我已经使用 subversion 有一段时间了，我正在考虑学习并切换到 GIT，因为现在它似乎是大多数人的偏好。
尽管如此，GIT 的最大优势之一（及其复杂性的来源）是去中心化的能力，每个人都有自己的存储库并在需要时合并存储库。我对这个功能不感兴趣，实际上我想把所有东西都集中在一个服务器上，无论是对于我独自工作的项目，还是希望多人始终拥有最新源的项目都存储在同一台服务器，没有或只有最少数量的分支/分叉。
考虑到这一点，并且目前大多数开发都是在 Windows 上使用 Visual Studio 完成的，并且还需要使用一些简单的 svn 命令从 Linux 进行一些访问，GIT 仍然是一个不错的选择吗？值得转换吗？GIT 还提供了哪些其他使我们受益的功能？
让我说清楚。
那么，为什么要切换到 Git 呢？
我知道有很多关于 Git“比 Subversion更好”的议论，但其中大部分是真正不了解版本控制的人。他们看到许多开源项目使用 Git，并假设如果 Linux 使用 Git，它一定会更好。
我同时使用 Git 和 Subversion，发现它们各有优缺点。
当客户要求交付成果和发布截止日期时，Git 的问题就会开始显现。Git 在持续集成环境中不能很好地工作，除非您像母鸡一样对待您的开发人员。发生的情况是在发布周期结束之前，不会将任何更改传递到中央存储库。然后，您在发布的最后几天被困在试图处理不兼容、冲突和其他问题。
使用像 Subversion 这样的集中式存储库，开发人员被迫一起工作。他们在代码中进行更小、更增量的更改。借助良好的持续集成环境，您的 QA 团队可以提取中间版本并进行测试，而无需等待最终版本。
作为奖励，Subversion 通过 AnkhSVN 与 VisualStudio 进行了出色的集成。终于有了VisualStudio 的Git 源代码提供程序，但它依赖于 TortioseGit 和 BASH shell。同时，AnkhSVN 是一个完全封装的源代码提供者，其界面类似于您使用 VisualStudio 或 TeamFoundation，因此 VisualStudio 开发人员对它非常熟悉。
所以，除非你所有的开发者都想要 Git，或者你打算使用 Git 的分布式特性，否则真的没有理由仅仅为了切换而切换。
您可能想要从 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，我喜欢它。不过，我是在不久前开始在 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 特性是它允许你在不提交任何东西到主干的情况下尝试一些想法。然后，如果它不起作用，你可以丢弃它，没有人会注意到。不是我喜欢向别人隐瞒一些东西，而是我不想强迫其他人将他们的工作与我的实验性东西合并，这些东西最终可能会被删除。此外，删除此实验代码会成为问题，因为它与其他更改交织在一起。因此，如果您使用 SVN，您唯一的选择就是在使用此功能时不提交任何内容。然而，它最终导致了一个巨大的补丁炸弹，而不是小的逻辑步骤，即在出现问题时要么进行审查和平分。
顺便说一句， git-bisect 对于对抗代码中棘手的回归非常有用。如果有东西坏了，可能不清楚是什么以及为什么。所以你需要找到引入这个问题的提交，而 git-bisect 是完成这项工作的最佳工具。
最后，您有更多选择来决定如何更好地处理某些情况。例如，您的核心团队成员可以将他们的更改直接推送到“主干”（在 Git 中通常称为“主控”），但您可能不希望新分配的人在没有任何审查的情况下推送他的更改。因此，只需告诉他将他的更改推送到同一中央存储库中的单独分支上，然后给他的导师发送电子邮件，如果这些更改是好的，他将审查并合并这些更改。Git 中的分支真的很便宜，你不应该害怕使用它们。当一个短暂的主题分支被合并到上游时，它的名字通常会被删除，所以它不会使分支命名空间混乱。
考虑到这一点，并且目前大多数开发都是在 Windows 上使用 Visual Studio 完成的，并且还需要使用一些简单的 svn 命令从 Linux 进行一些访问，GIT 仍然是一个不错的选择吗？
是的。Git 将允许您将版本控制用作备份系统（仅在本地提交内容并在您拥有完整功能时发布）和用于探索性工作（在新分支中对新功能进行原型设计，如果它不起作用，则删除分支）。
Git 的分布式特性不会妨碍使用集中式环境，它只是不会强加它。
值得转换吗？
在我看来，是的。我使用过很多源代码控制系统，在切换到分布式（当时是 mercurial）之后，对我的工作影响如此之大，以至于下次我不得不使用 SVN 进行项目时，我在本地安装了 mercurial最重要的是，“本地提交”和无痛合并功能。
GIT 还提供了哪些其他使我们受益的功能？
分支将允许您在不影响整个团队的情况下共享未完成的工作。这意味着您可以将您的工作发送给同事进行审查、反馈、测试或贡献，而完全不会影响主要分支。
本地提交将允许您同时处理多个功能（根据需要在它们之间切换，或保存您当前的工作，切换到其他内容，然后轻松返回）。它们还允许您将版本控制系统用于备份点（因为您可以提交任何内容，无论它是否编译或代码是否干净、经过测试或审查，如果代码未编译，则不会影响其他所有人）。
例如，我有一个代码清理分支，当我没有其他任务（或者很无聊，或者有一点时间）时，我会处理它。我只在清理文件或模块时将其推送到服务器上。
（本地）分支还允许您处理影响整个代码库（或大部分代码库）的更改，而无需让团队的其他成员“在您提交之前什么都不做”，这样他们就不会在您同步时引入合并冲突。
还有另一个方面：使用 SVN，添加不完整的代码会迫使您将其放置在奇怪#ifdef FEATURE_NAME的块中，这样即使代码不完整，其他人也可以解决半实现的功能。使用 git，您根本不需要这样做，因为您可以根据需要将不完整的更改保存在分支（本地或集中式）中。这最大限度地减少了代码混乱。
git 非常灵活。您可以以集中或分散的方式使用它。这真的是关于工作流程。如果您希望所有开发人员都在同一页面上，则每个人都需要定期推送/拉取/获取。github 有很多很棒的通知功能来提醒人们更新（例如电子邮件和 atom 提要）。我们在我的工作中为私人回购付费，而且我经常使用这些提要。
我现在正在我的企业中实施高度集中的工作流程，是的，Git 在该设置中运行良好。
唯一的问题是添加中央服务器所需的适当身份验证和授权层，以允许或拒绝 git（推/拉/克隆）操作。
有关更多信息，请参阅“分布式版本控制系统和企业 - 一个好的组合？ ”。