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。

处理这种情况的正确方法是什么？我们是否应该恢复与该功能相关的所有提交，这些提交是在release-2.0中完成的，并带有诸如"恢复功能 X - 推送回 3.0"之类的消息，然后将feature合并到release-3.0？

Answer 1

首先，如果您在release-2.0和master分支中都更改了模块 A，并且您希望将模块 A 在master上的更改应用于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(主要(代表客户要求的主要/重大更改，y(次要(表示我们修复错误或客户在审查您所做的工作时需要很少的更改。

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

此外，您还可以参考另一个不同的分支模块：在develop分支上工作 -完成工作时> ->develop合并到release分支中 -> 在release分支获得批准/审查后 ->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 将改为您的"主干"，您的所有工作都合并到其中，而当前生产代码将始终有一个标记，如果您需要修补程序，您可以从中签出。

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

• Git 合作 - 从花哨到实用
• GitFlow 被认为是有害的
• trunkbaseddevelopment.com