我见过很多关于“Git vs SVN”主题的引文，通常是awser
...
但在这里，我想讨论是否有利于持续交付？ 在我看来，Git鼓励我们经常进行分支，但这种做法反对持续交付的概念，主张经常合并到主线，在发布时不支持功能。
所以，当我想为Continous Delivery，Git或SVN选择版本控制系统时，我有点困惑？
你有什么看法？
答案 0 :(得分：0)
我认为你必须先了解差异b / w git和SVN 看一下这个链接.. Why is Git better than Subversion?
我想在此之后你可能知道你必须选择哪一个..
答案 1 :(得分：0)
首先，我永远不会选择svn。可能有一些情况，但一般来说git更灵活。
那就是说，让我们看看Continous Delivery（CD）。从我的角度来看，这意味着要经常部署。这也意味着您需要某种连续集成（CI），您可以在其中运行测试并确定版本是否已发货。这也意味着您需要某种工作流程来确定如何测试和发布哪个版本。
回到svn时代，我们没有任何分支，因为这是令人不安的。每个人都会进入存储库，然后负责运输的人会看到一切是否正常，并使用他的版本的存储库来发货。
这是不可能用于CD的，因为你想要至少一个稳定的分支。此分支只应填充稳定版本的软件，然后才能投入生产。您还需要一个测试分支，其中功能已合并，可以进行测试然后进行部署。并且您需要任何数量的开发分支，其中尚未准备好功能。
别搞错：你可以用svn做CD。只是git被设计为与不同服务器上的许多分支和远程存储库一起工作，而svn被设计为作为每个人都可以承诺的单个存储库。
您也可能遇到用户管理问题。我不知道svn，但我认为你不能拥有不同分支的不同权利。这意味着对repo具有写访问权限的每个人都可以破坏您的应用程序并部署这些内容。另一方面，可以轻松设置一个存储库，其中只有高级开发人员具有写入权限并且可以部署。所有其他开发人员都在另一个远程存储库然后，负责人将所有内容拉到另一台服务器上，以便部署它们。
这一切都来自于git被设计为具有许多存储库的事实，这些存储库定期合并，分支，分叉和修补（开源项目）。另一方面，svn更像是一个公司软件，你需要对你的文件进行版本化，并且可能有一两个分支用于不同版本的软件，但不是更多。
最后一件事：我会每天选择git而不是svn。
答案 2 :(得分：0)
如果工作流程正确无论Subversion还是Git，你应该没问题。每个版本控制系统都支持分支机构，有些人认为草地在一边或另一边更环保，但事实上版本控制是一种商品。
对于版本控制系统周围的基础架构，通常称为应用程序生命周期管理（如持续集成），更重要的目标是用于将版本控制系统与其他部分集成在一起的工具的成熟度。紧密的IDE集成也很好，可以使开发人员的工作时间尽可能高效。
你会发现很多Git狂热者在论坛上活跃，但Subversion有（而且是今天）最流行的版本控制系统。我试图不可知，但为了对付一些“svn糟透了”的言论，你可能想读这个： http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/
答案 3 :(得分：0)
您的担忧是有效的。来自http://martinfowler.com/bliki/FeatureBranch.html
尽管许多人将DVCS与功能分支相关联，但他们可以 与CI一起使用。您需要做的就是在一个分支上标记一个分支 存储库作为主线。 如果每个人都拉着并推动每一个 那天，你有一个CI主线。确实有一个训练有素的团队，我 通常更喜欢在CI项目中使用DVCS而不是集中式 一。如果没有纪律严明的团队，我会担心DVCS会这么做 推动人们走向长寿的分支机构，而集中的VCS和 不愿意将其推向频繁的主线提交。