您可以看到网络上的所有人都建议不要git rebase
在公共分支中使用,但如果您总是重新定义功能分支,我看不出有什么问题.
我的团队总是使用分支功能(哇),我们习惯只在本地使用它,所以rebase不是问题,但有时我们想向另一个开发人员展示部分完成的功能的代码,所以我们只是宣传它,但是我们失去了所有的优点git rebase
,或者至少是你在网上可以阅读的内容.
我不明白是什么问题,如果在同一个公共分支工作的开发人员从未将它合并到任何分支(当该分支上仍有开发时),并且当他们拉动它时,他们使用rebase操作.对分支所做的任何更改都将始终在远程分支的顶部进行rebase,因此永远不会丢失,并且您不会遇到重复相同提交的问题.
到目前为止,没有一个答案显示了将要发生的问题以及它将如何发生,所以我将试着更清楚.
我将举例说明使用rebase的工作流程(在前面的段落中描述得很糟,抱歉)我没有看到任何问题.
初始状态:
master ==========A
origin/feature +=====AB
feature user A +=====AB
feature user B +=====AB
Run Code Online (Sandbox Code Playgroud)
master得到一些提交,用户A做了一些提交:
master ==========A=====C
origin/feature +=====AB
feature user A +=====AB====D
feature user B +=====AB
Run Code Online (Sandbox Code Playgroud)
用户A做了git pull --rebase
(他总是这样做)来更新他的分支,没有新的东西,然后他重新掌握并推送:
master ==========A=====C
origin/feature +=====ACB'=====ACB'D
feature user A +=====ACB'=====ACB'D
feature user B +=====AB
Run Code Online (Sandbox Code Playgroud)
(注意B'是仍然代表变化B的新提交)
然后用户B做了一些提交:
master ==========A=====C
origin/feature +=====ACB'=====ACB'D
feature user A +=====ACB'=====ACB'D
feature user B +=====AB======E
Run Code Online (Sandbox Code Playgroud)
用户B终于做了一次git pull --rebase
,没有必要对master进行rebase,所以他只是推动:
master ==========A=====C
origin/feature +=====ACB'=====ACB'D======E'
feature user A +=====ACB'=====ACB'D
feature user B +=====ACB'=====ACB'D======E'
Run Code Online (Sandbox Code Playgroud)
Jör*_*tag 33
如果你改变,你重写历史.就像在现实世界中一样,如果你想改写历史,你需要一个阴谋:每个人都必须"参与"这个阴谋(至少每个知道历史的人,即每个曾经从分支机构撤出的人) .
只要谁从分支拉人的圈子受到严格控制,这是很容易得到一个阴谋去,但是,只要你发布的历史,就变成了很多困难.但这并非不可能:pu
例如,Junio C Hamano的Git存储库中的分支在每次发布后都会被重新定位,这是一个广泛发布的存储库.这种方法的工作方式是,分支机构经常被重新定位,以及发生这种情况的时间,在Git网站,Git wiki和Git邮件列表中广泛记录,并且每个rebase都会在邮件列表中提前公布,所以人们可以为此做好准备.
当你反对公共分支时,这是完全可以的.
但是当你改变公共分支本身时,对那些也在使用它的人来说并不好.
加成:
当rebase中断单元测试时,您将没有机会进行git bisect
错误的修订.
更多细节:
归档时间: |
|
查看次数: |
10346 次 |
最近记录: |