今天上午，我读了重构两种意见。
- 看来1（页不存在）
- 看来2（页不存在）
他们建议分支（随后合并）的代码：
- 保持躯干干净。
- 允许开发者从高风险的变化走开。
根据我的经验（特别是Borland的StarTeam中），合并是一个非繁琐的操作。 因为这个原因，我只分支时，我必须（即当我想冻结候选发布版）。
从理论上讲，分支是有道理的，但合并的机制使它成为一个非常危险的操作。
我的问题：
- 你觉得舒适的合并代码吗？
- 你比冻结发布候选其他原因分支代码？
Answer 1:
有些松动指导原则：
- 科后期只有当你需要
- 及早并经常合并
- 找合适的人做的合并，无论是谁写的原始版本谁进行了改变的人或该人是最好的
分支仅仅是另一种工具，你需要学习，如果你想最大的利益如何有效地使用它。
您对分支的态度应该分布式开源项目（比如那些在GIT）以及贵公司的开发项目（可能在SVN运行）之间可能是不同的。 对于分布式的项目，你会想鼓励分支最大限度地创新和实验，对于后者各种你要更严格的控制和支配的分枝应该/不应该发生时决定每行代码签入的政策，主要是为了“保护”代码。
这里是一个指导分支：
http://www.vance.com/steve/perforce/Branching_Strategies.html
下面是一些高水平的最佳实践较短指南：
https://www.perforce.com/sites/default/files/pdf/high-level-perforce-best-practices.pdf
Answer 2:
分支可能是痛苦的，但它不应该是。
这就是混帐项目一样（水银，巴扎）向我们讲述CVS和SVN。 在Git和善变，分支很容易。 如果有非和困难 - 在SVN很容易，但大项目，它可以是一个有点铁杆管理（因为花在分支/合并过程可能会很长的时间 - 相比于其他一些类似的git和Mercurial -obvious冲突）。 这不帮不使用的经常转移到有分支信心的用户。 用户不知道分支的强大用途的地块只是不停地掉不增加新的问题，他们的项目，让未知的恐惧，从效率使他们远。
分支应该是一个简单而强大的工具，我们不得不使用以任何理由不够好分支。
一些很好的理由来支数：
- 工作在一个特定的功能与其他人平行（或同时在其他功能工作相反，如果你独自一人的项目）;
- 具有应用程序的多个版本的品牌;
- 具有相同的应用程序的并行版本 - 就像在同一时间developped并发技术团队，看看哪个效果更好的一部分;
- 该应用程序的资源具有上的艺术家/设计者正在改变（例如在游戏中）特定分支，其中，同时其它分支和中继线用于提供加法和调试应用程序是“稳定的”;
- [添加这里有用的用途]
Answer 3:
分支是微不足道的。 合并是不是。 出于这个原因，我们很少分支什么。
Answer 4:
使用SVN，我发现分支是相对简单的。 特别是如果你定期合并到主干您的分支，以保持它变得太远远不同步。
Answer 5:
我们SVN使用。 只需要我们约5分钟分行代码。 相比于痛苦的它让我们可以搞乱干线量是微不足道。
Answer 6:
在数百万行的代码了数以千计的开发分支代码库的工作是每天都会发生。 分支机构的寿命取决于工作的数量正在做变化。
对于一个小的修复：
- 设计师让一个侧支关闭主流
- 做出改变
- 测试
- 评论
- 合并来自主流到侧支变动累计
- 通过一个或多个前面的步骤迭代
- 合并回到主流
对于多人的团队功能：
- 团队使得功能侧支离主流
- 个别团队成员的特征侧支操作，如“小补丁”的方式，并融合为特色侧支。
- 侧支总理定期积累并轨从主流变为功能侧支。 从主流小的增量合并为特色侧支更容易对付。
- 当功能的工作原理，从主流做最终合并为特色侧支
- 合并功能侧支到主流
对于客户端软件版本：
- 做一个发布分支
- 根据需要释放分支机构提供修复
- 修复从主流根据需要传播到/
客户发布流可以支持非常昂贵。 需要测试资源 - 人员和设备。 一两年后，在特定的流开发的知识开始变得陈旧的主流前进。
你能想象它必须花费多少为微软支持XP，Vista和Windows 7同时？ 想想试验台，管理，文档，客户服务，最后是开发团队。
黄金法则： 永远不要打破主流，因为你可以摆摊了大量的开发者。 $$$
Answer 7:
该分支的问题是，为什么我使用分布式版本控制系统（在我的案件的Git，但也有水银和集市）在那里创建一个分支是微不足道的。
我用短暂的分支机构所有的时间进行开发。 这让周围乱七八糟我在我自己的仓库，犯错误，错误的选择，然后rebase所以只有干净的改变被保持在历史的变迁到主分支。
我使用的tag s到标记冻结代码，而且很容易在这些系统回去岔开这对于bug修复，而不代码库中具有长寿命分支的负载。
Answer 8:
我使用Subversion和考虑分支非常简单和容易。 因此，要回答的问题1 ..是的。
之所以分支可能大规模变化。 我分支，如果我觉得我应该。 挺难把规则和理由下来所有的可能性。
但是，只要“允许开发者从高风险的变化走开。” 评论。 我完全以与一个同意。 我创建了一个分支，每当我想真正玩的代码，并希望我做这个工作的唯一开发者。当你一个分支，可以做到这一点...
Answer 9:
我一直在使用SVN和TFS的项目，并通过自身的分支是一个非常简单的事情。
我们使用分支的候选版本以及为持久或试验性功能和来自其他球队的干扰隔离。
在分支的唯一痛苦的时刻被合并，因为旧的或激烈的发达分支可能差别很大，从树干，可能需要显著努力合并回去。
说了上面的，我要说的是，分支是一个强大的和有益的做法，应同时发展来考虑。
Answer 10:
如果合并是太痛苦，考虑迁移到一个更好的VCS。 这将是一个更大的痛苦，但只有一次。
Answer 11:
我们使用SVN和已采取的规则分支重大更改。 较小变化，就在树干做。
我们也分支版本。
分支与合并为我们运作良好。 诚然，有时我们不得不坐下来思考的事情是如何结合在一起的，但通常使用svn做合并的一切伟大的工作。
Answer 12:
我使用SVN，它需要不到一分钟的分支代码。 我曾经使用ClearCase的，它花了不到一分钟，分行代码。 我也用其他较小，供应链管理系统，他们要么不支持分支机构或太痛苦使用。 StarTeam中听起来像后者。
所以，如果你不能迁移到更有益的（实际上，我只听说的StarTeam坏事），那么你可能要尝试不同的方法：手动分支。 这包括检查你的代码，将其复制到不同的目录，然后将其添加为一个新的目录。 当你需要合并，你看看这两个目录和使用的WinMerge进行合并，在结果原来的目录检查。 尴尬，如果你继续使用分支，但它的工程潜在的困难。
与分支的诀窍是不要把它当作一个全新的产品。 这是一个分支 - 用于单独，安全地进行更改主干线的产品相对短暂的设备。 谁以为合并是很难或者是重构代码文件这么多（即它们重命名，复制，创建新的，删除旧）的分支成为一个完全不同的事情，或者他们保持分支这么久，累积的更改承担一点相似于原文。 你可以保持一个分支很长一段时间，你就必须定期回来合并更改。 做到这一点，分支/合并变得很容易。
Answer 13:
我只是做了几次，所以我不与它正好舒服。
我已经做到了进行设计实验，将跨越某些签入，所以分支是隔离开自己一个花园，而且，它让我鼓捣，而其他人对主枝合作，发挥一个简单的方法，所以我们并没有失去太多的时间。
使得这将使后备箱不可编译的广泛的变化时，我也已经做到了。 它成为我的项目，我不得不删除编译时类型安全的代码库（从仿制药到System.Object的）一大截清楚。 我知道这将需要一段时间，需要遍布这将与其他人的工作干扰代码库的变化。 这也将打破建立，直到我完成。 所以我支和剥离出来的仿制药，工作，直到该分支编译。 然后我它合并到主干。
事实证明，这非常好。 避免了很多脚趾步，这是伟大的。 希望这样的事永远不会再次出现。 它的种类，一个设计将改变需要这种广泛的编辑也不会导致大量的代码的一种罕见的事情被甩出...
Answer 14:
支链必须正确管理，使合并无痛。 根据我的经验（与Perforce的）常规的集成，从主线分支意味着整合到主要的线非常顺利。
当时只有极少数情况下合并失败。 从主线分支的不断整合很可能涉及合并，但他们只是小编辑，自动工具可以处理，无需人工干预。 这意味着，用户没有“看到”这些发生。
因此，在最后的集成所需的任何合并，经常可被自动太处理。
Perforces 3路合并工具，是一个很大的帮助时，实际上是需要他们。
Answer 15:
你觉得舒服的分支代码？
这真的取决于我使用的工具。 用StarTeam，分支的确是不平凡（TBH，吮吸的StarTeam在分支）。 使用Git，分支是有规律的活动，是很容易的。
你比冻结发布候选其他原因分支代码？
嗯，这实际上取决于你的版本控制模式，但简短的回答是肯定的。 其实，我建议阅读以下文章：
- 版本控制多个敏捷团队亨里克·Kniberg
- FeatureBranch由Martin Fowler
我很喜欢在第一篇文章中描述的图案，它可以与任何（非分布式）的版本控制系统中适用，包括StarTeam中。
我可能会考虑用第二个方法（实际上是两种策略的混合）（只有用）分布式版本控制系统（DVCS）如Git，水银...
Answer 16:
我们使用的StarTeam当我们（在发布周期或一些跨越多个版本的Windows长达到项目即修复到生产）需要它的情况下，我们唯一分支机构。 我们将视图标签来标识版本，这使得它一件简单的事需要以后创建分支。 所有作品都是基于这些视图标签，我们不建未标记的代码。
开发者应该有一个“代码 - 测试 - 提交”模型，如果他们需要为他们创建并管理它的一些测试目的还是“冒险”的发展观点。 我管理的仓库，只有当我们需要他们创建分支。 这些时间是（但不限于）：
- 生产的修补程序
- 具有长的或重叠的开发周期项目
- 大量重写或试验发展
StarTeam中的合并工具是不是最大的，但我还没有碰到由它造成的问题。 无论是谁做的只是合并需要非常肯定他们知道他们在做什么。
创建于明星队“只读参考”视图，将其设置为浮动配置将允许在后备箱的变化在分支自动显示。 设置项分支上的变化。 这有利于并行开发力度。
创建一个标记配置的“只读参考”的观点是，你会使用什么热修复现有的生产版本（假设你已经标记他们）。
Answer 17:
分支是平凡的，因为大多数已经回答了，但合并，就像你说的，是不是。
真正的按键去耦和单元测试。 试试你分支之前脱钩，并保持对主要着眼于肯定的是，去耦和接口保持不变。 当谈到时间合并这种方式，它就像更换一块乐高：去除老片，新的片在其位置非常适合。 单元测试是有保证什么得到打破。
Answer 18:
分支与合并应该是相当简单。
- 我感觉很舒服分支/合并。
- 分支出于不同的原因做，这取决于你的开发过程模型/
那里有几个不同的分支型号：
这里有一个
Trunk
.
.
.
..
. ....
. ...
. ..Release1
.
.
...
. ....
. ...Release2
.
.
..
. ...
. ..
. ...Release3
.
.
现在，这里是一个奇怪的事情。 假设Release1需要一些bugfixing。 现在，你需要分支Release1开发1.1。 这是确定的，因为现在你可以分支R1，做你的工作，然后合并回R1形成R1.1。 请注意这是如何保持版本之间明确的diff？
另一个分支模型是让所有的开发在树干上做的，每一个版本被标记，但没有进一步的发展大干快上特定版本完成。 分行发生发展。
Trunk
.
.
.
.Release1
.
.
.
.
.Release2
.
.......
. ......
. ...DevVer1
. .
. .
. ...DevVer2
. ....
. ....
...
.Release3
.
可能有一个或两个主要分支型号，我不记得他们把我的头顶部。
底线是，你的VCS需要支持灵活的分支和合并。 每个文件系统VCS存在一个重大的痛苦IMO（RCS，ClearCase的，CVS）。 SVN据说是一件麻烦事在这里为好，不知道为什么。
水银在这里做了伟大的工作一样，（我认为）饭桶。
文章来源: Do you feel comfortable merging code?
