【转摘】TFS上分支和标签的用法

引用路径：http://blog.csdn.net/cxzhq2002/article/details/8518250

 

什么时候用分支:  例如为某个客户定制的专用版本,和主干的特性有很大差别.不具通用性的需求.

                       大的版本修改,例如2.0 到3.0 加了很多特性,但2.0 还有维护.改bug

 

什么时候用标签: 小版本的发布, 如2.1.1到2.1.2.

 

 

 

分支的优点: 清晰,容易操作,程序员只要get latest/checkin latest就可以了

 

分支的缺点: 合并比较麻烦, 解决方法是要么是定期同步或者干脆不同步.

 

 

 

标签的优点: 灵活

标签的缺点: 如果要对某个label的版本进行hotfix, 操作起来比较麻烦, 要先get specific version by label, 然后修改代码,checkin之后会产生一个新的changeset, 然后在一个workspace里面get labelversion,然后get changset, 重新label一个version.来发布hotfix. 发布之后还要把之前latest的代码copy一份,重新check in latest

 

========================================

有策略地进行分支

源代码是开发工作中的一项重要资产。如果有策略地进行分支，则可保持软件的多个版本的顺序和一致性。

使用版本控制。

在通过多个项目发布同时引入了多个更改时，团队如何管理代码？

---

反之，如果您将代码从 MAIN 分支合并到 DEVELOPMENT 分支中，则此过程称为“正向集成”。

Team Foundation Server Branching Guide 2.0（Team Foundation Server 分支指南 2.0）。

分支和合并需要遵循下列原则：

1. 当 MAIN 分支也从其他分支集成更改时，正向集成非常重要。

2. MAIN 分支必须包含已通过集成测试的代码，以便始终准备进行发布。

3. 由于团队成员会定期签入更改，因此 DEVELOPMENT（或工作）分支将不断演变。

4. 标签是分支中的文件在某个特定时间的快照。

   使用标签获取文件快照。

DEVELOPMENT 分支应运行连续生成类型，因为团队必须尽快了解影响 DEVELOPMENT 分支的新签入的发生时间。

团队应采用何种频率进行反向集成和正向集成？

---

只能在单元测试验证 DEVELOPMENT 分支的稳定性后反向集成到 MAIN 分支中。

工作分支中可能会发生某些冲突或失败，这是因为无法保障工作分支是稳定的。

签入到由封闭签入生成过程控制的文件夹。

团队如何管理实现不同用户情景的源？

---

可以将两组用户情景拆分为两个分支。

团队应在何时添加分支？

---

以下情况下应创建分支：

• 在必须按与现有分支不同的时间表/周期发布代码时。

• 如果创建具有新策略的新分支，则可以为项目增添策略价值。

• 在向客户发布功能且团队打算进行不影响计划的发布周期的更改时。

虽然通过  可方便地进行分支，但在分支很多时，管理分支的开销可能会很大。

从版本控制的角度，团队如何管理发布？

---

通过使用 Team Foundation Server，可以标记一个分支以在某个特定时间点为代码拍摄快照。如下图所示，可以为发布标记 MAIN 分支。这样，您可以将分支返回到此时间点时的状态。

下图显示了一个分支，该分支包含更新代码，随后在第二个冲刺 (sprint) 末尾进行发布后，该分支反向集成到 MAIN 分支。 如果您从工作分支对发布进行分支，则会导致集成问题，因为无法保证工作分支的稳定性。

http://msdn.microsoft.com/zh-cn/library/ee782536.aspx

 

http://msdn.microsoft.com/zh-cn/magazine/gg598921.aspx

 

 

==================

标签是逻辑上的

分支是物理上的

标签历史版本比较、在修改时，中间做应急发布不方便，多任务并发，多团队合作有问题，客户端一个版本。

分支可在任意时刻在主线上发布、修复应急bug、专用版不影响主线，客户端多个版本，容易混乱。

标签和分支的作用：大版本区分。

标签在出现hotfix，并发任务，人员放假回家的情况，大团队作业的情况确实不好。