0

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

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

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

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

  2. 新feature的完成并合并在release-2.0.

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

在这一点上，我们认为有两种可能的情况：

  1. 我们 rebaserelease-2.0以master带来错误修复和修复冲突（丢弃现在无关的错误修复代码）。最终release-2.0，master当版本准备好时，我们会合并。

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

解决方案 #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？

4

2 回答 2

0

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

* 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 这样的“经过验证的”分支模型，所以我认为你走在正确的轨道上，试图找出适合你的需求。更多阅读请参见：

于 2017-08-04T05:48:54.980 回答
0

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

除了您列出的解决方案 1 和解决方案 2 之外，还有另一种方法可以将模块 A 的更改从 应用master到release-2.0。即直接从to签出相关文件，然后提交更改masterrelease-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(minor) 表示我们修复错误或客户在审核时需要少量更改你所做的工作。

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

此外，您还可以参考另一个不同的分支模块：在develop分支上工作 -> 完成工作时 -> 合并develop到release分支中 ->release分支被批准/审核后 -> 合并release到master分支中 -> 在标签中记录发布版本。

于 2017-08-04T02:00:44.090 回答