在公共功能分支中使用git rebase

Fil*_*sti 28 git workflow

您可以看到网络上的所有人都建议不要git rebase在公共分支中使用,但如果您总是重新定义功能分支,我看不出有什么问题.

我的团队总是使用分支功能(哇),我们习惯只在本地使用它,所以rebase不是问题,但有时我们想向另一个开发人员展示部分完成的功能的代码,所以我们只是宣传它,但是我们失去了所有的优点git rebase,或者至少是你在网上可以阅读的内容.

我不明白是什么问题,如果在同一个公共分支工作的开发人员从未将它合并到任何分支(当该分支上仍有开发时),并且当他们拉动它时,他们使用rebase操作.对分支所做的任何更改都将始终在远程分支的顶部进行rebase,因此永远不会丢失,并且您不会遇到重复相同提交的问题.

附加1:

到目前为止,没有一个答案显示了将要发生的问题以及它将如何发生,所以我将试着更清楚.

我将举例说明使用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都会在邮件列表中提前公布,所以人们可以为此做好准备.

  • 所以只要你能让每个人都参与到阴谋中,有什么步骤可以确保他们与重写的历史同步? (7认同)
  • 究竟.关键是必须告知任何使用(或可能使用)分支的人是否最终会重写其历史记录.只要您获得所有(潜在)用户的同意,重写已发布的历史记录就没有错.用户协议表明,当您重写该分支的历史部分时,他们无权投诉.您甚至可以使用特殊前缀来指示此类可重写分支:tmp /,unstable /,rewritable /或use-at-own-risk /. (4认同)

Ant*_*ins 6

当你反对公共分支时,这是完全可以的.

但是当你改变公共分支本身时,对那些也在使用它的人来说并不好.

加成:

当rebase中断单元测试时,您将没有机会进行git bisect错误的修订.

更多细节:

  • 您准备了一些要添加到分支的代码.
  • 你调试了它,所以它通过了所有的单元测试
  • 你已经在(远程)分支中获取了新的更改
  • 现在你正在为重新设定的远程分支重新设置你的代码
  • 在这里,单元测试会被打破
  • 你正在运行git bisect,它指向远程rebase.
  • 你的行为?


moe*_*sef 5

http://git-scm.com/book/ch3-6.html

\n\n

在“变基的危险”部分下

\n\n
\n

...你\xe2\x80\x99会被朋友和家人嘲笑。

\n
\n