代码合并：Merge、Rebase 的选择

图解 Git 命令

基本用法

上面的四条命令在工作目录、stage 缓存(也叫做索引)和 commit 历史之间复制文件。

• git add files 把工作目录中的文件加入 stage 缓存
• git commit 把 stage 缓存生成一次 commit，并加入 commit 历史
• git reset -- files 撤销最后一次 git add files，你也可以用 git reset 撤销所有 stage 缓存文件
• git checkout -- files 把文件从 stage 缓存复制到工作目录，用来丢弃本地修改

• git commit -a 相当于运行 git add 把所有当前目录下的文件加入 stage 缓存再运行 git commit。
• git commit files 进行一次包含最后一次提交加上工作目录中文件快照的提交，并且文件被添加到 stage 缓存。
• git checkout HEAD -- files 回滚到复制最后一次提交

代码合并：Merge、Rebase 的选择

概述

git rebase 和git merge 做的事其实是一样的。它们都被设计来将一个分支的更改并入另一个分支，只不过方式有些不同

Merge

#将 master 分支合并到 feature 分支最简单的办法就是用下面这些命令
git checkout feature
git merge master

#或者，你也可以把它们压缩在一行里。
git merge master feature

Rebase

#将 feature 分支并入 master 分支
git checkout feature
git rebase master

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



rebase最大的好处是你的项目历史会非常整洁。首先，它不像 git merge 那样引入不必要的合并提交.

这种简单的提交历史会带来两个后果：安全性和可跟踪性。如果你违反了 rebase 黄金法则，重写项目历史可能会给你的协作工作流带来灾难性的影响。此外，rebase 不会有合并提交中附带的信息——你看不到 feature 分支中并入了上游的哪些更改.

交互式的 rebase

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
#这个列表定义了 rebase 将被执行后分支会是什么样的。更改 pick 命令或者重新排序，这个分支的历史就能如你所愿了。比如说，如果第二个提交修复了第一个提交中的小问题，你可以用 fixup 命令把它们合到一个提交中：
pick 33d5b7a Message for commit #1
fixup 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3

保存后关闭文件，Git 会根据你的指令来执行 rebase，项目历史看上去会是这样

忽略不重要的提交会让你的 feature 分支的历史更清晰易读。这是 git merge 做不到的。

Rebase 的黄金法则

最重要的就是什么时候 不能 用 rebase。git rebase 的黄金法则便是，绝不要在公共的分支上使用它。

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

这次 rebase 将 master 分支上的所有提交都移到了 feature 分支后面。问题是它只发生在你的代码仓库中，其他所有的开发者还在原来的 master 上工作。因为 rebase 引起了新的提交，Git 会认为你的 master 分支和其他人的 master 已经分叉了

所以，在你运行 git rebase 之前，一定要问问你自己「有没有别人正在这个分支上工作？」。如果答案是肯定的，那么把你的爪子放回去，重新找到一个无害的方式（如git revert）来提交你的更改。不然的话，你可以随心所欲地重写历史。

#撤销提交
git revert 提交id

将上游分支上的更改并入feature分支

merge 是保留你完整历史的安全选择，

rebase 将你的 feature 分支移动到 master 分支后面，创建一个线性的历史。

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

用 Pull Request 进行审查

如果你将 Pull Request 作为你代码审查过程中的一环，你需要避免在创建 Pull Request 之后使用 git rebase。只要你发起了 Pull Request，其他开发者能看到你的代码，也就是说这个分支变成了公共分支。重写历史会造成 Git 和你的同事难以找到这个分支接下来的任何提交

来自其他开发者的任何更改都应该用 git merge 而不是 git rebase 来并入。

因此，在提交 Pull Request前用交互式的 rebase 进行代码清理通常是一个好的做法。

可以在一个临时分支中执行 rebase。这样的话，如果你意外地弄乱了你 feature 分支的历史，你还可以查看原来的分支然后重试

git checkout feature
git checkout -b temporary-branch
git rebase -i master
# [清理目录]
git checkout master
git merge temporary-branch

总结

如果你想要一个干净的、线性的提交历史，没有不必要的合并提交，你应该使用 git rebase 而不是 git merge 来并入其他分支上的更改。

另一方面，如果你想要保存项目完整的历史，并且避免重写公共分支上的 commit， 你可以使用 git merge。两种选项都很好用，但至少你现在多了 git rebase 这个选择。