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

Question

使用版本控制时，历史记录通常看起来像一个平面修订版链。组织层次结构有一些基本的机制（我指的是分支机构），但它看起来不够灵活。什么是常用实践（版本控制不可知）来组织多级别层次结构中的修订，以及什么是版本控制工具特定的陷阱？

我会从我的实践中提供一个微不足道的现实世界的例子，它引导我回到这个问题。

假设我想重构一个函数/类的方法。我创建一张票并命名为“重构方法ClassName.method_name（）”。在研究了method_name（）的代码之后，我将重构过程划分为子任务。为了简单起见，让我们考虑我需要在代码中重新命名具有不同含义的两个变量，所以我需要在两个不同的原子步骤中完成它。我重命名一个变量，保存更改并在消息“中重命名为ClassName.method_name（）”中的foo变量“（因为提前提交并且提交通常很好）。我重复第二个变量：“在ClassName.method_name（）”中重命名的bar变量“。

现在我有问题跟踪一票，命名为“重构方法ClassName.method_name（）”，并在版本控制两个版本：

• “在ClassName.method_name（）更名为富变量”
• “更名为ClassName.method_name酒吧变量（）”

在哪里的问题，这两个版本之间的关系？我迷路了！

我的目标是有一个这样的逻辑层次： “）重构方法ClassName.method_name（” “在ClassName.method_name）更名为富变量（”

• • “在ClassName.method_name（）更名巴变量”

氖无条件地说我正在寻找一般的工作流程，这将允许创建像这样的多级层次结构。每一层次的项目可以是一个修订版本或一张票证，一张票连续修订链固定的情况只是一个特例。

这样做很有意义，我很喜欢使用大纲和将数据组织到使用树的层次结构中。

人们在版本控制中如何做到这一点？有许多版本控制工具，每个都有他们的微妙之处，有些允许将第三方错误跟踪器直接放入存储库，有些甚至还集成了错误跟踪（如fossil），所以请详细说明特定版本控制工具的工作流程。

Answer 1

你想要什么叫做功能分支，是分布式版本控制的一个非常常见的工作流程。对于你的例子，它会像这样：

• 从你的主干创建一个名为“重构方法”的分支。
• 从名为“rename foo”的“重构方法”分支创建分支。
• 为了重命名foo，在进行“重命名foo”分支时做所有工作。
• 将“重命名foo”合并回“重构方法”。
• 从名为“重命名栏”的“重构方法”分支创建分支。
• 做你所有的重命名栏工作，在你走的时候进入“重命名栏”分支。
• 将“重命名栏”合并回“重构方法”。
• 将“重构方法”合并回您的主干。

显示与图形工具主干分支将只显示“重构法”有一个加号或东西展开，有点像这样：

。点击加号会显示“重命名foo”和“重命名栏”。再次点击会显示所有的单个步骤。此外，这项工作可以同时进行，人们以不同于检出的顺序检入，并且您仍然可以获得分层历史记录。在我的图表中，你可以看到阿诺德在艾米分流她的改变后检查了他的错误修复，但是历史仍然有效。