2

我是版本控制系统的新手，并试图决定使用哪一个。有很多信息，但也许专家已经可以通过回答以下问题来帮助我。我找到了一个与我的要求非常相似的版本控制/分支模型：

http://nvie.com/posts/a-successful-git-branching-model/

理论上我可以用 SVN 轻松实现这一点吗？像 Hotfix 和 Bugfix 分支一样，它们各自合并到多个不同的分支中？为什么“合并”应该更容易使用 Git 呢？

4

4 回答 4

5

在很多 StackOverflow 答案中都推荐了您链接到的工作流程。不过，一般来说，主要思想是将“好代码”和“开发代码”分开 -master和development分支。此外，保持功能分离，直到它们准备好合并到development分支中——这就是featuresandhotfix分支。

我毫不怀疑，SVN 完全可以实现该工作流程或非常相似的工作流程-您将使用SVN Branches。

周围有一大堆修订控制系统，Nvie Git 工作流程非常通用——一般的工作流程可能会在大多数修订控制系统中使用。

理论上我可以用 SVN 轻松实现这一点吗？像 Hotfix 和 Bugfix 分支一样，它们各自合并到多个不同的分支中？

就个人而言，我认为 SVN 中的分支不像 Git 中那样容易。Linus Torvalds 同意——因此他围绕分支的想法设计了 Git。

为什么“合并”应该更容易使用 Git 呢？

Git 是围绕分支的思想设计的。制作分支，使用分支，将两个分支合并在一起，将三个分支合并在一起，将来自本地和远程存储库的分支合并在一起——Git 擅长分支。SVN 不是以分支为中心的，在我（有限的）SVN 经验中，将两个分支合并在一起并不总是很有趣。

如果您刚开始使用版本控制系统，我建议您使用 Git。要在 Git 和 SVN 之间进行适当的比较，请查看此链接。然而，我要指出的是，Git 有点让人费解，特别是如果你是新手的话——从概念上讲，SVN 更容易理解。我发现Pro Git 这本书非常有帮助。

于 2012-05-07T22:21:44.093 回答
3

从您提供的链接：

在我来自的经典 CVS/Subversion 世界中，合并/分支一直被认为有点吓人（“当心合并冲突，它们会咬你！”）而且你只是偶尔才会做的事情。

但是使用 Git，这些操作非常便宜和简单，它们被认为是您日常工作流程的核心部分之一，真的。

就 SVN 而言，我同意该声明（我没有真正的 GIT 工作经验）。在 SVN 中，合并是耗时的，坦率地说，是可怕的。你不会轻易分支。所以，我想，答案是“不”——如果你事先知道你必须做很多分支和合并，就不要使用 SVN。

于 2012-05-07T22:15:49.410 回答
2

理论上——是的，SVN 可以实现。但是SVN缺乏合并和分支工具。因此与 SVN 合并/分支有点不方便和可怕（主要问题 - 复杂的树和其他冲突）。

GIT 是合并分支的大师——他可以解决极其棘手的冲突。它还可以让您轻松跟踪所有分支版本。

SVN 和 GIT 的主要区别：

  • SVN 是集中式版本控制 (CVCS)
  • GIT 是去中心化版本控制 (DVCS)

要了解比较，请查看这篇文章

于 2012-05-07T22:18:58.117 回答
1

Subversion 有一个优势，即您始终知道特定修订中的特定分支/主干是否合并到您的分支（通过 svn:mergeinfo），这在挑选提交的情况下很重要。Git 提供了被认为工作得更好的合并工具。

您可以将 SubGit ( subgit.com ) 安装到您的 SVN 存储库中，并具有两种方法的优势。安装后，SubGit 创建了一个链接到该 SVN 存储库的 Git 存储库，以便对该 Git 存储库的任何推送都转换为 SVN，反之亦然。转换是即时执行的。

于 2012-05-12T12:54:02.117 回答