敏捷开发的Git分支

Question

首先，我想

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

分支战略：

1. 我有一个master分支和一个integration分支与它一起运行。
2. 根据任务/问题从master中分离出来。
3. 当任务分支完成其工作时，将其合并到integration中，以查看它是否破坏了其他任务分支的任何工作。如果是的话，就把它们修好。
4. 将请求从task-branch(not 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中的错误
3. 合并为integration作为I
4. integration绿
5. 拉请求 硕士-*/\/bob/任务2 D

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

选项2

1. 切换回bob/task#2
2. 尝试修复G中的错误
3. 合并到integration中并运行测试，以查看测试是否为绿色
4. 如果没有，切换回bob/task#2
5. 尝试在I中修复它
6. 合并到integration并运行测试 ..。 直到integration变成绿色。
7. 拉请求 师父*？\//ken/任务#1\x{e76f}A-B/AC.26/bob/任务#2D

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

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

每次他将自己的工作合并到integration中时，他都需要解决同样的integration合并冲突，这是痛苦和多余的。

鲍勃有更好的选择3吗？

谢谢。

Answer 1

您应该考虑遵循Git流：

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

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

1. 开发人员创建特性/bug修复分支，并提交拉请求将他们的更改合并到集成分支中。
2. 决定哪些特性将成为发行版应该在之前进行，然后将更改集成到集成分支中，而不是在集成之后。一旦将特性合并到集成分支中，它就注定要发布，并且订单已经确定(将特性应用到集成分支的顺序)。
3. 当您检查一个拉请求，并决定它将使它成为一个发布，然后您应该检查变更集，看看它是否可以合并为一个快速合并，它是否会导致一个干净的合并提交，或是否存在合并冲突。
4. 如果存在合并冲突，则建议开发人员将更改重新建立在集成分支的尖端上。这将产生一个干净的提交历史和一个更稳定的集成分支，因为冲突解决发生在开发分支上，并且由最熟悉代码库的开发人员解决。
5. 从开发分支到集成分支的合并应该是干净的:没有合并冲突，只是快速合并和/或清理合并提交。集成分支不应该出现冲突解决！
6. 一旦准备好发布，就在Integration分支之外创建一个预发布分支(这个分支是一个发布分支，它比开发分支活得更长以稳定发布)。只有修复进入预发布分支。
7. 当预发布分支准备好生产时，将预发布分支合并回主分支(这将是一个快速合并)，同时将同一分支合并到Integration中。利用这个机会将提交压缩为单个提交，这样您就有了一个更干净的主提交历史记录。
8. 在您合并到集成或主分支之后，清理您的分支:在合并到integration之后删除dev分支；在合并到master之后删除预发布分支。
9. 使用语义版本控制策略发布标记生产。创建一个正式的发布分支来支持未来的修复。
10. 当您在发布分支上发现一个问题时，按照与开发新特性相同的过程来解决这个问题(步骤1-5)。使在主分支上的固定优先于解决发布分支上的问题。一旦修复，樱桃-选择固定在释放分支上。
11. 热修复的策略是不同的。对于热修复，应用从主程序的分支修复，并选择修复到集成分支。

总括而言，我建议的要点是：

1. 让开发人员合并代码并在开发分支上处理合并冲突，然后将它们拖到集成分支中
2. 选择哪些拉请求(dev分支)将使其成为一个发行版。一旦决定，这些特性就注定要发布。
3. 不要将提交/更改从集成分支转到主！
4. 合并成主人应该总是快进合并。由于您有一个额外的集成分支，因此您没有理由不执行此操作。

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

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