用于敏捷开发的 Git 分支

Question

首先，我想

1. 让我的 master 分支始终保持绿色。
2. 能够为下一个版本挑选更改。

分支策略：

1. 我有一个 master 分支和一个 integration 分支与它一起运行。
2. 按任务/问题从master 分支。
3. 当一个任务分支完成其工作时，将其合并到integration 以查看它是否破坏了其他任务分支的任何工作。如果是，请修复它们。

4. 从task-branch（不是integration 分支）拉取请求到master 分支。

   这意味着 integration 分支仅用于 CI 目的，它永远不会合并到 master

5. 决定下一个版本将包含哪些更改。将这些分支合并到master。
6. 发布。

这就是问题所在，假设我有以下情况：

master       -*-----------------
              |\
integration  -+-\-------C---F---
              |  \     /   /
ken/task#1    |   A---B   /
              |          /
bob/task#2    D---------E

在F 中，发生了两件事：

1. 发生合并冲突，因为C 和F 更改了some-code.js 的相同行
2. F 打破了来自 C 的一些测试。

现在，Bob 必须解决这个问题，他有两个选择：

选项 1

1. 将integration 合并为bob/task#2 为G
2. 修复H中的Bug
3. 合并到integration 为I
4. integration绿色

5. 拉取请求

   master       -*--------------------------
                 |\
   integration  -+-\-------C---F-----------I
                 |  \     /   / \         /
   ken/task#1    |   A---B   /   \       /
                 |          /     \     /
   bob/task#2    D---------E-------G---H
   

但是，通过这种方法，我不能只选择 task#2 包含在我的下一个版本中。 因为 bob/task#2(H) 已经包含在 ken/task#1 中所做的更改，所以将 bob/task#2 合并到 master 意味着将 ken/task#1 合并到 master 中。

选项 2

1. 切换回bob/task#2
2. 尝试修复G中的bug
3. 合并到integration 并运行测试以查看测试是否为绿色
4. 如果没有，请切换回bob/task#2
5. 尝试在I中修复它

6. 合并到integration并运行测试

   ...

   直到integration 变为绿色。

7. 拉取请求

   master       -*-----------------
                 |\
   integration  -+-\-------C---F---H---J--- ..........
                 |  \     /   /   /   /
   ken/task#1    |   A---B   /   /   /
                 |          /   /   /
   bob/task#2    D---------E---G---I--- ..............
   

此方法可防止将更改从 ken/test#1 捆绑到 bob/task#2。

但是，Bob 现在需要“猜测”他需要做什么来修复错误。然后一遍又一遍地合并到integration 中，看看测试是否为绿色，因为G 和I 现在没有在C 中添加测试。

每次他将自己的工作合并到integration 时，他还需要解决同样的some-code.js 合并冲突，这既痛苦又多余。

Bob 有更好的选择 3 吗？

谢谢。

Answer 1

您应该考虑遵循 Git 流程：

https://www.atlassian.com/git/tutorials/comparing-workflows

以下是我对如何与 Git 流开发模型保持一致的想法：

1. 开发人员创建功能/错误修复分支并提交拉取请求以将其更改合并到集成分支中。
2. 应在将更改集成到集成分支之前（而不是之后）决定将哪些功能纳入发行版。将功能合并到集成分支后，它就注定要发布，并且顺序已确定（您将功能应用到集成分支的顺序）。
3. 当您审查拉取请求并决定将其发布到版本中时，您应该审查变更集以查看它是否可以合并为快进合并，是否会导致干净的合并提交，或者是否存在合并冲突。
4. 如果存在合并冲突，您应该建议开发人员将他们的更改重新基于集成分支的尖端。这会产生干净的提交历史和更稳定的集成分支，因为冲突解决发生在 development 分支上，并且由最熟悉代码库的开发人员完成。李>
5. 从开发分支到集成分支的合并应该是干净的：没有合并冲突，只是快进合并和/或干净的合并提交。集成分支上不应发生冲突解决！
6. 一旦您准备好发布，请从集成分支创建一个预发布分支（此分支是一个发布分支，它的寿命将比开发分支更长，以稳定发布）。只有修复进入预发布分支。

7. 当预发布分支准备好用于生产时，将预发布分支合并回主分支（这将是快进合并），同时将同一分支合并到集成中。借此机会将提交压缩为单个提交，以便您在 master 上拥有更清晰的提交历史记录。

8. 合并到integration或master分支后，清理分支：合并到integration后删除dev分支；合并到 master 后删除 pre-release 分支。

9. 使用语义版本控制策略标记生产版本。创建一个正式发布分支以支持未来的修复。

10. 当您在发布分支上发现问题时，请按照与开发新功能相同的过程来解决问题（步骤 1-5）。修复主分支优先于修复发布分支的问题。修复后，将修复挑选到发布分支上。

11. 热修复的策略不同。对于热修复，请从 master 的分支应用修复，然后将修复精选到集成分支上。

总而言之，我推荐的要点是：

1. 在将开发分支拉入集成分支之前，让开发人员在开发分支上合并代码并处理合并冲突
2. 选择哪些拉取请求（开发分支）将使其成为一个版本。一旦决定，这些功能就注定要发布。
3. 不要从集成分支中挑选提交/更改到主分支！
4. 合并到 master 应该总是是快进合并。由于您有一个额外的集成分支，因此您没有理由不想强制执行此操作。

Git Flow 非常适合大中型项目。但我实际上更喜欢将 GitHub Flow 用于较小的项目，特别是如果我正在为 Web 开发组件库。

在此处了解更多信息： http://scottchacon.com/2011/08/31/github-flow.html