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

Question

背景:我们的项目使用 github，我在主存储库的自己的分支上工作。我们使用 rebase 而不是 merge 来避免大量的 merge 提交。

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

1. 在实现新功能时，创建我分支的 master 的本地分支并将我的更改放入其中。我和小组中的其他人进行了很多小的提交，因此几乎总是会有多个提交影响分支上的同一个文件。
2. 将本地分支推送到我的分支上，这样我就有了我正在处理的内容的远程副本(我不想在我的笔记本电脑死机或丢失时丢失所有更改。我尝试在最后执行此操作每一天)。
3. 如果完成该功能需要很长时间，我偶尔会在我的 fork 的 master 上重新设置基准，以确保没有可能破坏我的功能的更改。这通常可以正常工作。
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

git push --force 在处理 rebase 和远程分支时是一个不争的事实，因为 git push 不会执行非快进推送它。 git 中的大多数东西都假设历史只是附加，从不编辑，而 rebase 打破了这个假设，所以你必须做一些非常奇怪的事情才能让它工作。

我们曾经使用与您描述的非常相似的 rebase 工作流，但最终在一段时间后切换回 merge 工作流。 Rebasing 给你一个很好的、漂亮的、线性的历史，但是有很多缺点，比如需要 --force，在 merge 到 master 之前失去查看分支状态的能力，等等​​。

正如 Amber 提到的， rebase 使得与同一分支上的其他人一起工作变得非常困难——在 git push --forceing 之前，您必须查看远程分支的状态以查看是否有人先推送了它，然后 pull --rebase 将其 push ，然后 git push --force。即使这有竞争条件 - 如果其他人在您 push --force 之前推送，他们的更改将被您的更改覆盖。