变基
除了通过git merge来合并分支以外，还可以用git rebase操作将某一分支上的所有修改都移至另一分支上。
它的原理是首先找到这两个分支（即当前分支release、变基操作的目标基底分支 main） 的最近共同祖先 C1，然后对比当前分支相对于该祖先的历次提交，提取相应的修改并存为临时文件， 然后将当前分支指向目标基底 C4，并以此作为另一分支修改的基底。
跨分支变基
除了上述最基本的变基形式外，便基还有其他不同用途。
假设你希望将bugfix中的修改合并到主分支并发布，但暂时并不想合并 release中的修改， 因为它们还需要经过更全面的测试。这时，你就可以使用 git rebase 命令的 --onto 选项， 选中在 bugfix分支里但不在 release分支里的修改（即 C3 和 C4），将它们在 main 分支上重放：
移除分支提交
git rebase命令不仅可以给修改分支变基，还可以移除分支上的提交。
移除C1、C2提交。
cherry-pick
git cherry-pick可以将某一条分支上的某次提交直接移植到另外一条分支上，同时该提交也会被merge到分支上， 这种方式在你只想引入特性分支中的某个提交时很有用。值得注意的是，与git rebase不同，git cherry-pick后面的参数需要用该提交的hash，不能用分支名代替。
撤销合并
我们已经知道如何创建一个合并提交，但有时出错是在所难免的。 假设现在在一个feature分支上工作，不小心将其合并到主分支中，现在提交历史看起来是这样：
错误地合入分支后想要恢复到合并之前的状态 ，有两种方法：
一种是用git reset --hard HEAD~命令将主分支回退到上一次的提交。
这个方法的缺点是它会重写历史，在一个共享的仓库中这会造成问题。 用简单的话说就是如果其他人已经有你将要重写的提交，你应当避免使用 reset。 如果有任何其他提交在合并之后创建了，那么这个方法会使那些改动丢失。因此我们一般选择用第二种方法来进行版本回退。
通过git revert来生成一个与撤销版本修改互补的新的版本，从而达到去掉因分支merge所带来的修改的目的。
-m 1 标记指出 “mainline” 需要被保留下来的父结点。 当你引入一个合并到 HEAD（git merge feature），新提交有两个父结点：第一个是 HEAD（C4），第二个是将要合并入分支的最新提交（C3）。 在本例中，我们想要撤消所有由父结点 #2（C3）合并引入的修改，同时保留从父结点 #1（C4）开始的所有内容。
C6剔除了C3的修改保留了C4，主分支相当于回到了合入feature分支之前的状态。
