Geo*_*rgi 5 git merge workflow gitlab
我的问题是一个理论/程序问题。我正在尝试找出/构建一个适合我们组织的自定义 Git 工作流程（不要与 Git 流程混淆）。
我们正在使用 GitLab（但这并不那么重要）并拥有以下 3 个长期存在的分支：
development（最新稳定代码库）staging（自动部署到登台服务器）master（自动部署到生产服务器）、和分支受到保护，development这意味着开发人员只能合并到它们，而不能推送。此外，在合并期间，会强制执行 rebase（仅限 FF）和挤压合并，以获得更干净的 Git 日志。stagingmaster
对于每个功能/错误修复，都会创建一个新的功能分支，development并在准备好时合并回相应的分支。
但这是问题所在，我们希望能够很好地控制合并到 3 个长期分支中的内容。例如，仅仅因为某些功能是与 开发并合并的development，并不意味着我们希望它在 中master，事实证明这很难实现，至少从我的角度来看是这样。
这是一个示例场景：
feature/store基于 创建一个分支development，并随着时间的推移完成它development合并为developmentstagingfeature/add-footer-menu。这个分支基于developmenttoo，一旦完成，他们将其合并到development，staging并且master，因为它需要立即上线棘手的部分是，这种方式也会从上线时发生变化feature/store，而我们不希望这样。唯一的解决方法是专门使用cherry-picks，并且仅cherry-pick我们想要与staging和合并的提交master。这可能会起作用，但在我看来有点矫枉过正。是否有更简单的流程来实现这一目标？
主要目标是很好地控制上线的内容。通常development和staging会有相同的提交，但只有特定功能需要转到master.
另外，还有一件事。如果我们执行上述操作，这意味着如果我们想要将一个功能分支合并到 3 个长期存在的分支中，这意味着我们需要拥有各自的功能分支，因此我们可以对它们进行变基和合并。3 个长寿分支 = 3 个短期特征分支，仅用于合并。如果不是 Git 专家，这看起来就不对劲。
请分享您的想法和建议。谢谢你！
我建议您考虑 Git 维护者使用的工作流程，称为gitworkflows。（有时它也称为 gitworkflow；单数形式，不带 's'。）请在此处进行补充阅读。
我的建议基于以下要求：
通常
development和staging会有相同的提交，但只有特定功能需要转到master.
本质上，在决定将功能分支 PR 完成到master.
对您的工作流程可能进行的调整：
development分支（或实际重命名）视为pu（建议的更新）或seen（他们现在称之为）。这是集成测试的第一级。staging分支（或实际重命名）视为next. 这是用于部署到登台系统的强化集成分支。master用 来代替development(或seen)。development和staging分支视为一次性分支，并将master定期重置。如果您不这样做，您最终将得到大量未合并的代码，从而污染您的测试环境。在我的公司，我们next每周日都会重置分支，有时甚至更频繁，特别是当我们考虑恢复已恢复的 PR 时。注意事项：
development？如果答案是什么（它没有部署在任何地方）并且之前只是作为开发人员使用的分支点，也许你可以删除它。master然后通过合并到进行分支并进行测试staging。development和执行此操作staging。原因是一次性分支不需要干净的历史记录。不过，您仍然希望重新建立最新版本master，并且您的最终测试staging要么已经拥有最新版本master（如果最近重置），要么您的 PRstaging可能包含这些新提交，master以便您可以测试与它们的集成。最后的想法：
分支策略很少是一刀切的。您可能不可避免地想要使用对您的存储库和团队有意义的不同工作流程的一部分。例如，我公司的一些团队将稍微修改过的 Git Flow 与 gitworkflows 结合使用。我们有一个next分支是我们分支的前体develop，因此我们可以在代码进入develop. 原因是在 Git Flow 中，所有输入的代码develop最终都会进入master生产环境，因此它为我们提供了额外的健全性检查。有些人认为 Git Flow 太复杂了，我们可以说它变得更加复杂，但它对我们来说非常有用。