我现在已经使用颠覆了一段时间，我正在考虑学习并转用GIT，因为它现在似乎是大多数人的偏好。
然而，GIT的最大优势之一（及其复杂性的来源）是分散的能力，每个人都有自己的存储库并在需要时合并存储库。我对这个功能不感兴趣，实际上我想将所有内容集中在一台服务器上，既适用于我单独工作的项目，也适用于多个人应始终拥有最新源的项目。相同的服务器，没有或只有最少量的分支/分支。
考虑到这一点，目前大多数开发是在Windows上使用Visual Studio完成的，并且还需要使用一些简单的svn命令从Linux进行访问，GIT仍然是一个不错的选择吗？是否值得转换？ GIT提供哪些其他功能对我们有益？
答案 0 :(得分：5)
让我直截了当。
那么，为什么要切换到Git？
我知道Git上有很多关于“比Subversion更好”的喋喋不休，但大多数人都是真正不知道版本控制的人。他们看到许多开源项目使用Git并假设如果Linux使用Git，它必须更好。
我同时使用Git和Subversion，并发现每个人都有自己的优点和缺点。
当您有客户强加的可交付成果和发布截止日期时，Git的问题就会出现。 Git只是在持续集成环境中不能很好地工作，除非你像母鸡一样在你的开发人员身上。发生的情况是，在发布周期结束之前，不会向中央存储库发送任何更改。然后，在发布的最后几天，你一直试图处理不兼容，冲突和其他问题。
使用像Subversion这样的集中式存储库，开发人员不得不一起工作。他们在代码中进行更小，更多的增量更改。通过良好的持续集成环境，您的QA团队可以提取中间版本并进行测试，而无需等待最终版本。
作为奖励，Subversion通过AnkhSVN与VisualStudio进行了出色的集成。 VisualStudio最终有Git Source Code Provider，但它依赖于TortioseGit和BASH shell。同时，AnkhSVN是一个完全封装的源代码提供程序，其界面类似于使用VisualStudio或TeamFoundation，因此VisualStudio开发人员非常熟悉它。
因此，除非所有您的开发人员都想要Git，或者您打算使用Git的分布式功能，否则没有理由仅仅为了切换而进行切换。
答案 1 :(得分：3)
您可能希望从SVN切换到Git有两个主要原因：
但是，正如你所提到的，Git告诫它不能集中化：好吧，你可以拥有一个中央服务器，但你也需要一个本地仓库，所以开发人员需要：
两个步骤。通常它不会成为一个问题，但有些情况下它可能是继续使用SVN的主要原因。
话虽如此，虽然Git是一个很好的选择，但考虑到你基本上是在Visual Studio上......你为什么不看看www.plasticscm.com（免责声明：我为这家公司工作） 。我们最近发布了一个功能，允许您直接推送到git服务器...以防您需要混合方法：http://codicesoftware.blogspot.com/2012/10/direct-pushpull-from-plastic-scm-to-git.html。它可以完全集中作为选项（SVN风格），但具有所有合并功能，图形和VStudio集成。
答案 2 :(得分：2)
目前我在Windows上使用Git和Visual Studio，我喜欢它。但是，我刚才在Linux上学习过Git。最初，我正在为我当时工作的一个项目运行git-svn。虽然git-svn不允许利用所有Git功能，但对我来说，通过Git找到自己的方式并让自己相信Git对我们的开发很有用。只有在那之后我们决定将该存储库从SVN转换为Git。
我认为Git的主要优点是它足够灵活，可以适应不同的工作流程。因此，您可以选择最适合您的开发团队的内容。集中式与分布式不是两个特定工作流程之间的选择，而是大量可能的工作流程之间的选择。如果您决定使用类似于SVN的集中式工作流程，那么使用Git仍然有一些优势。
首先，在与上游合并之前提交更改。在你有机会提交你的工作之前，SVN强迫你做“svn update”。这意味着如果您在合并期间犯了错误，您可能会失去工作。在SVN中，您无法丢弃当前的合并状态并重新进行重做。此外，除非此人可以直接访问您计算机上的工作树，否则您无法请求更有经验的人帮助进行非平凡的合并。
一般而言，提交和合并会使您的历史记录更加真实，因为它显示了您所做更改的实际状态以及您如何解决冲突。缺点是历史不再是线性的。使用Git，您可以通过执行“git pull --rebase”（可以配置为默认值）来保留线性历史记录，这使您的历史记录与SVN一样线性。
SVN的第二个问题是当您将更改提交到中央存储库时，您永远不知道其他人是否同时进行了更改。如果对不同的文件进行了这些更改，SVN将接受您的ChangeSet。因此，您在SVN存储库中有一个没有人测试过的新状态。通常，对不同文件所做的更改不会导致问题，但有时可以。例如，一个开发人员更改了C标头中的某些功能以及使用它的所有位置，但另一个开发人员在新代码中添加了此功能的新用法。因此，即使每个开发人员测试了他或她的更改，您最终也可能在主开发分支上出现故障状态。开发人员可能不会立即注意到这种破坏，直到有人说“svn update”，但此时这个人可能会有他/她自己的更改，因此在某些情况下可能会非常混乱。
另一个有用的Git功能是它允许你尝试一些想法，而不会向trunk提交任何内容。然后，如果它没有成功，你可以丢弃它，没有人会注意到。我并不是想隐瞒别人的东西，但我不想强迫其他人将他们的工作与我的实验性东西合并，最后可能会将其删除。此外，删除此实验代码会成为问题，因为它与其他更改交织在一起。因此，如果您使用SVN，那么在您使用此功能时，您唯一的选择就是不提交任何内容。然而，它导致最后一个巨大的补丁炸弹，而不是小的逻辑步骤，这是要么在出现问题时进行审查和平分。
顺便说一句，git-bisect对于在代码中对抗棘手的回归非常有用。如果某些事情被破坏，可能并不明显是什么以及为什么。所以你需要找到引入这个问题的提交，而git-bisect是这项工作的最佳工具。最后，您还有更多选择来决定如何更好地处理某些情况。例如，您的核心团队成员可以将他们的更改直接推送到“trunk”（在Git中通常称为“master”），但您可能不希望新分配的人员在没有任何审核的情况下推送他的更改。因此，只需告诉他将更改推送到同一中央存储库中的单独分支，然后通过电子邮件发送给他的导师，如果他们是好的，他将审核并合并这些更改。分支在Git中非常便宜，你不应该害怕使用它们。将短期主题分支合并到上游时，通常会删除其名称，因此不会使分支命名空间混乱。
答案 3 :(得分：1)
考虑到这一点，目前大多数开发是在Windows上使用Visual Studio完成的，并且还需要使用一些简单的svn命令从Linux进行访问，GIT仍然是一个不错的选择吗？
是的，确实如此。 Git将允许您使用版本控制作为备份系统（仅在本地提交内容并在具有完整功能时发布）和探索性工作（新分支中的原型新功能，如果它不起作用，则删除分支）。 / p>
Git的分布式特性并不妨碍在集中式环境中工作，它只是不强加它。
是否值得转换？
在我看来，是的。我已经使用了很多源代码控制系统，在切换到分布式（当时是mercurial）之后，对我工作的影响非常大，以至于下次我不得不与SVN合作完成一个项目时，我在本地安装了mercurial最重要的是，“本地提交”和无痛的合并能力。
GIT提供哪些其他功能会使我们受益？
分支将允许您在不影响整个团队的情况下分享不完整的工作。这意味着您可以将您的工作发送给同事进行审核，反馈，测试或贡献，而不会影响主要分支。
本地提交将允许您同时处理多个功能（根据需要在它们之间切换，或保存当前的工作，切换到其他功能，然后无痛地返回）。它们还允许您将版本控制系统用于备份点（因为您可以提交任何内容，无论它是否编译或代码是否干净，经过测试或审查，如果代码无法编译，则不会影响其他人）。
例如，我有一个代码清理分支，当我没有其他任务（或无聊或有一点时间）时，我工作。当我清理文件或模块时，我只在服务器上推送它。
（本地）分支还允许您处理影响整个代码库（或其大部分）的更改，而不会让团队的其他成员“在您提交之前不做任何事情”，这样他们就不会引入合并冲突你同步。
还有另一个方面：使用SVN，添加不完整的代码会强制您将其放在奇怪的#ifdef FEATURE_NAME块中，这样即使代码不完整，其他人也可以解决半实现的功能。使用git，您根本不需要，因为不完整的更改可以根据需要保存在分支（本地或集中）中。这样可以最大限度地减少代码损失。
答案 4 :(得分：0)
我现在正在我的企业中实施高度集中的工作流程，是的，Git在该设置中工作正常
唯一的问题是添加集中式服务器所需的适当身份验证和授权层，以允许或拒绝git（推/拉/克隆）操作。
有关详情，请参阅“Distributed Version Control Systems and the Enterprise - a Good mix?”。
答案 5 :(得分：0)
git非常灵活。您可以以集中或分散的方式使用它。这真的是关于工作流程。如果你想在同一页面上的所有开发人员，每个人都需要定期推/拉/取。 github有很多很棒的通知功能可以提醒人们更新（例如电子邮件和原子提要）。我们在工作中支付私人回购，我经常使用这些饲料。