如何在层次结构中组织修订？

Question

当使用版本控制时，历史记录通常看起来像一个扁平的修订链。有一些组织层次结构的基本机制(我指的是分支)，但它看起来不够灵活。有哪些常见的实践(版本控制不可知论者)来组织多层次层次结构中的修订，以及版本控制工具特有的问题是什么？

我将从我的实践中提供一个琐碎的现实世界的例子，这将引导我提出这个问题。

假设我想重构一个函数/类方法。我创建了一个票据，并将其命名为“重构方法ClassName.method_name()”。在研究method_name()，代码的基础上，将重构过程划分为子任务。为了简单起见，让我们考虑一下，我需要在代码中重命名两个具有不同含义的变量，所以我需要在两个不同的原子步骤中这样做。我重命名一个变量，保存更改并使用消息提交“重命名为ClassName.method_name()中的foo变量”(因为早期提交和提交通常是好的)。我重复第二个变量：“重命名为ClassName.method_name()中的bar变量”。

现在，我在问题跟踪器中有了一张票据，名为"Refactor method ClassName.method_name()“，以及版本控制的两个修订版：

• “在ClassName.method_name()中重命名foo变量”
• “在ClassName.method_name()中重命名bar变量”

该问题与这两次修订之间的关系如何？我迷路了!

我的目标是建立这样的逻辑层次：

• “重构方法ClassName.method_name()”
  • “在ClassName.method_name()中重命名foo变量”
  • “在ClassName.method_name()中重命名bar变量”

​

不用说，我正在寻找通用工作流，这将允许创建像这样的多层次层次结构。层次结构中的每一项都可以是修订或票证，通过一系列连续修订来固定票证的情况只是一种特殊情况。

这将是合理的，我是一个球迷使用外线和组织数据的层次结构使用树。

人们是如何在版本控制中做到这一点的？有许多版本控制工具，每个工具都有其微妙之处，有些允许将第三方bug跟踪器直接包含到存储库中，有些甚至有集成的bug跟踪(如化石)，因此请详细说明特定版本控制工具的工作流。

Answer 1

您想要的是特性分支，这是一个非常常见的分布式版本控制工作流。举个例子，它应该是这样的：

• 从主干中创建一个名为“重构方法”的分支。
• 从您的“重构方法”分支创建一个名为"rename“的分支。
• 做您所有的工作，重命名foo，提交到“重命名foo”分支。
• 将“重命名foo”合并回“重构方法”。
• 从您的“重构方法”分支创建一个名为"rename bar“的分支。
• 做你所有的工作重命名吧，提交到“重命名栏”的分支，随着您的前进。
• 将“重命名栏”合并回“重构方法”。
• 将“重构方法”合并回您的主干。

用图形工具显示主干分支只会显示带有加号或展开它的“重构方法”，有点像这样：

​

。单击加号将显示“重命名foo”和“重命名栏”。再次单击将显示所有单独的步骤。而且，工作可以并行进行，人们签入的顺序与他们签出的顺序不同，您仍然可以得到分层历史记录。在我的图形中，你可以看到阿诺德在艾米分叉去找她的零钱后，签下了他的bug修复程序，但历史仍然有效。