具有不同环境的自定义 Git 工作流？

Question

我的问题是理论/程序问题。我正在尝试找出/构建一个适合我们组织的自定义 Git 工作流（不要与 Git 流混淆）。

我们正在使用 GitLab（但这不是那么重要）并且有以下 3 个长期存在的分支：

• development（最新稳定代码库）
• staging（自动部署到登台服务器）
• master（自动部署到生产服务器）

development、staging 和 master 分支是受保护的，这意味着开发人员只能合并到它们，但不能推送。此外，在合并期间，为了更清晰的 Git 日志，强制执行 rebase（仅 FF）和 squash-merge。

对于每个功能/错误修复，都会根据development 创建一个新功能分支，并在准备好后合并回各自的分支。

但是问题来了，我们想要很好地控制合并到 3 个长寿分支中的内容。例如，仅仅因为某些功能被开发并与development 合并，并不意味着我们希望它在master 中，至少在我看来很难实现。

这是一个示例场景：

• 开发人员基于development 创建了一个feature/store 分支，并随着时间的推移完成它
• 他们将其变基为 development 并将其合并为 development 和 staging
• 之后，名为feature/add-footer-menu 的新功能开发开始。这个分支也是基于development，一旦完成，他们将其合并到development、staging和master，因为它需要立即上线

棘手的部分是这样feature/store 的更改也会生效，我们不希望这样。唯一的解决方法是只使用cherry-picks，并且只选择我们想要与staging 和master 合并的提交。这可能会奏效，但在我看来是一种矫枉过正。有没有更简单的流程来实现这一点？

主要目标是对上线的内容进行良好的控制。通常development 和staging 会有相同的commit，但只有特定的功能需要去master。

另外，还有一件事。如果我们执行上述操作，这意味着如果我们想要将一个特性分支合并到 3 个长期存在的分支中，这意味着我们需要拥有各自的特性分支，这样我们就可以对它们进行 rebase 和合并。 3 个长寿命分支 = 3 个短寿命特征分支，仅用于合并。如果不是 Git 专家，这看起来不对。

请分享您的想法和建议。谢谢！

Answer 1

我建议您考虑一下 Git 维护人员使用的工作流程，称为 gitworkflows。 （有时也称为 gitworkflow；单数，不带 's'。）Additional reading here.

我根据要求提出此建议：

通常development 和staging 会有相同的提交，但只有特定功能需要转到master。

在您决定将功能分支 PR 完成到 master 之前，基本上您有两个级别的集成分支。

可能对您的工作流程进行调整：

1. 将您的development 分支（或实际重命名）视为pu（建议更新）或seen（他们现在这样称呼它）。这是集成测试的第一级。
2. 将您的staging 分支（或实际重命名）视为next。这是用于部署到暂存系统的强化集成分支。
3. 开发人员应从master 分支，而不是development（或seen）。
4. 开始将您的development 和staging 分支视为一次性分支，这些分支将定期重置为master。如果你不这样做，你最终会得到很多未合并的代码污染你的测试环境。在我的公司，我们每周日都会重置 next 分支，有时会更频繁，尤其是在我们考虑恢复已恢复的 PR 时。

注意事项：

1. 你实际上用你的development 分支做什么？如果答案是什么都没有（它没有部署在任何地方）并且以前仅用于开发人员使用的分支点，也许您可​​以将其删除。然后从master 分支出来并通过合并到staging 进行测试。
2. 关于将功能分支重新定位和合并到每个目标分支的问题，您不再需要为development 和staging 这样做。原因是一次性分支不需要干净的历史记录。不过，您仍然希望重新定位到最新的master，并且您在staging 中的最终测试如果最近被重置，或者已经拥有最新的master，或者您对staging 的PR 可能包括来自的那些新提交master 这样您就可以测试与他们的集成。

最后的想法：

分支策略很少是一刀切的。您可能不可避免地希望使用对您的存储库和您的团队有意义的不同工作流程的一部分。例如，我公司的一些团队将稍作修改的 Git Flow 与 gitworkflow 结合使用。我们有一个next 分支，它是develop 分支的前导，因此我们可以在代码进入develop 之前进行一些集成测试。原因是在 Git Flow 中，所有位于 develop 的代码最终都会进入 master 并投入生产，因此它为我们提供了额外的健全性检查。有些人认为 Git Flow 太复杂了，我们可以说它变得更加复杂，但它对我们来说非常有用。