Question

首先，我想

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

分支策略：

我有一个master分支和一个integration分支。
按任务/问题从master分支。
当任务分支完成其工作时，将其合并到integration以查看它是否已破坏其他任务分支的任何工作。如果是，请修复它们。
将请求从任务分支（非integration分支）拉到master分支。

这意味着integration分支仅用于CI目的，它永远不会合并到master
确定下一个版本将包含哪些更改。将这些分支合并到master。
推出。

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

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

在F中，会发生两件事：

合并冲突发生在C和F改变了同一行some-code.js
F打破了C的一些测试。

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

选项1

将integration合并为bob/task#2 <{1}}
修复G
合并为H integration
I绿色
提取请求
```
integration
```

但是，通过这种方法，我不能只选择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中在一起。

选项2

切换回master
尝试修复bob/task#2
合并到G并运行测试以查看测试是否为绿色
如果没有，请切换回integration
尝试在bob/task#2
合并到I并运行测试

...

在integration为绿色之前。
提取请求
```
integration
```

此方法可防止将master -*----------------- |\ integration -+-\-------C---F---H---J--- .......... | \ / / / / ken/task#1 | A---B / / / | / / / bob/task#2 D---------E---G---I--- ..............的更改捆绑到ken/test#1。

然而，Bob现在需要“猜测”他需要做些什么来修复bug。然后一遍又一遍地合并到bob/task#2以查看测试是否为绿色，因为integration和G现在没有在I中添加测试。

他还需要解决相同的C合并冲突，每次将他的工作合并到some-code.js，这是痛苦和多余的。

鲍勃有更好的选择3吗？

感谢。

Answer 1

您应该考虑遵循Git流程：

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

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

开发人员创建功能/错误修复分支并提交拉取请求以将其更改合并到Integration分支。
关于哪些功能将成为发行版的决定应该之前将更改集成到Integration分支中 - 而不是之后。将功能合并到集成分支后，它就会发布，并且已确定订单（将功能应用到集成分支中的顺序）。
当您查看拉取请求并确定它将使其成为版本时，您应该查看更改集以查看它是否可以合并为快进合并，是否会导致干净的合并提交，或者是否存在合并冲突。
如果存在合并冲突，您应该建议开发人员将他们的更改重新定位到Integration分支的顶端。这会产生干净的提交历史记录和更稳定的集成分支，因为冲突解决方案发生在开发分支以及最熟悉代码库的开发人员。
从开发分支到Integration分支的合并应该是干净的：没有合并冲突，只是快进合并和/或清理合并提交。 Integration集上不应该发生冲突解决！
一旦您准备好发布，请从Integration分支创建一个预发布分支（此分支是一个发布分支，它将比开发分支更长时间以稳定发布）。只有修复进入预发布分支。
当预发布分支准备好进行生产时，将预发布分支合并回主分支（这将是快进合并），同时将同一分支合并到Integration中。借此机会将提交压缩为单个提交，以便您在master上拥有更清晰的提交历史记录。
合并到集成或主分支后，清理分支：合并到集成后删除dev分支;合并到master后删除预发布分支。
使用语义版本控制策略标记生产版本。创建一个官方发布分支以支持未来的修复。
当您在发布分支上发现问题时，请按照与开发新功能相同的过程来解决问题（步骤1-5）。使主分支上的修复优先于在发布分支上修复问题。一旦修复，樱桃挑选修复分支。
热修复策略不同。对于热修复，请从master的分支中应用修复，然后将修复程序选择到Integration分支。

总结一下，我建议的主要观点是：

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

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

在此处了解详情： http://scottchacon.com/2011/08/31/github-flow.html

用于敏捷开发的Git分支

1 个答案: