如何使用SVN管理源代码？分支,合并

Question

我们是位于不同地点的4位开发人员/朋友的团队.我们都已经开始研究ProjectX并使用Subversion创建了分支A,B,C和D.

我们只掌握控制源代码的版本的基本知识.有一天,我们中的一个人试图将分支A与B,C和D合并,而B和B试图合并A,C和D.(他们甚至不知道如何合并它:D,只需右键单击>合并>合并一系列修改)我们遇到了一些冲突,解决了它们.尝试再次合并,再次右击.....)再次冲突.

现在所有代码都搞砸了.我们有4个不同的代码副本(D缺少B的功能但有C等等).所以我在SO上经历了很多线程,阅读SVN书籍,特别是这篇文章(如何正确分支)帮助了解了如何合并分支和主干.我想我对未来有了更好的了解.但是我如何摆脱目前的局面？

我的问题是:

• 我们四个人正在同一个项目上工作,但通常在不同的位上工作,我们应该只有一个分支？然后创建4个工作副本,然后仅提交和更新.一旦我们准备合并trunk到分支,分支到trunk？根据上述文章中的建议
• 你能否建议任何工作流程,以便我们可以将我们的4个分支到达主干,然后我可以进行导出以从头开始再次控制版本.
• 另外我认为如果再次使用4个分支,我们每个人每天/定期更新我们的分支并从主干(合并)获取更改并将本地更改合并回主干？(而不是尝试mergin分支到分支:-D)

请建议我们应该使用哪些工作流程？这样它在维护代码方面的痛苦最小化.谢谢.

Answer 1

我不会为每个开发人员创建一个分支.我建议一个持续的集成过程,其中所有四个人从一个"主干"检查并经常合并更改 - 每天多次.理想情况下,您将拥有标准化的构建工具(例如Maven,Ant等)和构建调度程序(例如Hudson,Cruise,TeamCity等).将这两个工具放在SCM工具(Subversion)之上,您可以让一个过程持续构建您检查到主干的所有更改,并在出现问题时通过电子邮件发送给所有开发人员.这可以防止您通过不良更改或合并破坏构建,同时允许您保持轻量级分支结构(即一个分支 - 主干).

分支机构使您的代码更改与您的队友更改变得更加困难.分支应该真正用于分支 - 创建软件的特殊管理"分支".例如,如果您要发布软件的1.0版本,那么从主干创建1.0分支(在开发之后但在发布之前)可能是一个好主意,因此您可以在不影响正在进行的情况下维护此版本在主干上开发(可能是2.0版本).

我建议用Subversion抓取Pragmatic Version Control.这是SCM的一个非常可靠的概述,具有Subversion的细节.