TFS-级联分支机构的可持续性 [英] TFS -- Sustainability of Cascading Branches

问题描述

分支指南通常描述一个永生的 Main分支，其功能从Main分支，并合并回到Main，而Releases从Main分支，以及Service Pack，RTM等所需的Release的其他分支。关于Main的信息通常简化为 Main中没有垃圾。

Branching guidance usually describes an immortal "Main" branch, with features branched from Main, and merged back to Main, and Releases branched from Main, with further branches of a Release as necessary for Service Packs, RTMs, etc. The guidance regarding Main is often simplified to "no trash in Main."

我正在与一个定期（每月一次）并按顺序发布的小组合作。对他们来说，似乎没有必要将工作返回到Main分支。他们使用的是TFS 2010，在分支上，其分支结构看起来像这样：

I'm working with a group that releases regularly (as often as monthly) and serially. To them it seems unnecessary to ever return work to the Main branch. They use TFS 2010--diagramatically their branching structure looks like this:

在分支上进行日常构建；最终，该分支机构投入生产。分支的任何修补程序都直接应用到该分支，并且可以选择合并到将来的所有机上分支。

Daily builds on a branch are made; eventually the branch goes to production. Any hotfixes to a branch are applied directly to that branch, and optionally merged forward to any future in-flight branches.

该组的分支策略被概括地描述为级联分支反模式。但是，考虑到这些分支机构正式投入生产，然后（通常）生存时间很短，真的吗？

This group's branching strategy has been described perjoratively as the "Cascading Branches Antipattern." But is it really, given that these branches release to production, and then (usually) have a fairly short time to live?

这种在TFS中级联分支机构的做法是否可持续从长远来看。如果没有，限制是什么？何时达到（在几个分支之后）？

Is this practice of cascading branches in TFS sustainable over the long term. If not, what are the limits, and when (after how many branches) might they be reached?

是否有任何理由最终不破坏 Main，R1，R2（等等），或者是否存在陷阱，以防止破坏和回收空间

Is there any reason to NOT "destroy" Main, R1, R2 (etc.) eventually, or is there a "gotcha" that will prevent destroying and reclamation of space on the SQL server that is hosting the source code repository?

推荐答案

级联分支可以工作。我也想不出任何技术原因来销毁非常旧的（最好是已存档的）分支会影响较新的级联分支。这里有一些要考虑的问题：

Cascading branches can work. I also can't think of any technical reason why destroying very old (preferrably archived) branches would impact the newer cascaded branches. Here are some issues to consider:

1. 开发人员必须在每次发行后将一个新的分支映射到其工作区。


2. 如果开发人员在发布前无法检入任何工作，则必须手动将其移至新分支（与发布后仅检入同一个工作的Dev或Main分支相对） 。）


3. 如果您有一个或多个开发人员在Rn的子分支中工作，并且已决定将其工作移至Rn + 1，则需要进行无基础合并以避免检查。进入原始的父Rn分支。


4. 确保释放后安全地锁定每个分支。所有这些分支都将增加开发人员无意中检查对已发布分支所做的更改的风险。


5. 每次级联之后，您都需要调整构建定义和任何其他特定于路径的工件。如果所有开发工作都只能在Dev（或Main）范围内进行，则主要工作空间和相关的构建/项目工件将随时间保持不变。


6. 当出现以下情况时，您如何孤立地处理并行功能？您不知道Rn中将提供哪些功能？ （如果您有一个主要分支，则可以从Main中拥有多个子功能部件开发分支，然后仅在功能部件稳定并且可以合并到下一个版本中发布时合并功能部件分支。）

1. Developers have to map a new branch to their workspace after every release.
2. Developers have to manually move any work to a new branch if they weren't able to check it in before release (vs. just checking in to the same working Dev or Main branch after release.)
3. If you have one or more developers working in a child branch of Rn and a decision is made to move their work to Rn+1 then a baseless merge will be required to avoid checking into the original parent Rn branch.
4. MAKE SURE YOU SECURELY LOCK EACH BRANCH after release. All those branches will increase risk of a developer accidentally checking in a change to a released branch.
5. You need to adjust build definitions and any other path-specific artifacts after each cascade. If all development just works out of Dev (or Main) then the primary workspace and related build/project artifacts remain the same over time.
6. How do you work on a parallel features in isolation when you don't know which feature(s) will ship in Rn? (If you have a main branch the you can have multiple child feature dev branches from Main, then merge a feature branch only when it is stable and ready to merged to ship in the next release.)

我相信Jeff Levinson做了一个介绍，描述了从单个分支开始，然后是级联分支，然后是Main + Release和几个变体（同时描述了每个利弊）的分支进化。 ）。查看分支和合并实践-Jeff Levinson（2010年技术视频）（或相关的分支和合并PPT ）。

I believe Jeff Levinson did a presentation that described branching evolution starting with single branch, then cascading branch, then Main+Release and a couple variations (while describing pros and cons of each). Check out Branching and Merging Practices - Jeff Levinson (Teched 2010 Video) (or related Branching & Merging PPT).

享受！ -Zephan

这篇关于TFS-级联分支机构的可持续性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！