3

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

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

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

第二个问题：是否有其他集成方法可能更适合我们的场景？特别是，我正在阅读一篇关于混杂集成的文章，该文章看起来不错，尽管同时进行的项目越多，这似乎也会变得越来越困难。但话又说回来，我不希望我们同时拥有三个以上的大型项目，通常只有两个。对于我们的许多项目来说，持续集成并不是一种选择，因为它们往往是全有或全无的项目，或者如果部分推进的话会令用户感到不安（例如，我们最近重新设计了我们的结帐流程）。 对于我们的情况，这篇文章似乎也是一个很好的方法。

4

5 回答 5

5

我们让人们使用他们觉得最舒服的任何工具。git-svn 为更熟悉或想要学习 git 以进行专业发展的人们提供了 git-lite 体验。有一个名为SubGit的项目，它可以让您拥有 SVN 和 Git 供任何想要使用的人使用。

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

于 2013-03-01T16:34:18.517 回答
3

试试 git，你不会回去的。

我会说只有在你不进行任何合并的情况下才坚持使用 Svn（即在一个小团队中的主干上工作）。所有其他情况，包括你的情况——git 会让你的生活更轻松。

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

此外，这个答案非常适合解释 Git 与 SVN。

于 2013-03-01T16:19:04.920 回答
3

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

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

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

Git 不适用于大型存储库（就数据而言）。但是，您始终可以模块化系统并提取其中的一部分。这个概念的好处通常没有被很好地理解（在拥有大量糟糕的遗留设计的公司和公司中），以便得到足够的赞赏。如果您有一个巨大的存储库（例如在 SVN/Perforce 等下通常是这种情况），那么您将所有项目的所有代码都放在一个地方。但是，Git 允许您将项目的整个历史记录保存在本地克隆中。想象一下，如果您已将所有内容正确模块化——您可以将模块的完整历史记录为单个实体。Git 遵循的原则是每个项目都应该有一个存储库（至少大多数人是这样采用的）。维护一小棵代码树总是更简单、更快、更整洁。分支、合并、重写历史、将目录及其历史提取到单独的新存储库中……所有这一切都非常简单。

Git 是你绝对应该尝试的东西。即使你害怕它。阅读 ProGit 书。它很好，并且有很好的例子和解释。你会很快发现 Subversion 的局限性。我从早期开始使用 CVS，然后迁移到 Subversion 并管理它多年。当我开始与 git 打交道时（一旦我读过这本书），我真的意识到这个版本控制是多么聪明。

真的，如果您尝试并为此付出一些时间，那么您将没有回头路。

如果您想开始并快速学习它，我建议您在 GitHub 中建立一个项目并尝试一下。他们有很好的解释让你快速入门。

于 2013-03-01T18:38:02.617 回答
0

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

于 2013-03-01T16:13:14.677 回答
0

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

不。您的问题（大多数情况下，我可以理解过程）不在于使用的工具，它们是开发过程的组织和管理方面的更重的问题。改变工具不会破坏坏习惯。

你的主要问题不是“糟糕的合并”（顺便说一句，我从未见过描述过“奇怪的反向合并”，同时使用同步合并到分支 - 稍后将这些分支合并到主干），而是“头脑中的混乱”。Git-merge（通常）更健壮，但你会踩到其他耙子，这在 Git 中要多得多

于 2013-03-02T06:23:51.573 回答