关于git rebase的几点思考

       平时使用git rebase这个命令的机会并不多，直到最近有需要合并给git commit log的需求时，使用到了git rebase命令。现在特地把一些关键的个人感受记录在下面，以供日后参考。

合并多条commit log

方法在搜索引擎上面都可以搜到。简单来说就是先执行：

git reabse -i [commit-id_end] [commit-id_start]

 commit-id_end是最后一个需要合并的记录的前一个时间点的commit id，commit-id_start是第一个需要合并的提交的commit id， commit-id_start可以省略不写。执行完这条命令之后，会弹出一个文本编辑界面，我们需要确定哪些记录需要被合并，哪些记录需要被保留。我最常用的就是第一条（时间线最早的一条）保留下来（设置为pick），其余均合并（squash）。编辑完毕，保存退出。然后会进入第二个文本编辑界面，我们需要设置好合并后的commit message。设置完毕保存退出，就可以看到git开始执行合并操作了。

Q: 本地合并结束后，如何同步到远程？

A: 执行git push -f 强制更新（需要带上-f）

Q: 如果我有另一个地方也保存了仓库的状态，怎么进行同步合并结果呢？

A: 这里需要特别注意，如果另一个开发环境也保存了合并之前的哪些commit log，若不能正确地合并，则会导致之前合并操作前功尽弃。这里根据实践，一个简单的命令即可解决： git pull -rebase

Q: 如果指定了commit-id_start，在合并时发现合并工作被转移到一个临时分支，该怎么办？

A: 以这个分支为基础创建一个新的分支，假如该分支名称为temp。切换回原分支，然后执行git rebase temp。执行完之后可能会出现冲突，这个时候我们需要解决冲突，然后执行git add并执行git rebase --continue。如果执行git rebase --continue失败，那么可以选择执行git rebase --skip，后续可能会多次提示冲突，重复这几步操作即可。

关于git rebase

接上面的叙述，前面用到了两次rebase，尤其是git pull -rebase到底发生了什么。查阅了相关资料，可以知道git rebase是防止菱形提交结果的。那疑惑来了，为什么在以往的开发经历中貌似没有法发现这个问题。经思考，总结出我们开发工作的流程是这样的：

1）从master中checkout一个开发分支dev

2）dev上面完成开发工作并完成测试

3）现在需要把dev合并到master，首先checkout到master，然后pull去更新master，最后再merge dev

4）master运行没有问题，可以删除/保留dev分支

也就是说这样使用git，很少会关注到用git rebase。当然，这次关注到git rebase还是因为前面所记录的：如果有第二个开发的地方需要同步commit log，最好用git pull -rebase来解决。