|
概述
你要知道的第一件事是，git rebase 和git merge 做的事其实是一样的。它们都被设计来将一个分支的更改并入另一个分支，只不过方式有些不同。
想象一下，你刚创建了一个专门的分支开发新功能，然后团队中另一个成员在 master 分支上添加了新的提交。这就会造成提交历史被 fork 一份，用 Git 来协作的开发者应该都很清楚。
现在，如果 master 中新的提交和你的工作是相关的。为了将新的提交并入你的分支，你有两个选择：merge 或 rebase。
Merge
将 master 分支合并到 feature 分支最简单的办法就是用下面这些命令：
git checkout feature
git merge master
或者，你也可以把它们压缩在一行里。
git merge master feature
Rebase
作为 merge 的替代选择，你可以像下面这样将 feature 分支并入 master 分支：
git checkout feature
git rebase master
它会把整个 feature 分支移动到 master 分支的后面，有效地把所有 master 分支上新的提交并入过来。但是，rebase 为原分支上每一个提交创建一个新的提交，重写了项目历史，并且不会带来合并提交。
rebase最大的好处是你的项目历史会非常整洁。首先，它不像 git merge 那样引入不必要的合并提交。其次，如上图所示，rebase 导致最后的项目历史呈现出完美的线性——你可以从项目终点到起点浏览而不需要任何的 fork。这让你更容易使用 git log、git bisect 和 gitk 来查看项目历史。
不过，这种简单的提交历史会带来两个后果：安全性和可跟踪性。如果你违反了 rebase 黄金法则，重写项目历史可能会给你的协作工作流带来灾难性的影响。此外，rebase 不会有合并提交中附带的信息——你看不到 feature 分支中并入了上游的哪些更改。
Rebase 的黄金法则
当你理解 rebase 是什么的时候，最重要的就是什么时候 不能 用 rebase。git rebase 的黄金法则便是，绝不要在公共的分支上使用它。
比如说，如果你把 master 分支 rebase 到你的 feature 分支上会发生什么：
这次 rebase 将 master 分支上的所有提交都移到了 feature 分支后面。问题是它只发生在你的代码仓库中，其他所有的开发者还在原来的 master 上工作。因为 rebase 引起了新的提交，Git 会认为你的 master 分支和其他人的 master 已经分叉了。
同步两个 master 分支的唯一办法是把它们 merge 到一起，导致一个额外的合并提交和两堆包含同样更改的提交。不用说，这会让人非常困惑。
所以，在你运行 git rebase 之前，一定要问问你自己「有没有别人正在这个分支上工作？」。如果答案是肯定的，那么把你的爪子放回去，重新找到一个无害的方式（如 git revert）来提交你的更改。不然的话，你可以随心所欲地重写历史。
交互式的 rebase
交互式的 rebase 允许你更改并入新分支的提交。这比自动的 rebase 更加强大，因为它提供了对分支上提交历史完整的控制。一般来说，这被用于将 feature 分支并入 master 分支之前，清理混乱的历史。
把 -i 传入 git rebase 选项来开始一个交互式的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
- p, pick = 保留该commit（缩写:p）
- r, reword = 保留该commit，但我需要修改该commit的注释（缩写:r）
- e, edit = 保留该commit, 但我要停下来修改该提交(不仅仅修改注释)（缩写:e）
- s, squash = 将该commit和前一个commit合并（缩写:s）
- f, fixup = 将该commit和前一个commit合并，但我不要保留该提交的注释信息（缩写:f）
- x, exec = 执行shell命令（缩写:x）
- b, break = 停在这里(稍后使用“git rebase—continue”继续rebase)
- d, drop = 丢弃该commit（缩写:d）
- l, label = 用名称标记当前磁头
- t, reset = 将磁头复位到一个标签
- m, merge [-C | -c ] [# ]
使用原始合并提交消息(或者如果没有指定原始合并提交，则使用oneline)创建合并提交。使用 - c < commit> 重新编写提交消息。
保存后关闭文件，Git 会根据你的指令来执行 rebase.
忽略不重要的提交会让你的 feature 分支的历史更清晰易读。这是 git merge 做不到的。
本地清理
在你工作流中使用 rebase 最好的用法之一就是清理本地正在开发的分支。隔一段时间执行一次交互式 rebase，你可以保证你 feature 分支中的每一个提交都是专注和有意义的。你在写代码时不用担心造成孤立的提交——因为你后面一定能修复。
调用 git rebase 的时候，你有两个基（base）可以选择：上游分支（比如 master）或者你 feature 分支中早先的一个提交。我们在「交互式 rebase」一节看到了第一种的例子。后一种在当你只需要修改最新几次提交时也很有用。比如说，下面的命令对最新的 3 次提交进行了交互式 rebase：
git checkout feature
git rebase -i HEAD~3
通过指定 HEAD~3 作为新的基提交，你实际上没有移动分支——你只是将之后的 3 次提交重写了。注意它不会把上游分支的更改并入到 feature 分支中。
如果你想用这个方法重写整个 feature 分支，git merge-base 命令非常方便地找出 feature 分支开始分叉的基。下面这段命令返回基提交的 ID，你可以接下来将它传给 git rebase：
git merge-base feature master
交互式 rebase 是在你工作流中引入 git rebase 的的好办法，因为它只影响本地分支。其他开发者只能看到你已经完成的结果，那就是一个非常整洁、易于追踪的分支历史。
但同样的，这只能用在私有分支上。如果你在同一个 feature 分支和其他开发者合作的话，这个分支是公开的，你不能重写这个历史。
用带有交互式的 rebase 清理本地提交，这是无法用 git merge 命令代替的。
git checkout master
git pull
git checkout local
git rebase -i HEAD~2 //合并提交 --- 2表示合并两个
git rebase master---->解决冲突--->git rebase --continue
git checkout master
git merge local
git push
合并 最近提交的 commit
1、git log 查看当前的提交历史
2. git rebase 进行 git 压缩
具体的操作下面的 Commands 说明得很清楚了，对于 commit 合并可以使用 squash、fixup 指令，区别是 squash 会将该 commit 的注释添加到上一个 commit 注释中，fixup 是放弃当前 commit 的注释；
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out
参考：https://github.com/geeeeeeeeek/git-recipes/wiki/5.1-%E4%BB%A3%E7%A0%81%E5%90%88%E5%B9%B6%EF%BC%9AMerge%E3%80%81Rebase-%E7%9A%84%E9%80%89%E6%8B%A9 | 
转播
