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

Question

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

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

所以，第一个问题是：对于我们正在做的事情，Git是否明显优于SVN，或者我们是否仍然可能遇到同样的问题而且只是为了毛茸茸的合并？

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

Answer 1

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

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

Answer 2

试试git，你不会回去。

如果你不做任何合并（即在一个小团队的干线上工作），我会说坚持使用Svn。所有其他情况，包括你的肯定 - git将使你的生活更轻松。

当涉及分支，合并和解决冲突时，Git比SVN更好。例如，考虑SVN“每个分支的一个结账目录”场景。此外，git在合并/分支方面要好得多，有些人正在使用git-svn来合并SVN分支。想象一下，反过来......

此外，This answer非常擅长解释Git vs SVN。

Answer 3

“Git有一个学习曲线” - 是的。另一方面，在学习曲线之后，开发人员开始更好地理解源控制系统的概念。他们变得更有条理，更实际地做事。

是的，如果您需要将存储库从Subversion迁移到Git，您的分支布局将会有所不同（除此之外）。但历史将全部存在。

通常较慢的学习曲线的一个原因是，相当多的命令具有不同的名称，并且需要一些时间来绕过它。

Git对于大尺寸的存储库（就数据而言）并不好。但是，您始终可以模块化您的系统并提取它的位。这个概念的好处通常不能很好地理解（在公司和拥有大量糟糕遗留设计的公司），以便得到足够的重视。如果您有一个庞大的存储库（例如SVN / Perforce等通常的情况），您可以在一个地方拥有所有项目的所有代码。但是，Git允许您将项目的整个历史记录保存在本地克隆中。想象一下，如果您已经正确地模块化了所有内容 - 您可以将模块的完整历史记录作为单个实体进行检查。 Git遵循的原则是每个项目都应该有一个存储库（至少大多数人都采用了这个存储库）。维护一小段代码总是更简单，更快速，更整洁。分支，合并，重写历史，将历史记录提取到单独的新存储库中...所有这一切都是如此，太容易了。

Git是你应该尝试的东西。即使你害怕它。阅读ProGit书。这很好，并有很好的例子和解释。您将很快发现Subversion的局限性。我过去常常使用CVS，然后迁移到Subversion并管理它多年。当我开始处理git时（一旦我读完这本书），我真的意识到这个版本控制有多聪明。

真的，如果你尝试并花费一些时间，那么你将无法回头。

如果您想快速开始学习，我建议您在GitHub中设置一个项目，然后再玩一下。他们有很好的解释让你快速入门。

Answer 4

我想如果你习惯了SVN继续使用它。 Git非常好，但你仍然有学习曲线，开始使用它会有破坏性。 Svn工作正常，所以也许你可以改善你公司的“分支”和“项目”的结构。听起来你有一个与工具无关的结构问题。无论如何，这只是我的拙见。我希望它有所帮助。

Answer 5

  

较大的项目合并过程仍然很混乱，我想知道Git是否会更清洁。

没有。在使用过的工具中，您的问题不是（主要是我可以理解的过程），它们是开发过程的组织和管理的更重的问题。改变工具不会破坏坏习惯。

你的主要问题不是“糟糕的合并”（BTW，我从未见过描述“backmerge bizarre”，同时使用sync-merge进行分支 - 然后将这些分支合并到trunk），但是“混乱记”。 Git-merge（通常）更强大，但你会踩到其他rakes，这在Git中更多