【Git】git rebase变基

git rebase作用：相对于git merge的第二种合并分支方法，但是git rebase可以使git提交变得整洁

1. 场景1——合并多次提交

在日常开发中，代码变更比较频繁，有时候想让前几次提交的合并为一次提交，这里可以使用git rebase -i 命令来完成。

命令格式：git rebase -i [startpoint] [endpoint]

• 其中i表示interactive的缩写即弹出交互式的界面让用户编辑完成合并操作；

• [startpoint] [endpoint]则指定了一个编辑区间，如果不指定[endpoint]，则该区间的终点默认是当前分支HEAD所指向的commit(注：该区间指定的是一个前开后闭的区间)

执行完命令后，会跳到一个vim编辑器中：

• pick：保留该commit（缩写:p）
• reword：保留该commit，但我需要修改该commit的注释（缩写:r）
• edit：保留该commit, 但我要停下来修改该提交(不仅仅修改注释)（缩写:e）
• squash：将该commit和前一个commit合并（缩写:s）
• fixup：将该commit和前一个commit合并，但我不要保留该提交的注释信息（缩写:f）
• exec：执行shell命令（缩写:x）
• drop：我要丢弃该commit（缩写:d）

注意: 不要把已经在仓库的commit进行合并，避免冲突造成不必要的麻烦

2. 场景2——线性提交记录

参考文章：http://blog.itblood.com/1646.html

rebase 实际上就是取出一系列的提交记录，“复制”它们，然后在另外一个地方逐个的放下去。

Rebase 的优势就是可以创造更线性的提交历史，这听上去有些难以理解。如果只允许使用 Rebase 的话，代码库的提交历史将会变得异常清晰。

• 创建新分支 bugFix分支：git branch bugFix

• 提交一次(提交在master分支上)：git commit

• 切换到bugFix分支：git checkout bugFix

• 提交一次（提交在bugFix分支上）：git commit

• 使用git rebase把 bugFix 分支里的工作直接移到 master 分支上（移动以后会使得两个分支的功能看起来像是按顺序开发，但实际上它们是并行开发的）：git rebase master

注意：提交记录 C3 依然存在（树上那个半透明的节点），而 C3’是我们 Rebase 到 master 分支上的 C3 的副本。

• 切换到master分支上（为了进行更新master的操作）：git checkout master

把master的 rebase 到 bugFix 分支上（由于 bugFix 继承自 master，所以 git 只是简单的把 master 分支的引用向前移动了一下而已）：git rebase bugFix

场景3——不使用git pull而使用git fetch+git rebase origin/分支