代码合并：Merge、Rebase 的选择

Merge

将master分支合并到feature分支

1 2	git checkout feature git merge master

压缩到一行

1	git merge master feature

merge

Merge 好在它是一个安全的操作。现有的分支不会被更改，避免了 rebase 潜在的缺点(后面会说)。
另一方面，这同样意味着每次合并上游更改时 feature 分支都会引入一个外来的合并提交。如果 master 非常活跃的话，这或多或少会污染你的分支历史。

这样可以将feature分支并入master分支

1 2	git checkout feature git rebase master

它会把整个 feature 分支移动到 master 分支的后面，有效地把所有 master 分支上新的提交并入过来。但是，rebase 为原分支上每一个提交创建一个新的提交，重写了项目历史，并且不会带来合并提交。
rebase

rebase最大的好处是你的项目历史会非常整洁。首先，它不像 git merge 那样引入不必要的合并提交。其次，如上图所示，rebase 导致最后的项目历史呈现出完美的线性——你可以从项目终点到起点浏览而不需要任何的 fork。

把 -i 传入 git rebase 选项来开始一个交互式的rebase过程：

1 2	git checkout feature git rebase -i master

它会打开一个文本编辑器，显示所有将被移动的提交：

1
2
3

pick 33d5b7a Message for commit #1
pick 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3

这个列表定义了 rebase 将被执行后分支会是什么样的。更改 pick 命令或者重新排序，这个分支的历史就能如你所愿了。比如说，如果第二个提交修复了第一个提交中的小问题，你可以用 fixup 命令把它们合到一个提交中

1
2
3

pick 33d5b7a Message for commit #1
fixup 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3

保存后关闭文件，Git 会根据你的指令来执行 rebase

git rebase 的黄金法则便是，绝不要把公共的分支rebase到dev branch.

比如说，如果你把 master 分支 rebase 到你的 feature 分支上会发生什么：
rebase

在你工作流中使用rebase最好的用法之一就是清理本地正在开发的分支。比如说，下面的命令对最新的3次提交进行了交互式rebase：

1 2	git checkout feature git rebase -i HEAD~3

通过指定HEAD~3作为新的基提交，你实际上没有移动分支——你只是将之后的3次提交重写了。注意它不会把上游分支的更改并入到 feature 分支中。
Rebasing onto HEAD~3

如果你想用这个方法重写整个 feature 分支，git merge-base 命令非常方便地找出 feature 分支开始分叉的基。下面这段命令返回基提交的 ID，你可以接下来将它传给 git rebase

1	git merge-base feature master

默认情况下，git pull 命令会执行一次merge，但你可以传入–rebase 来强制它通过rebase来整合远程分支。

1	git pull --rebase origin master #可以将feature rebase到master

brand new commits

提交记录如下:

1
2
3

pick f1f92bd Add first commit
pick 2dfbc7e Add second commit
pick c4e858b Add third commit

进入rebase git rebase -i HEAD^3, vim编辑模式

提交记录修改为：

1
2
3

pick f1f92bd Add first commit
s 2dfbc7e Add second commit
s c4e858b Add third commit

保存退出。