高端精品网站建设,个人网站做论坛,网站建设需准备什么,投票网站定制什么时候用分支: 例如为某个客户定制的专用版本,和主干的特性有很大差别.不具通用性的需求. 大的版本修改,例如2.0 到3.0 加了很多特性,但2.0 还有维护.改bug 什么时候用标签: 小版本的发布, 如2.1.1到2.1.2. 分支的优点: 清晰,容易操作,程序员只要get latest/checkin latest就…什么时候用分支: 例如为某个客户定制的专用版本,和主干的特性有很大差别.不具通用性的需求. 大的版本修改,例如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 有策略地进行分支
源代码是开发工作中的一项重要资产。但如何在多个开发人员同时处理文件更新时有效管理和演化源文件成为了一个难题。可以使用版本控制系统在共享储存库中存储源代码、隔离并行开发工作、集成代码更改以及恢复以前的文件版本。版本控制中的一个关键元素是分支利用分支可进行同步开发。如果有策略地进行分支则可保持软件的多个版本的顺序和一致性。
Team Foundation 提供一个灵活可靠的版本控制系统。您可以使用 Team Foundation 版本控制管理开发源代码、文档、工作项和由团队处理的其他关键信息的过程中的多个版本。有关 Visual Studio Team Foundation Server 中的版本控制的更多信息请参见使用版本控制。
在通过多个项目发布同时引入了多个更改时团队如何管理代码 在使用版本控制系统时您必须考虑如何设置分支结构。可以通过镜像源代码文件来创建一个分支。然后可以在不影响源的情况下更改该分支。例如如下图的分支结构所示MAIN 分支包含已通过集成测试的已完成功能而 DEVELOPMENT 分支包含团队正在构建的代码。当 DEVELOPMENT 分支中的新功能完成并可通过集成测试时您可以将代码从 DEVELOPMENT 分支提升到 MAIN 分支中。此过程称为“反向集成”。反之如果您将代码从 MAIN 分支合并到 DEVELOPMENT 分支中则此过程称为“正向集成”。 有关如何创建和合并代码分支的更多信息请参见 CodePlex 网站上的以下页面Team Foundation Server Branching Guide 2.0Team Foundation Server 分支指南 2.0。
分支和合并需要遵循下列原则 每个分支都必须具有一个定义的策略此策略与如何将代码集成到相应分支中有关。例如在上图的分支结构中可以指定一个团队成员来拥有和管理 MAIN 分支。该成员负责执行初始分支操作、将更改从 DEVELOPMENT 分支反向集成到 MAIN 分支以及将更改从 MAIN 分支正向集成到 DEVELOPMENT 分支。当 MAIN 分支也从其他分支集成更改时正向集成非常重要。 MAIN 分支必须包含已通过集成测试的代码以便始终准备进行发布。 由于团队成员会定期签入更改因此 DEVELOPMENT或工作分支将不断演变。 标签是分支中的文件在某个特定时间的快照。 有关更多信息请参见使用标签获取文件快照。
利用 Team Foundation Build可以从分支的几种生成类型中进行选择手动、连续、封闭、滚动和计划。建议 MAIN 分支具有封闭签入生成类型。这意味着DEVELOPMENT 分支必须先通过 MAIN 分支的所有要求然后您才能提交反向集成。DEVELOPMENT 分支应运行连续生成类型因为团队必须尽快了解影响 DEVELOPMENT 分支的新签入的发生时间。
团队应采用何种频率进行反向集成和正向集成 如下图所示反向集成和正向集成应至少在用户情景完成时进行。虽然每个团队对于完成的定义可能不同但完成用户情景通常意味着完成了功能和对应的单元测试。只能在单元测试验证 DEVELOPMENT 分支的稳定性后反向集成到 MAIN 分支中。 如果您具有多个工作即 DEVELOPMENT分支则当任意分支集成到 MAIN 分支时应立刻正向集成到所有工作分支。因为 MAIN 分支保持稳定所以正向集成是安全的。工作分支中可能会发生某些冲突或失败这是因为无法保障工作分支是稳定的。
应尽快解决所有冲突这非常重要。通过对 MAIN 分支使用封闭签入可以使反向集成变得简单得多因为质量要求可帮助避免 MAIN 分支中发生冲突或错误。有关更多信息请参见签入到由封闭签入生成过程控制的文件夹。
团队如何管理实现不同用户情景的源 如下图所示可以定期将更改签入工作分支以完成用户情景。可以在同一分支中同时实现多个用户情景但仅当所有进行中的工作都已完成时才能反向集成到 MAIN 分支。建议您按照类似大小对用户情景进行分组因为您不希望大用户情景阻止多个小用户情景的集成。可以将两组用户情景拆分为两个分支。 团队应在何时添加分支 以下情况下应创建分支 在必须按与现有分支不同的时间表/周期发布代码时。 在代码需要不同的分支策略时。如果创建具有新策略的新分支则可以为项目增添策略价值。 在向客户发布功能且团队打算进行不影响计划的发布周期的更改时。
不应对每个用户情景创建分支因为这会产生较高的集成成本。虽然通过 可方便地进行分支但在分支很多时管理分支的开销可能会很大。
从版本控制的角度团队如何管理发布 团队应能在任意冲刺 (sprint) 末尾发布代码。通过使用 Team Foundation Server可以标记一个分支以在某个特定时间点为代码拍摄快照。如下图所示可以为发布标记 MAIN 分支。这样您可以将分支返回到此时间点时的状态。 因为必须在发布时实现更新所以为发布创建分支可帮助团队继续独立处理下一个冲刺 (sprint)而不会与将来的发布产生冲突。下图显示了一个分支该分支包含更新代码随后在第二个冲刺 (sprint) 末尾进行发布后该分支反向集成到 MAIN 分支。 在为发布创建分支时应从 MAIN 分支该分支最稳定创建分支。如果您从工作分支对发布进行分支则会导致集成问题因为无法保证工作分支的稳定性。
http://msdn.microsoft.com/zh-cn/library/ee782536.aspx http://msdn.microsoft.com/zh-cn/magazine/gg598921.aspx 标签是逻辑上的
分支是物理上的
标签历史版本比较、在修改时中间做应急发布不方便多任务并发多团队合作有问题客户端一个版本。
分支可在任意时刻在主线上发布、修复应急bug、专用版不影响主线客户端多个版本容易混乱。
标签和分支的作用大版本区分。
标签在出现hotfix并发任务人员放假回家的情况大团队作业的情况确实不好。
