SVN:每个开发人员的个人分支机构？
我会说实话,SVN分支机构吓唬我.我工作的最后一个项目广泛使用它们,我似乎花了一半的时间来测试我的分支工作,做一个虚拟合并到主干,做一个真正的合并 - 只是为了找到其他人刚刚做了这个和我不得不更新并重新开始.
在那个特定的项目中,分支是由每个开发人员完成的...有一个主干,然后你有了你的个人分支,处理任务并合并了一系列修订版本.看起来很可怕因为你每次必须检查什么分支中的最后一个修订版是您合并的.
这个范例真的很好吗,我只是没有得到它,因为我不习惯命令行SVN使用？或者这是一个糟糕的系统？
Pas*_*ent 13
使用Subversion,我使用"工作分支",它由团队拥有并由团队中所有成员共享,如伟大版本控制多个敏捷团队文章所述,如下所示:
我热烈建议阅读全文,这真的值得一读.
除了Subversion以外的其他东西,我可能会考虑使用"功能分支",但说实话,我没有看到每个开发人员的个人分支点(对我来说超出功能的粒度是没有意义的).
Eri*_* J. 11
我从未使用过开发人员分支.这个想法对我没有意义.
首先,您应该与开发团队保持一致,以便人们倾向于处理源代码的不同部分.如果每个人都在不断编辑相同的文件,那么任何技术都无法帮助您保持每个人的协调.
SVN在人们处理相同文件的那些时候合并不同人的编辑工作做得很好.编写单元测试以帮助确保合并的代码产品仍然有效.
我在开发下一个版本时使用分支来维护当前发布的代码版本.
- 当有几个开发人员处理几个不同的功能时,我可以看到"每个开发人员分支"的方法很有用,其中一个尚未准备好使用他们的功能,但您仍想发布其他已准备好的功能.您可以说"如果它还没有准备就不要检查它",但是你有一个开发人员检查一堆文件的问题,并且如果需要的话,其他开发人员很难处理这些文件.但是我绝对同意,分支快乐也是有问题的. (2认同)
Pao*_*olo 11
每个开发人员分支都是有效的范例.我发现的主要好处是,它们允许您检查正在进行的工作,从而将其备份,其他人访问以防您生病等,而不会扰乱主干线.
分支机构本身并不是真正的问题,问题在于管理合并.我过去所做的是使用合并令牌(软玩具或动作人物效果很好 - 持有令牌的人可以合并到主干)或者在开发维基上有合并队列,基本上只有一个开发合并到一次干.
- 大声笑,你的合并令牌基本上就像使用Sourcesafe"嘿,你能检查文件123.h,我需要进行更改" (2认同)
正如我所看到的,每个开发人员拥有一个分支机构的主要好处是,您可以制定频繁签入的策略 - 确保每个人每晚都检查代码 - 无论代码状态如何,因为它们不会破坏其他人的构建,更不用说主要的发展路线了.
这意味着你可以每晚备份人们的工作,如果开发人员犯了错误或者他们的算法实现遇到了问题,那么开发人员更容易恢复到他们开发的(部分)工作版本.
它还将确保只有经过完全批准和测试的代码(假设您正在进行代码审查和单元测试)才能进入主线.
我同意合并开销可能是繁重的,但是如果每个人都经常(至少每周一次,最好是每天一次)从主线到他们的分支整合,那么从开发者分支合并的影响应该是最小的.
老实说，您可能想要其他东西，比如 git。
- 为什么？提供 git 比 SVN 更好地解决这个问题的一些理由会很有帮助。 (9认同)
- 事实上，这只是一种支持 GIT 的狂热，还是对我的具体问题的深思熟虑的回应？ (3认同)
- 约翰，这实际上是经过深思熟虑的答案。Git 专为您正在做的事情以及更多事情而设计。我没有尝试详细解释，因为我不会公正地解释...让您指出可以... Linus Torvald on Git at Google IO - 这是一个很长的观察，但您会看到什么大惊小怪的是。http://www.youtube.com/watch?v=4XpnKHJAok8 抱歉打扰！ (3认同)