Git 分支模型：几个问题

Question

我们几乎已经确定了一个分支模型，其中我们有一个代表生产代码的 master 分支和一个代表未来版本的 release-x.x 分支。

但是，我们不确定如何有效解决一些情况：

实时错误修复与当前版本无关

1. 一个新的feature 是release-2.0 的分支，并完全重写了模块A。

2. 新的feature完成并合并到release-2.0中。

3. 在 master 上发现并修复了当前直播模块 A 中的错误。

此时我们认为有两种可能的情况：

1. 我们将 release-2.0 重新设置为 master 以带来错误修复和修复冲突（丢弃现在不相关的错误修复代码）。最终，当发布准备就绪时，我们将 release-2.0 合并到 master 中。

2. 我们只挑选与发布相关的错误修复到release-2.0，当发布准备好时，我们用release-2.0历史覆盖整个master历史。

解决方案 #1 迫使我们解决合并冲突，我们知道不需要提交，但解决方案 #2 迫使我们擦除整个 master 分支，并在每个版本中将其替换为 release-2.0 分支的历史记录。这带来了丢失我们忘记在release-2.0 上挑选的错误修复的小概率，并且还可能破坏在发布之前由master 分支的正在进行的错误修复。

一个功能最终没有进入发布

1. 我们创建一个新的feature，基于release-2.0 并将其合并到release-2.0 和--no-ff。
2. 发现了一些错误，因此我们在feature 上修复它们并重做上述合并过程。
3. 客户再次查看该功能并决定他们想要更改许多内容 - 没有这些内容，该功能没有任何价值，但我们无法为release-2.0 进行这些更改，并且必须等到release-3.0。

处理这种情况的正确方法是什么？我们是否应该使用诸如“Revert feature X - push back to 3.0”之类的消息来恢复与release-2.0 中完成的功能相关的所有提交，然后将feature 合并到release-3.0？

Answer 1

首先，如果您在release-2.0 和master 分支中都更改了模块A，并且您想将master 上的模块A 的更改应用到您的release-2.0 分支。

除了您列出的解决方案 1 和解决方案 2，还有另一种方法可以将模块 A 的更改从 master 应用到 release-2.0。即直接从master 到release-2.0 签出相关文件，然后提交更改。详细步骤如下：

git checkout release-2.0
git checkout master /path/to/moduleA  
# Such as git checkout master moduleA/*
# Now module A is what you changed in master
git commit

其次，对于大多数情况，如果您使用版本格式为x.y（major.minor），x（major）代表客户要求的主要/重大更改，并且y（次要）表示我们修复了错误，或者客户在审核您所做的工作时需要进行少量更改。

因此，如果您的客户在查看 2.0 版本时要求进行重大更改，您可以将项目开发为 3.0 版本。完成工作后，您的客户将审查 3.0 版本。如果他们报告 3.0 版本的错误或微小更改，您可以将版本更改为 3.1（将您的 release-3.0 分支重命名为 release-3.1 或在完成更改后添加标签 3.1）。

除此之外，还有another different branching module可以参考：在develop分支上工作->完成工作时->将develop合并到release分支->在@987654339之后@分支被批准/审核 -> 合并release 到master 分支 -> 在标签中记录发布版本。

Answer 2

我建议使用标签而不是分支来表示生产中的内容。这样，您可以简单地签出一个新的修补程序分支并修复您的错误，然后直接部署此提交并将其标记为当前的生产代码，如果您知道下一个版本会更改所有内容，则无需将其合并回来。

* 54c82e0 - (HEAD -> master) Commit6
* bb6db8e - Commit5 
* 5156c9f - Commit4 
| * 630a150 - (tag: v1.1) Hotfix commit 
|/
* db5c984 - (tag: v1.0) Commit3 
* 00c6c5c - Commit2 
* 715412a - Commit1 

您将使用您计划的分支模型，但 master 将成为您的“主干”，您的所有工作都将合并到其中，而当前的生产代码将始终有一个标签，您可以从中签出 if你需要修补程序。

我会谨慎选择像 GitFlow 这样的“经过验证的”分支模型，所以我认为你走在正确的轨道上，试图找出适合你的需求。更多阅读请参见：

• Git Cooperation - From fancy to Functioning
• GitFlow considered harmful
• trunkbaseddevelopment.com