合并代码感觉舒服吗？

Question

今天早上,我读了两篇关于重构的意见.

• 意见1(页面不存在)
• 意见2(页面不存在)

他们建议将代码分支(并随后合并)到:

1. 保持行李箱清洁.
2. 允许开发人员摆脱风险的变化.

根据我的经验(特别是与Borland的StarTeam合作),合并是一种非繁琐的操作.出于这个原因,我只在我必须时(即当我想要冻结候选版本时)进行分支.

从理论上讲,分支是有道理的,但合并的机制使其成为一种非常危险的操作.

我的问题:

• 合并代码感觉舒服吗？
• 您是否因为冻结候选版本以外的原因而分支代码？

Answer 1

分支可能是痛苦的,但不应该.

这就是git-like项目(mercurial,bazar)告诉我们关于CVS和SVN的内容.在git和mercurial上,分支很容易.在SVN上它很容易,但是对于大型项目来说,管理起来可能有点硬(因为花在分支/合并过程上的时间可能很长 - 与git和mercurial之类的其他项目相比 - 如果有非 - 显而易见的冲突).这不能帮助那些不习惯经常分支的用户对分支有信心.很多用户都没有意识到分支的强大用途,只是为了不让新问题添加到他们的项目中,让对未知的恐惧使他们远离效率.

分支应该是一个简单而强大的工具,我们必须使用任何足以分支的原因.

分支的一些好理由:

• 与其他人并行处理特定功能(或者,如果您单独参与项目,则可选择处理其他功能);
• 有几个品牌版本的应用程序;
• 拥有相同应用程序的并行版本 - 比如同时开发的并发技术由团队的一部分开发,以确定哪些工作更好;
• 具有应用程序的资源在艺术家/设计者(例如在游戏中)特定分支中被改变,其中应用程序是"稳定的"而其他分支和主干用于特征添加和调试;
• [在这里添加有用的用法]

Answer 2

一些宽松的指导原则:

• 分支迟到,只在你需要的时候
• 早期和经常合并
• 找到合适的人来进行合并,无论是进行更改的人还是编写原始版本的人都是最好的

分支只是另一种工具,如果您想获得最大的收益,您需要学习如何有效地使用它.

您对分支的态度应该在分布式开源项目(例如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 3

分支是微不足道的.合并不是.出于这个原因,我们很少分支任何东西.

Answer 4

使用SVN,我发现分支相对无痛.特别是如果您定期将主干合并到您的分支中,以防止它太过不同步.

Answer 5

我们使用svn.分支代码只需要5分钟左右.与它使我们免于弄乱行李箱所带来的痛苦程度相比,这是微不足道的.