时间戳

首页 > 解决方案 > 工作流程：带有功能分支、变基、拉取请求的 git（非开源项目）

git - 工作流程：带有功能分支、变基、拉取请求的 git（非开源项目）

问题描述

我们团队中有 5 名开发人员定期（每天）向单个 repo 的 master 分支提交拉取请求。典型的工作流程是这样的：

问题是如果多个开发者提交拉取请求，只有其中1个可以成功合并到主分支。一旦完成，所有其他分支都会失败，因为主分支领先于功能分支。然后所有开发人员必须再次变基和推动。然后只能合并1个，其余的失败。迭代直到所有 PR 被合并。

应该有更好的方法吧？

标签： gitbitbucketpull-requestgit-workflowfeature-branch

解决方案

Bitbucket 有以下可用的合并策略。听起来您的团队选择了“仅快进”或“壁球，仅快进”。如果 PR 没有完全变基，这将拒绝它，并且正如您所注意到的，当 PR 排队时这很烦人。

如果您想保留干净的历史记录图并且也没有合并提交（我认为这是选择该选项开始的原因），那么您可以使用的其他两个选项是：“变基，快进”，或“壁球”。这些将在完成时进行变基，并且如果它们在排队，则不应阻止请求。

旁注：我个人更喜欢其他一些工具所称的“半线性合并”，它相当于 BitBucket 选项“Rebase，merge”。这会强制合并提交，这很好，因此您可以查看与该 PR 关联的所有提交，并使您能够查看显示对分支--first-parent所做的实际更改的历史记录。master但是，在你的情况下，如果每个人都为每个 PR 压缩到一个单一的提交，那么可能对你来说几乎没有价值收益。但是，如果您决定在单个 PR 中允许多次提交，那么它可能会朝那个方向倾斜。

推荐阅读