我们的工作流程:
我们有一个开发分支，所有的新功能和修复都会被推送。我们从 develop 分支中切出一个 release_candidate 分支，然后在发布时进入 master。
对于个别功能和修复，每个开发人员都会创建一个功能分支。我们将 git 配置为默认为 git pull --rebase。每个功能分支通常是我们经常从开发中 rebase 的本地分支。这保持了一个很好的干净的提交历史，很容易 merge 回开发，我们可以轻松地提交功能分支中的更改作为补丁进行审查。就本地功能分支而言，此流程是理想的。它会引起最少的麻烦，产生干净的提交历史，并允许我们在 merge 到开发中时压缩提交。
问题:
当我们有几个持久的功能分支被推送到远程以进行备份和协作时，问题就出现了。然而，频繁地 rebase 远程功能分支是一场灾难(因为我们自己对 rebase 的工作原理缺乏了解)。从那以后，我们学会了不对公共(public)功能分支进行 rebase 。
问题:
远程功能分支的干净 git 工作流程是什么？我们需要保持从开发中引入更改的能力，同时继续在功能分支上工作，因为它可能包含相关的修复。我们还希望保持干净的提交历史和审查(我们使用 arc)功能分支作为可以快速转发到开发的补丁的能力。
可以有多个长时间运行的公共(public)功能分支，每个功能分支可以有多个开发人员并行工作
pull 请求的想法不是很吸引人。我们已经使用 arc 进行代码审查，不想指定专人负责审查 pull 请求。
相关读物:
最佳答案
在阅读您的帖子后，对我来说，您的分支似乎没有任何问题(至少)。您的 rebase 工作流程也没有任何问题。但是，我建议仅在需要将它们 merge 回开发分支时才对功能分支进行 rebase 。因此，在协作过程中，没有人会体验到必须修复本地存储库才能开始新的一天的恐惧。现在的一个缺点是，当特性分支在那里挂了几个星期时。你最终会得到一个没有更新的代码，可能会花一两天时间来测试和修复冲突，在这种情况下，我建议还压缩功能分支中的提交，这样修复冲突会容易得多。
接下来，由于我的第一个建议有局限性，我建议为那些长期存在的分支破例，不时地从 develop 更新它们。对于您的修订历史，您可能会/不会有相同的预期结果，但我认为这将是 yield 大于损失。
develop o---o---o---o---o---o---o---o---o---o---o---o
\ \ \ /
feature mike---betty--paul--o--bt-mk-mk-o---bt--pl
关于公共(public)功能分支的 git 工作流程，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/38528866/