问题描述
我的问题是一个理论/程序问题。我正在尝试找出/构建一个适合我们组织的自定义Git工作流(不要与Git Flow混淆)。
我们使用的是GitLab(但这并不重要)，并且有以下3个长期存在的分支：
development(最新稳定代码库)staging(自动部署到临时服务器)master(自动部署到生产服务器)
development、staging、master分支受保护，开发者只能合并，不能推送。此外，在合并过程中，为了获得更干净的Git日志，会强制执行REBASE(仅FF)和Squash-Merge。
对于每个功能/错误修复，都会基于development创建一个新的功能分支，并在准备好后合并回相应的分支。
development合并，并不意味着我们希望在master中实现它，事实证明，这很难实现，至少从我的角度来看是这样。以下是一个场景示例：
- 开发人员根据
development创建feature/store分支，并随时间推移完成 - 他们将其重定位为
development，并将其合并为development和staging - 之后，名为
feature/add-footer-menu的新功能开发开始。此分支也基于development，一旦完成，他们将其合并到development、staging和master，因为它需要立即上线
feature/store中的更改也会生效，而我们不希望发生这种情况。解决这个问题的唯一方法是专门使用Cherry-Pick，并且只选择我们想要与staging和master合并的提交。这可能会奏效，但在我看来，这有点过头了。是否有更简单的流程来实现这一点？主要目标是很好地控制活动内容。通常development和staging将具有相同的提交，但只有特定功能需要转到master。
还有一件事。如果我们执行上述操作，这意味着如果我们想要将一个功能分支合并到3个长期存在的分支中，这意味着我们需要拥有各自的功能分支，所以我们可以重新基址并合并它们。3个长期存在的分支=3个短暂的特色分支，仅用于合并。如果不是Git专家，这看起来就不对劲。
请分享您的想法和建议。谢谢！
推荐答案
我建议您考虑一下Git的维护者使用的工作流，它被称为gitworkflows。(有时也称为GitWorkflow；不带"s"的单数。)Additional reading here.
我的建议基于以下要求：
基本上，在您决定将功能分支PR完成为master之前，您有两个级别的集成分支。
可能对您的工作流进行的调整：
- 将
development分支视为(或实际重命名)为pu(建议的更新)或seen(他们现在这样称呼它)。这是集成测试的第一级。 - 将
staging分支视为next(或实际将其重命名)。这是您用于部署到临时系统的强化集成分支。 - 开发者应该从
master分支，而不是development(或seen)。 - 开始将
development和staging分支视为将被定期重置为master的一次性分支。如果您不这样做，最终会有大量未合并的代码污染您的测试环境。在我的公司，我们每个星期天重置next分支，有时甚至更频繁，特别是当我们正在考虑恢复恢复的公关时。
注意事项：
- 您实际如何处理
development分支？如果答案是Nothing(它没有部署在任何地方)，并且以前只用于供开发人员使用的分支点，也许您可以直接删除它。然后从master分支并合并到staging进行测试。 - 关于将功能分支重新基址并合并到每个目标分支的问题，您不再需要对
development和staging执行此操作。原因是，一次性树枝不需要有干净的历史。不过，您仍然希望重新定位到最新的master，并且您在staging中的最终测试可能已经具有最新的master(如果最近重置)，或者您进入staging的PR可能包含来自master的那些新提交，以便您可以测试与它们的集成。
最终想法：
分支策略很少是一刀切的。不可避免地，您可能希望使用对您的repo和您的团队有意义的不同工作流的部分。例如，我公司的一些团队将略微修改的Git流与GitWorkflow结合使用。我们有一个next分支，它是develop分支的前置光标，因此我们可以在代码进入develop之前进行一些集成测试。原因是，在Git Flow中，所有位于develop中的代码最终都会进入master并投入生产，因此它为我们提供了额外的健全性检查。有些人认为Git Flow太复杂了，我们可以说把它做得更复杂了，但它对我们很有效。
这篇关于不同环境下的定制Git工作流？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！