在网络上,人们总是建议不要在公共分支中使用 git rebase
,但我看不出有什么问题,如果你总是在一个特性分支上进行变基。
我的团队总是为特性(哇)创建分支,我们习惯于只在本地使用它,因此变基不是问题,但有时我们想向另一个开发人员展示部分完成的特性代码,所以我们只需将其公开化,但然后我们就失去了使用 git rebase
的所有优势,或者至少在网上可以读到这样的说法。
我不明白问题在哪里,如果正在同一公共分支上工作的开发人员从未将其合并到任何分支中(当该分支仍在开发时),并且当他们拉取它时,他们会执行一个变基操作。对分支所做的任何更改将始终在远程分支的顶部进行变基,从而永远不会丢失,并且您不会遇到相同提交重复的问题。
附录1:
至今为止,没有一个答案显示将发生什么问题以及如何发生问题,因此我将尝试更清楚地解释。
我将举例说明使用变基的工作流程(在以前的段落中描述不当,抱歉),我认为没有任何问题。
初始状态:
master ==========A
origin/feature +=====AB
feature user A +=====AB
feature user B +=====AB
主分支(master)新增了一些提交记录,用户A也进行了几次提交:
master ==========A=====C
origin/feature +=====AB
feature user A +=====AB====D
feature user B +=====AB
用户A经常使用git pull --rebase
命令更新分支,在没有新内容的情况下,他将分支变基到主分支并推送:
master ==========A=====C
origin/feature +=====ACB'=====ACB'D
feature user A +=====ACB'=====ACB'D
feature user B +=====AB
(请注意,B'是仍然代表更改B的新提交)
然后用户B进行了几次提交:
master ==========A=====C
origin/feature +=====ACB'=====ACB'D
feature user A +=====ACB'=====ACB'D
feature user B +=====AB======E
作为惯例,用户B最终执行了git pull --rebase
操作,因为没有必要在主分支上进行变基,所以他只需进行推送:
master ==========A=====C
origin/feature +=====ACB'=====ACB'D======E'
feature user A +=====ACB'=====ACB'D
feature user B +=====ACB'=====ACB'D======E'
git pull --rebase
,他的B'
将与用户A的B'
不同,因为每个提交(commit)B'
的变体都包含一个提交时间戳,这将改变每个提交的SHA-1哈希。如果既没有用户A也没有用户B更改任何补丁,并且每次重新基础操作都没有冲突,那么只要始终在主分支上进行重新基础而不是合并到主分支,你就可以基本解决SHA-1的差异。如果您所有的git用户都意识到了这种情况,请继续使用。 - Mikko Rantalainengit cat-file -p HEAD
查看示例)。在创建提交时,可以覆盖这两个时间戳,但对于新提交,默认情况下两个时间戳都为当前时间。对于已经变基的提交,“作者”时间戳保持不变,而“提交者”时间戳设置为变基时间。除非您在变基时使用特殊标志,否则您的变基后的SHA-1取决于您运行变基命令的时间。 - Mikko Rantalainen