Question

我们的工作流程：

我们有一个开发分支，其中推送了所有新功能和修复。我们从develop分支中删除了release_candidate分支，然后在发布时进入master。

对于个别功能和修复，每个开发人员都会创建一个功能分支。我们将git配置为默认为git pull --rebase。每个功能分支通常都是一个本地分支，我们经常从开发中进行修改。这保持了一个很好的干净的提交历史，简单地合并回到开发中，我们可以轻松地提交功能分支中的更改作为补丁进行审核。就本地特色分支来说，这种流程是理想的。它导致最小的麻烦，导致干净的提交历史，并允许我们在合并到开发时压缩提交。

问题：

当我们有一些持久的功能分支被推送到远程进行备份和协作时，出现了问题。但是，经常重新定位远程功能分支是一场灾难（因为我们自己对rebase如何工作缺乏了解）。从那以后，我们学会了不要改变公共部门的分支。

问题：

远程功能分支的干净git工作流程是什么？我们需要保持从开发中引入更改的能力，同时继续在功能分支上工作，因为它可能包含相关的修复。我们还希望保持干净的提交历史记录以及审查（我们使用arc）功能分支作为补丁的能力，该补丁可以快速转发到开发中。

可以有多个长期运行的公共功能分支，每个功能分支可以有多个开发人员并行工作

拉取请求的想法不是很吸引人。我们已经使用arc进行代码审查，并且不想指定负责审查拉取请求的点人员。

相关阅读：

Answer 1

在阅读您的帖子后，对我来说，您的分支似乎没有任何问题（至少）。变基工作流也没有错。但是，我建议仅在需要将功能分支合并回到开发分支时才对功能分支进行重新设置。因此，在进行协作时，没有人会遇到必须修复其本地存储库以开始新的一天的恐惧。现在的缺点是，要素分支在其中悬挂了数周。您最终将得到一个未更新的代码，可能需要花费一两天的时间来测试并解决冲突，在这种情况下，我建议您也将提交提交压缩在功能分支中，以便更轻松地解决冲突。

接下来，由于我的第一个建议是有局限性的，所以我建议对那些长期存在的分支机构进行例外处理，并从开发中不时进行更新。您可能/将不会有与修订版本相同的预期结果，但我认为收益大于损失大于损失。

develop     o---o---o---o---o---o---o---o---o---o---o---o
             \                   \           \         /
feature       mike---betty--paul--o--bt-mk-mk-o---bt--pl

公共功能分支的git工作流程

1 个答案: