针对多个大型开发分支的Git与Subversion

Mik*_*odd 3 svn git workflow continuous-integration

在我的公司,我们目前正在使用Subversion.我们的项目开发过程包括一个"实时"代码分支(这是我们的实时Web服务器上的内容),一个用于较小项目的通用开发分支,然后每个较大的项目都有自己独立的分支.在任何给定时间,我们通常至少有2个较大的项目正在开发中.将这些合并回实时分支可能会很痛苦,但更重要的是,当大型项目1上线时,大型项目2将在稍后发布,并且合并过程只是......混乱.

我在SVN中一直在做的是每天从开发分支中实时合并(所以发生的任何错误修复等).但是更大的项目合并过程仍然很混乱,我想知道Git是否更干净.作为SVN发生的"坏"事件的一个例子,我们将在dev上有一个小功能,将其合并为live,然后在执行实时反馈时,SVN再次尝试将该功能合并回dev(导致冲突),除非我们在合并中手动取消选择该提交.根据我的理解,Git"聪明"足以知道提交起源于dev,因此它不会尝试将其合并回来......但我的理解可能是错误的.我还听说Git更善于自动处理复杂的合并,就像我们正在努力做的那样.

所以,第一个问题是:Git对于我们正在做的事情是否明显优于SVN,或者我们是否仍然可能遇到同样的问题和刚刚融合的问题?

第二个问题:是否有其他可能更适合我们场景的集成方法?特别是,我正在阅读一篇关于混杂集成的文章,这篇文章似乎很好,尽管看起来似乎也会越多,同时进行的项目也越多.但话说回来,我不希望我们同时拥有超过三个大项目,通常只有两个.持续集成不是我们许多项目的选择,因为它们往往是全有或全无的项目,或者如果被推入部分会对用户产生不利影响(例如我们最近重新设计结账流程). 对于我们的情况,本文似乎也是一种很好的方法.

Pet*_*ton 5

我们让人们使用他们认为最舒适的工具.git-svn为那些更熟悉或想要学习专业开发git的人们提供git-lite体验.那里有一个名为SubGit的项目,它可以让你有任何想要使用的SVN和Git.

一般来说,根据功能分支开发风格进行分支/合并的人往往更喜欢git.对于几个团队成员来说,独立于团队其他成员进行协作的开销也要少得多.