适用于我公司所有开发团队的 Git 分支策略
Posted
技术标签:
【中文标题】适用于我公司所有开发团队的 Git 分支策略【英文标题】：Git Branch Strategy that suites for all the dev teams at my company 【发布时间】：2021-01-18 15:59:09 【问题描述】： 我们在 Github 上有一个单一存储库，多个团队通过基于 master 创建新分支并创建有关功能/错误修复等的拉取请求来脱离 master。 但是，对于我的团队来说，大多数时候（尽管并非总是如此），我们所做的事情并不能直接合并到 master 上，因为它需要经过产品经理的批准和客户的批准，这可能需要一段时间才能实施，而我们工作的 Epics 需要很长时间才能交付（通常需要 4 周的开发和 1 周的审核/调整），因此需要多个团队成员来处理不同的部分。 为了能够采用这样的分支策略，我们目前的工作如下： 我们创建一个名为 “releases/*” 的新分支，它成为我们要合并到 master 的分支（意味着上线到生产） 我们基于 releases/* 分支创建子分支，这些分支通过拉取请求合并到“releases/* 分支”。这样，多人可以同时处理史诗任务，这意味着 releases/* 分支将有多个子分支。 这使我们能够以这种方式在更小的阶段审查史诗的各个方面，而不是一次审查巨大的拉取请求。 一旦一切顺利并合并到releases/*分支，我们将releases/*分支合并到master，这意味着Epic完成了，变化是直播。请看下图直观了解
我们在使用这种方法时遇到的问题：
在基于 releases/* 分支的子分支中工作时，有时我们需要从同一级别的另一个子分支进行更改，并且我们会不断挑选我们可能需要的更改能够完成我们自己的任务。这是唯一的方法，还是有更好的方法？
对于 CI 测试，我们在 releases/* 分支上没有分支保护。
当测试失败时，我们可能会意外地将拉取请求合并到子分支的 releases/* 分支。我们尝试将分支保护添加到 releases/* 分支，以便保护它们以防止通过 CI 测试，但是，一旦我们在 Github 中启用此设置，我们就无法执行任何“推送”所需的操作到 releases/* 分支，（与 master 重新绑定以提取我们需要其他团队实施的更改或进行合并提交然后推送等） 来自 Github 的用于启用状态检查的分支保护设置：“启用后，必须先将提交推送到另一个分支，然后在状态检查通过后合并或直接推送到与此规则匹配的分支。” 这个 ^^ 意味着我们只能创建一个拉取请求来检索从主分支到 releases/* 分支的任何更改，并相应地重新设置子分支。有什么建议吗？
【问题讨论】：
【参考方案1】：Mono 存储库带有自己有趣的问题。您可以在您的场景中使用修改后的 git workflow。请仔细阅读上面的 git 工作流文档，然后再进一步阅读以更好地理解。
试探性的改编可能如下所示。 分行：
master：永恒稳定的分支 下一步：特定项目/史诗的集成分支 feature/* : 个别更改的主题分支每个单独的更改都有自己的主题分支。为了测试和验证构建，所有单独的主题分支都根据需要合并到 next 分支中。这样，如果您需要一个额外的分支或提交来测试您的更改，您只需将其合并到 next 中即可。
next 分支会在固定时间间隔（每天下午 3 点或每周一下午 3 点）由 master 重置，具体取决于您的整体部署和发布周期，跨所有团队和服务。根据您的需要，可能有多个 next 分支，同时共存（一个用于更频繁的日常更改，而对于每个此类长期运行的项目或史诗，还有几个）。您还可以设置一些自动化来标记一组已被审查和接受的主题分支，以便它们自动合并到您的项目或史诗的 next 分支中。
然后您可以在所有 next 分支上启用 Github 分支保护，因为更改只能通过 PR 到达它们。根据 git 工作流程，您从集成分支 (next) 部署并将主题分支直接合并到 master。这将需要一些纪律，也许实际上需要一些自动化，才能让事情无缝地工作。您可能还必须更改部署管道以适应此类更改。最后但并非最不重要的一点是，您可能还需要改变开发人员的思维方式，不再使用git flow。
【讨论】：
以上是关于适用于我公司所有开发团队的 Git 分支策略的主要内容，如果未能解决你的问题，请参考以下文章