小编Geo*_*rgi的帖子

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

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

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

、和分支受到保护，development这意味着开发人员只能合并到它们，而不能推送。此外，在合并期间，会强制执行 rebase（仅限 FF）和挤压合并，以获得更干净的 Git 日志。stagingmaster

对于每个功能/错误修复，都会创建一个新的功能分支，development并在准备好时合并回相应的分支。

但这是问题所在，我们希望能够很好地控制合并到 3 个长期分支中的内容。例如，仅仅因为某些功能是与 开发并合并的development，并不意味着我们希望它在 中master，事实证明这很难实现，至少从我的角度来看是这样。

这是一个示例场景：

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

棘手的部分是，这种方式也会从上线时发生变化feature/store，而我们不希望这样。唯一的解决方法是专门使用cherry-picks，并且仅cherry-pick我们想要与staging和合并的提交master。这可能会起作用，但在我看来有点矫枉过正。是否有更简单的流程来实现这一目标？

主要目标是很好地控制上线的内容。通常development和staging会有相同的提交，但只有特定功能需要转到master.

另外，还有一件事。如果我们执行上述操作，这意味着如果我们想要将一个功能分支合并到 3 个长期存在的分支中，这意味着我们需要拥有各自的功能分支，因此我们可以对它们进行变基和合并。3 个长寿分支 = 3 …