聊下git pull --rebase

有一种场景是常常发生的。

你们都基于develop拉出分支进行并行开发，这里的分支多是多到数十个。而后彼此在进行本身的逻辑编写，时间可能须要几天或者几周。在这期间你可能须要时不时的须要pull下远程develop分支上的同事的提交。这是个好的习惯，这样下去就能够避免你在一个无用的代码上进行长期的开发，回头来看这些代码不是新的代码。甚至是会面临不少冲突须要解决，而这个时候你可能还须要对冲突的部分代码进行测试回归，这就很麻烦了。

那么咱们来看一下你在pull时候须要习惯性的加上—rebase参数，这样能够避免不少问题。--rebase的本意是想让事情的发展看起来很连续和优美，而不是多出不少无用的merge commit 。

你在有些时候pull代码的时候会有这样的一个提示：

这个时候你是习惯性的，”esc ：wq“，直接默认commit注释。而后你的commit log就多了一笔很很差看的log。

若是你不懂的在最后release的时候合并掉这些无心义的commit，最后你的release分支就会被你搞的很丑陋。（合并commit请参考：聊下git merge –squash)

这个问题的出现是正常的，咱们来看下为何会出现这个问题。正常状况下的分支commit路线：

当前develop分支上有三个commit。如今咱们两个项目开始启动，须要分别拉出两个分支独立开发。

咱们分别checkout –b 出来两个分支，独立开发互不干扰。正常状况下，若是这两个分支的改动都没有重贴或者冲突的时候，一切都很顺利的。（重贴是指能够被系统自动合并的修改，而冲突是须要你手动解决的。你要重现这个现象仍是有点小麻烦的，你要修改恰好能够重贴的位置，而不是直接致使冲突的地方）

我在develop_newfeature_authorcheck里修改了点东西，push到develop。而后checkout 到develop_newfeature_apiwrapper。

git pull

这将会把develop_newfeature_authorcheck分支的修改直接拉下来于本地代码merge，且产生一个commit，也就是merge commit。

你可使用 git pull –rebase 这样的结局就彻底不同。—rebase 并不会产生一个commit提交，而是会将你的E commit附加到D commit的结尾处。在看commit log时，不会多出你所不知道的commit出来。其实此处的F commmit是无心义的，它只是一个merge commit。并且这里面的message里面的branch往后也不存了，这些分支都会被清除掉。

git pull –rebase 会使commit看起来很天然。

由于代码都有一个先后依赖，只是这个依赖在开发的时候谁先谁后的问题。

 

做者：王清培

出处：http://www.cnblogs.com/wangiqngpei557/

本文版权归做者和博客园共有，欢迎转载，但未经做者赞成必须保留此段声明，且在文章页面