如果你不能很好的应用 Git，那么这里为你提供一个非常棒的 Git 在线练习工具 Git Online ，你可以更直观的看到你所使用的命令会产生什么效果
另外，你在使用 Git 合并分支时只会使用 git merge 吗？有时使用 git rebase 可以比 git merge 做出更优雅的操作
- - - - -
不知怎么，git rebase 命令被赋予了一个神奇的污毒声誉，初学者应该远离它，但它实际上可以让开发团队在使用时更加轻松。
你可以将它理解成「七伤拳」，「七伤拳」并不是不能练，只是练「七伤拳」有一个先诀条件，那就是内功境界一定要非常高，即你要充分理解 git rebase 命令
在本文中，我们将 git rebase 与 git merge 命令进行比较。在 Git 工作流中，说明所有可以使用 rebase 的场景
概念概述关于 git rebase ，首先要理解的是它解决了和 git merge 同样的问题。这两个命令都旨在将更改从一个分支合并到另一个分支，但二者的合并方式却有很大的不同。
当你在专用分支上开发新 feature 时，然后另一个团队成员在 master 分支提交了新的 commits，这会发生什么？这会导致分叉的历史记录，对于这个问题，使用 Git 作为协作工具的任何人来说都应该很熟悉。
现在，假设在 master 分支上的新提交与你正在开发的 feature 相关。需要将新提交合并到你的 feature 分支中，你可以有两个选择：merge 或者 rebase。
Merge 方式最简单的方式是通过以下命令将 master 分支合并到 feature 分支中：
git checkout feature git merge master或者，你可以将其浓缩为一行命令：
git merge feature master这会在 feature 分支中创建一个新的 merge commit，它将两个分支的历史联系在一起，请看如下所示的分支结构：
使用 merge 是很好的方式，因为它是一种 非破坏性的 操作。现有分支不会以任何方式被更改。这避免了 rebase 操作所产生的潜在缺陷（下面讨论）。
另一方面，这也意味着 feature 分支每次需要合并上游更改时，它都将产生一个额外的合并提交。如果master 提交非常活跃，这可能会严重污染你的 feature 分支历史记录。尽管可以使用高级选项 git log 缓解此问题，但它可能使其他开发人员难以理解项目的历史记录
Rebase 方式作为 merge 的替代方法，你可以使用以下命令将 master 分支合并到 feature分支上：
git checkout feature git rebase master这会将整个 feature 分支移动到 master 分支的顶端，从而有效地整合了所有 master 分支上的提交。但是，与 merge 提交方式不同，rebase 通过为原始分支中的每个提交创建全新的 commits 来 重写 项目历史记录。
rebase 的主要好处是可以获得更清晰的项目历史。首先，它消除了 git merge 所需的不必要的合并提交；其次，正如你在上图中所看到的，rebase 会产生完美线性的项目历史记录，你可以在 feature分支上没有任何分叉的情况下一直追寻到项目的初始提交。这样可以通过命令 git log，git bisect 和 gitk 更容易导航查看项目。
但是，针对这样的提交历史我们需要权衡其「安全性」和「可追溯性」。如果你不遵循 ，重写项目历史记录可能会对你的协作工作流程造成灾难性后果。而且，rebase 会丢失合并提交的上下文， 你也就无法看到上游更改是何时合并到 feature 中的。
交互式 Rebase交互式 rebase 使你有机会在将 commits 移动到新分支时更改这些 commits。这比自动 rebase 更强大，因为它提供了对分支提交历史的完全控制。通常，这用于在合并 feature 分支到 master 之前清理其杂乱的历史记录。
要使用交互式 rebase，需要使用 git rebase 和 -i 选项：
git checkout feature git rebase -i master这将打开一个文本编辑器，列出即将移动的所有提交：
pick 33d5b7a Message for commit #1 pick 9480b3d Message for commit #2 pick 5c67e61 Message for commit #3