有一种场景是经常发生的。
大家都基于 develop
拉出分支进行并行开发,这里的分支可能是多到数十个。然后彼此在进行自己的逻辑编写,时间可能需要几天或者几周。在这期间你可能需要时不时的需要 pull
下远程 develop
分支上的同事的提交。这是个好的习惯,这样下去就可以避免你在一个无用的代码上进行长期的开发,回头来看这些代码不是新的代码。甚至是会面临很多冲突需要解决,而这个时候你可能还需要对冲突的部分代码进行测试回归,这就很麻烦了。
那么我们来看一下你在 pull
时候需要习惯性的加上 --rebase
参数,这样可以避免很多问题。--rebase
的本意是想让事情的发展看起来很连续和优美,而不是多出很多无用的 merge commit
。
你在有些时候pull代码的时候会有这样的一个提示:
这个时候你是习惯性的,esc :wq
,直接默认 commit
注释。然后你的 commit log
就多了一笔很不好看的 log
。
如果你不懂的在最后 release
的时候合并掉这些无意义的 commit
,最后你的 release
分支就会被你搞的很丑陋。
这个问题的出现是正常的,我们来看下为什么会出现这个问题。正常情况下的分支 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
看起来很自然。
因为代码都有一个前后依赖,只是这个依赖在开发的时候谁先谁后的问题。
本文转载自:https://www.cnblogs.com/wangiqngpei557/p/6056624.html