我一直在使用Subversion，但现在考虑学习并转换到GIT，因为它似乎是大多数人的首选。
然而，GIT的最大优势（也是其复杂性的源头）之一是分散能力，每个人都有自己的存储库，并在需要时合并存储库。我对这个功能不感兴趣，实际上我希望将所有内容集中在单个服务器上，无论是我独自工作的项目，还是预计多人随时在同一服务器上存储最新源代码的项目，没有或只有少量分支/派生。
考虑到这些情况，以及目前大部分开发都在Windows上使用Visual Studio进行，还需要从Linux使用一些简单的svn命令进行访问，那么GIT是否仍然是一个好的选择？是否值得转换？GIT还提供了哪些功能可以使我们受益？
让我来理一下。
那么，为什么要转换到Git呢？
我知道有很多关于Git“比Subversion更好”的议论，但大多数人并不真正了解版本控制。他们看到许多开源项目使用Git，并认为如果Linux使用Git，它一定更好。
我同时使用Git和Subversion，发现它们各有优势和劣势。
当您有客户强制要求的交付物和发布截止日期时，Git的问题开始显现出来。除非你像母鸡一样盯着你的开发人员，否则Git在连续集成环境中表现不佳。它的问题在于，在一个发布周期结束之前，没有任何更改会被提交到中央仓库。然后，在发布的最后几天，你会陷入处理不兼容性、冲突和其他问题的困境中。
使用类似Subversion这样的集中式仓库，可以强迫开发人员进行合作。他们对代码进行较小的、更增量的更改。在良好的连续集成环境下，你的QA团队可以提取中间版本并进行测试，而不必等待最终版本。
作为一个额外的奖励，Subversion通过AnkhSVN与VisualStudio完美地集成。虽然现在也有一个Git源代码提供程序，但它依赖于TortioseGit和BASH shell。与此同时，AnkhSVN是一个完全封装的源代码提供程序，其界面与使用VisualStudio或TeamFoundation类似，因此VisualStudio开发人员非常熟悉。
因此，除非所有的开发人员都想要Git，或者您计划使用Git的分布式特性，否则没有理由只是为了换而换。
git clone命令。 - utnapistim有两个主要原因让你可能想从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集成。
目前我在Windows上使用Visual Studio的Git，我很喜欢。然而，我之前学习Git时是在Linux上开始的。当时，我正在一个项目上运行git-svn。虽然git-svn不能利用所有Git功能，但它足够好让我找到了使用Git的方法并使自己确信Git对我们的开发有用。只有在那之后，我们才决定将该存储库从SVN转换为Git。
我认为Git的主要优点是它灵活到可以适应不同的工作流程。因此，您可以选择最适合您的开发团队的工作流程。集中式与分布式不是两个特定工作流程之间的选择，而更多地是在大量可能的工作流程之间进行选择。如果您决定采用类似于SVN的集中式工作流程，则仍然可以使用Git的一些优点。
首先，您需要在与上游合并之前提交更改。SVN强制您在提交工作之前进行“svn更新”。这意味着，如果您在此合并过程中犯错，您可能会丢失您的工作。在SVN中，您无法放弃当前的合并状态并重新执行它。除非此人直接访问您计算机上的工作树，否则您无法请求更有经验的人来帮助解决非常规的合并。
总的来说，提交和合并使您的历史记录更加真实，因为它显示了在哪个状态上进行了您的更改以及如何解决冲突。缺点是历史不再线性。使用Git，您可以通过执行“git pull -rebase”（可以配置为默认选项）来保留线性历史记录，这使得您的历史记录与SVN的历史记录一样线性。
第二个问题是，在将更改提交到中央存储库时，您永远不知道其他人是否同时进行了更改。如果这些更改是针对不同文件的，则SVN将接受您的ChangeSet。结果是，您在SVN存储库中有一个未经测试的新状态。通常，对不同文件进行的更改不会引起问题，但有时可能会。例如，一个开发人员更改了C头文件中的某个函数以及其使用的所有位置，但另一个开发人员在新代码中添加了该函数的新用法。因此，即使每个开发人员都测试了他或她的更改，您也可能会在主开发分支上出现错误状态。开发人员可能不会立即注意到这种故障，直到有人说“svn更新”，但此时此人可能已经拥有自己的更改，因此在某些情况下可能非常令人困惑。
Git的另一个有用功能是它允许您尝试某些想法而不将任何内容提交到主干。然后，如果它行不通，您可以放弃它，而没有人会注意到。不是我喜欢向别人隐藏什么，而是我不想强迫其他人与我的实验性东西合并，这可能会在最后被删除。此外，删除这个实验性代码变得很麻烦，因为它与其他更改交织在一起。因此，如果您使用SVN，则您在开发此功能时唯一的选择是不提交任何内容。但是，这会导致大量逻辑步骤的补丁轰炸，而不是小型逻辑步骤
顺便提一下，git-bisect 可以帮助你解决代码中的棘手问题。如果出现问题，可能不太明显是什么和为什么出了问题。因此，您需要找到引入此问题的提交，而 git-bisect 是进行此工作的最佳工具。
最后，您有更多选择来决定如何更好地处理某些情况。例如，核心团队的成员可以直接将其更改推送到“trunk”（在 Git 中通常称为“master”），但您可能不希望新分配的人在没有任何审查的情况下推送他的更改。因此，只需告诉他将他的更改推送到同一中央存储库中的单独分支上，然后发送电子邮件给他的导师，如果更改好，则会将其审核并合并。在 Git 中，分支非常便宜，您不必担心使用它们。当短期主题分支合并到上游时，通常会删除其名称，因此它不会混淆分支命名空间。
本地提交允许您同时处理多个功能（根据需要在它们之间切换，或保存当前工作，切换到其他内容，然后轻松返回）。它们还允许您使用版本控制系统作为备份点（因为您可以提交任何内容，而不管它是否编译或代码是否干净、经过测试或审核，如果代码无法编译，则不会影响其他人）。
例如，我有一个代码清理分支，当我没有其他任务（或感到无聊或有一点时间）时，我会在上面工作。只有在我清理文件或模块时才将其推送到服务器上。
（本地）分支还允许您处理影响整个代码库（或其中大部分）的更改，而不必让团队的其他成员“等待您提交”，以便他们在同步时不会引入合并冲突。
还有另一个方面：使用 SVN 添加不完整的代码会强制您将其放置在奇怪的 #ifdef FEATURE_NAME 块中，以便即使代码不完整，其他人也可以绕过半实现的功能进行工作。使用 Git，您根本不需要这样做，因为不完整的更改可以按需保存在分支（本地或集中式）中。这最小化了代码混乱。
我目前正在我的企业中实施高度集中化的工作流程，是的，Git在这种情况下运行良好。
唯一的问题是添加适当的身份验证和授权层，以便集中服务器允许或拒绝git（push/pull/clone）操作。
请参阅“分布式版本控制系统与企业-良好的组合吗？”了解更多信息。
Git非常灵活。您可以将其使用在集中式或分散式环境中。真正的关键在于工作流程。如果您想让所有开发人员都了解最新情况，每个人都需要定期进行push / pull / fetch操作。GitHub具有很多出色的通知功能，可通过电子邮件和Atom提醒人们更新。在我的工作中，我们为私有仓库付费，我经常使用这些提要。