长期(远程)功能分支上的git rebase

Question

背景:我们在项目中使用github,并且在我自己的主存储库的fork上工作.我们使用rebase而不是merge来避免大型合并提交.

场景:我想要的工作方式是这样的:

1. 在实现新功能时,创建fork的master的本地分支并在那里进行更改.我和组中的其他人做了很多小提交,因此几乎总会有多个提交影响分支上的同一个文件.
2. 将本地分支推送到我的分支,因此我有一个我正在处理的远程副本(如果我的笔记本电脑死亡或丢失,我不想丢失所有更改.我尝试在每天结束时执行此操作).
3. 如果完成该功能需要很长时间,我偶尔会对我的前任主人进行修改,以确保没有任何更改可能会破坏我的功能.这通常可行.
4. 为了使分支的远程副本保持最新,我将本地分支推送到rebase之后.

问题:第4步是我遇到问题的地方.我几乎总是要处理非快速转发的提交并使用git push --force.

我看了看

Git:如何维护永久并行分支

如何维护(大多数)并行分支只有一些差异

并没有找到一种方法使我的工作流程工作.在git工作流上进行谷歌搜索主要返回的结果是假设你们都在本地分支上工作,而不是在github上保留远程副本(例如 http://nvie.com/posts/a-successful-git-branching-model /).

我对Git比较陌生,所以我想知道我是否遗漏了一些东西.我希望能够在没有--force的情况下完成第4步.另一个工作流仍然允许我使用rebase而不是merge并保留我的本地分支的远程副本也非常有用.

Answer 1

git push --force在处理rebase和远程分支时,这是生活中的事实,因为git push如果没有它,就不会进行非快速推送.git中的大多数东西都假设历史只是附加到,从不编辑,并且rebase打破了这个假设,所以你必须做一些非常难以理解的事情来使它工作.

我们过去常常使用与您描述的工作流程非常类似的rebase工作流程,但最终会在一段时间后切换回合并工作流程.重新定位为您提供了漂亮,漂亮,线性的历史记录,但有许多缺点,例如要求--force,在合并master之前失去查看分支状态的能力,等等​​.

正如Amber所提到的,rebase使得与同一分支上的其他人一起工作变得非常困难 - 在git push --force开始之前,你必须先查看远程分支的状态,看看是否有其他人先推送它pull --rebase,然后再进入,git push --force.即使这有竞争条件 - 如果其他人在你之前推动push --force,他们的改变将被你的改写.

Answer 2

如果你rebase正在进行,你将永远不得不--force在推动时,因为rebase重写了历史.这就是它的工作原理.根据定义,重写历史不会在同一历史上快速前进.

替代方案是merge代替rebase.您可以使用完全相同的工作流程,除了使用merge而不是rebase,您不必强制推送.

如果没有其他人使用您的远程分支,那么使用--force本身并不是坏事.如果其他人正在使用远程分支,您可能应该使用它merge.