代码之家 › 专栏 › 技术社区 › Tom Kidd

当您计划在将来进行重写时,如何处理分支?

branch tfs version-control

Tom Kidd · 技术社区 · 16 年前

我的开发团队很快就要分支了——我们已经被SoScCuFe诅咒了,我们要搬到Team Foundation Server了,我对一些事情很好奇。

传统上,当我们对产品进行重大修改时,即使文件夹结构或文件名都不保持不变,我们也会在源代码管理中创建一个新的根文件夹。

例如

$/V1.0
$/V1.1
$/V1.5
$/V2.0

诸如此类。

我对分支是全新的,我读到的一件事是,你可以为你的产品的不同版本使用不同的分支。现在,当您谈论对代码进行修补、小的更改或修改时(最坏情况下,您可能会添加新文件),这是有意义的。

但是,当您执行产品的“v-next”版本时,您计划或多或少地对产品进行完全重写。( not from scratch ,但不是彻底地改写它),到了文件夹结构和文件名可能完全不同的程度,这仍然是您希望通过分支来做的事情吗?或者您想创建一个新的根目录($/v2.0以上)来处理它?

6 回复 | 直到 15 年前

ern 16 年前

我们的开发团队在Subversion中使用了相当标准的分支结构。在主存储库中,我们有3个文件夹:

在您的示例中,所有v*文件夹都将放在标记下。所有的主要开发都发生在主干中,当需要对另一个项目的主干中的内容进行变更时,我们使用分支。

我们还使用分支来存储对主干的巨大更改。这是一个很好的实践,以防在重写完成之前需要修复主干中的错误。所以,我们将在分支下创建一个“v-next”分支,当它完成时,我们将把这个分支合并回主干。

Community CDub 7 年前

我不是TFS专家,但我对 branches and tags .

在任何VCS中,都应该保留一个分支,以隔离与当前开发工作不兼容的开发工作。

这意味着,无论您当前工作的环境(分支或无分支)是什么,如果您不能继续当前的开发虽然启动您提到的那些剧烈的重构,然后您需要一个分支。
在该分支中,文件的历史记录可以在仍被记录的情况下采用新的路径。

诀窍是不要解释分支的标记,特别是如果两者都表示为目录。

V2.0 可以解释为:

我建议使用一种命名约定来阐明目录背后的意图:
V2.0_Refactoring 例如,它会更清楚地表示一个分支。

David Schmitt 16 年前

分支将您的历史保持在一起,并允许您查看项目的完整起源。此外,还可能(取决于产品和混乱状态)将已发布版本的修复程序合并到“下一个”版本中,这可能会或可能不会减少工作以保持此同步。

AwesomeTown 16 年前

根据我的经验,最有效的分支策略是有一个单独的“主线”主干,每个主要版本都有分支,然后根据需要从每个版本中分支出较小的版本。大多数工作都是在主线上完成的,然后当我们接近一个发布时,我们会分支并稳定分支。

您可以为任意小的变更集/发布进行分支,但最终会产生过多的认知开销,使它们变得有价值。您还可以创建更多的临时分支,以将正在进行的大型工程与主分支隔离开来,直到准备合并更改为止。

在所有这些背景下,我不认为在发布之初“重新开始”有多大价值。即使在发布结束时,一切都将发生变化,您仍然需要一个完整的历史记录来记录随着时间的推移事情是如何发展的。我假设TFS会跟踪移动/重命名/删除等操作,所以即使您进行了大量的文件级更改,这也是非常有价值的历史记录。

David Segonds 16 年前

您可能想看一些关于最佳实践的文章:

在您的情况下,我不会创建一个分支来承载您的v-next。只有当您准备好通过创建包装分支来交付给客户时,才应该创建该分支。

我将创建一些短期分支(每个Scrum迭代1个),以承载您的风险开发,并在每个迭代结束时将它们合并回来。只为风险开发创建开发分支,如您所说的剧烈重构。

你的主要分支机构应该总是稳定的。准备好交付给客户,或者至少准备好为包装部门分支。

我也推荐 SCM Patterns .

Andriy Volkov 15 年前