适合我公司所有开发团队的Git分支策略

问题描述

• 我们在Github上有一个单一的存储库，多个团队通过基于master创建新分支并创建有关功能/错误修正的拉取请求来代替master。
• 尽管如此，对于我的团队而言，大多数时候（尽管不是总是如此），我们从事的工作无法直接合并到母版上，因为这要经过产品经理的批准和客户的批准，这可能需要一段时间才能实施，而我们工作的Epic需要很长的时间才能交付（通常需要4周的开发时间，而审核/调整需要1周的时间），因此需要多个团队成员来完成不同的工作。
• 为了能够采用这样的分支策略，我们目前的工作如下：
• 我们创建一个名为“ releases / *” 的新分支，该分支将成为我们的分支，可以合并到master（意味着正式投入生产）
• 我们基于 releases / *分支创建子分支，这些分支通过拉取请求合并为“ releases / *分支”。这样，多个人可以同时处理史诗般的任务，这意味着 releases / *分支将分支出多个分支。
  • 这使我们能够以较小的阶段来审查史诗的各个方面，而不是立即审查巨大的Pull Request。
• 一旦一切顺利，并合并到 releases / *分支，我们将 releases / *分支合并到master，这意味着Epic已完成，更改是直播。

请看下面的图表以直观了解

这种方法存在的问题：

• 在基于 releases / *分支的子分支中工作时，有时我们需要从同一级别的另一个子分支进行更改，并且我们会不断地挑选这些更改我们可能需要能够处理自己的任务。那是唯一的方法，还是有更好的方法？

• 在CI测试的 releases / *分支上，我们没有分支保护。

  • 当测试失败时，我们可以将合并请求从子分支意外合并到 releases / *分支。我们尝试在 releases / *分支中添加分支保护，以便为通过的CI测试提供保护，但是，一旦在Github中启用了此设置，我们将无法执行任何“推送”必需的操作到 releases / *分支（与主管理员进行基础调整以引入更改，我们需要其他团队实施该更改或进行合并提交然后再推送，等等）。
    • 从Github的分支保护设置中启用状态检查：“启用后，必须先将提交推送到另一个分支，然后在通过状态检查后，将其合并或直接推送到与该规则匹配的分支。” / strong>
    • 此^^意味着我们只能创建拉取请求，以检索从master分支到 releases / *分支的任何更改，并相应地对子分支进行重新设置。

有什么建议吗？

解决方法

Mono仓库有一些有趣的问题。您可以在方案中使用经过修改的git workflow。请仔细阅读上面的git工作流程文档，然后再阅读以更好地理解。

尝试性的改编看起来像这样。
分支机构：

• master：永恒稳定的分支
• 下一个：特定项目/史诗的集成分支
• 功能/ *：主题分支，用于单个更改

每个变更都有其自己的主题分支。为了测试和验证构建，所有单独的主题分支均按需合并到 next 分支中。这样，如果您需要一个额外的分支或提交来测试您的更改，则只需将其合并到 next 中即可。

next 分支会按固定的时间间隔（每天下午3点或每个星期一下午3点）重置为 master ，具体取决于您的总体部署和发布周期，所有团队和服务。根据您的需要，可以同时存在多个 next 分支（一个分支用于更频繁的日常更改，而每个长期运行的项目或史诗则有多个）。您还可以设置一些自动化功能来标记一组已复审并接受的主题分支，以便它们自动合并到项目或史诗的 next 分支中。

然后，您可以在所有 next 分支上启用Github分支保护，因为更改只能通过PR到达。按照git工作流程，您可以从集成分支（ next ）进行部署，并将主题分支直接合并到 master 。为了使事情无缝地工作，这将需要一定的纪律，甚至可能实际上需要某种自动化。您可能还必须更改部署管道以适应此类更改。最后但并非最不重要的一点是，您可能还需要改变开发人员的思维方式，不再以git flow来思考。