2

我看过很多关于“Git vs SVN”主题的引文，通常的答案是

  1. 你可以在任何地方提交
  2. 节省空间
  3. 快速分支

...

但是在这里我想讨论一下是否有利于持续交付？在我看来，Git 鼓励我们经常分支，但这与持续交付的概念背道而驰，后者主张经常合并到主线，而不是在功能上发布时分支。

所以，当我想为我们的持续交付选择一个版本控制系统时，我有点困惑，Git 还是 SVN？

你怎么看？

4

4 回答 4

0

我认为您必须首先了解 b/w git 和 SVN 的区别 看看这个链接。为什么 Git 比 Subversion 更好？

我想在此之后你可能知道你必须选择哪一个..

于 2012-06-20T10:26:23.697 回答
0

首先，我永远不会选择svn。可能有一些情况，但总的来说 git 更加灵活。

也就是说，让我们看看持续交付 (CD)。在我看来，这意味着经常部署。这也意味着您需要某种持续集成 (CI)，您可以在其中运行测试并决定版本是否发布。这也意味着您需要某种工作流程来确定如何测试和发布哪个版本。

回到 svn 时代，我们没有任何分支机构，因为这很麻烦。每个人都会提交到存储库，然后负责运送的人会查看一切是否正常并使用他的存储库版本进行运送。

这显然不适用于 CD，因为您至少需要一个稳定的分支。这个分支应该只填充软件的稳定版本，然后才能投入生产。您还需要一个测试分支，其中合并了准备好进行测试然后部署的功能。并且您需要任意数量的开发分支，其中尚未准备好功能。

别搞错了：你可以用 svn 做 CD。只是 git 被设计为与不同服务器上的许多分支和远程存储库一起工作，而 svn 被设计为作为每个人都可以提交的单个存储库工作。

您也可能会遇到用户管理问题。我不了解svn，但我认为您不能对不同的分支拥有不同的权限。这意味着对 repo 具有写访问权限的每个人都可以破坏您的应用程序并部署这些东西。另一方面，很容易建立一个只有高级开发人员才具有写入权限并被部署的存储库。所有其他开发人员都在另一个远程存储库上工作。然后负责人拉出所有东西并将它们推送到另一台服务器，以便部署它们。

这一切都源于 git 被设计成有许多存储库，这些存储库会定期合并、分支、分叉和修补（开源项目）。另一方面，svn 更像是一种公司软件，您需要在其中对文件进行版本控制，并且可能有一个或两个分支用于不同版本的软件，但仅此而已。

最后一件事：我每天都会选择 git 而不是 svn。

于 2012-06-20T10:53:57.763 回答
0

你的担心是有道理的。来自http://martinfowler.com/bliki/FeatureBranch.html

尽管许多人将 DVCS 与特征分支联系在一起，但它们可以与 CI 一起使用。您需要做的就是将一个存储库上的一个分支标记为主线。如果每个人每天都在拉和推，那么你就有了一个 CI 主线。事实上，对于一个纪律严明的团队，我通常更愿意在 CI 项目中使用 DVCS，而不是集中式项目。如果团队纪律性较差，我会担心 DVCS 会将人们推向长期存在的分支，而集中式 VCS 和不愿分支会将他们推向频繁的主线提交。

于 2012-06-21T05:53:06.810 回答
0

无论是 Subversion 还是 Git，如果工作流程正确，您应该没问题。每个版本控制系统都支持分支，有些人认为一侧或另一侧的草更绿，但事实是版本控制是一种商品。

对于围绕版本控制系统的基础架构，通常称为应用程序生命周期管理（如持续集成），更重要的目标是用于将版本控制系统与其他拼图集成的工具的成熟度。紧密的 IDE 集成也很好，可以使开发人员的时间尽可能高效。

你会发现很多 Git 狂热者活跃在论坛上，但 Subversion 拥有（并且是今天）最流行的版本控制系统是有原因的。我试图保持不可知论，但要反驳一些“svn 糟透了”的言论，您可能想阅读以下内容： http ://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git /

于 2012-06-20T19:39:34.023 回答