长期（远程）功能分支上的git rebase

Question

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

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

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

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

我看了

Git: how to maintain permanent parallel branches

How to maintain (mostly) parallel branches with only a few difference

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

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

Answer 1

在处理rebase和远程分支时，

git push --force是生活中的事实，因为没有它，git push将不会进行非快进推送。 git中的大多数东西都假设历史只是附加到，从不编辑，并且rebase打破了这个假设，所以你必须做一些非常难以理解的事情来使它工作。

我们过去常常使用与您描述的工作流程非常类似的rebase工作流程，但最终会在一段时间后切换回合并工作流程。 Rebasing为您提供了漂亮，漂亮，线性的历史记录，但有许多缺点，例如需要--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。