我想向我的老板推荐 Git 作为一个新的源代码控制系统，因为我们被 VSS 困在 90 年代（哎呀），但是工具和 3rd 方支持是否足够好呢？
具体来说，我说的是类似于 TortoiseSVN 的 GUI 前端、不错的视觉差异/合并支持，以及电子邮件提交通知和来自 IDE 和构建系统等第三方的一般支持。
尽管这将被程序员使用，但我们的团队中确实需要这种东西。我不想让每个人都坚持使用新工具，甚至是新的源代码控制范例（分布式），只有命令行应用程序和一些在线教程。这将是一个倒退。
那么你觉得... Git 准备好了吗？Git 有哪些不错的工具，哪些第三方开发应用程序支持它？
编辑：我最初的问题非常含糊，所以我正在更新它以专门要求提供可用工具列表和对 Git 的第 3 方支持。也许我们可以得到一个包含内容列表的社区 wiki 帖子。
我也不认为“使用颠覆”是一个充分的答案。除了离线编辑之外，还有其他使用分布式源代码控制系统的原因——私人和廉价的分支就是其中之一。
取决于团队。如果你是一个精通技术的团队的一员，那么 git 是很棒的（而且通常不仅仅是很棒）。但是如果有些人在命令行上不习惯，可能会有一些麻烦（因为tortoisegit还处于起步阶段，坦率地说，我遇到的所有其他 GUI 都很糟糕）。
如果你要处理技术不高的人（设计师、高层管理人员等），我会选择颠覆之类的东西。TortoiseSVN非常棒（而且相当容易使用），svn 可能拥有 80% 的 git。
一个更简单的方法（我已经成功地做到了）是建立一个中央 Subversion 存储库，它为每个人提供了像 TortoiseSVN 这样的好工具。然后，想要将git-svn完整的 Git 环境用作 Subversion 客户端的开发人员。
这非常有效，因为仍然有一个中央存储库，每个人都知道给定的更改要么已提交，要么尚未提交。然后，在边缘，人们可以使用他们想要的工具（Git）来完成他们的工作。
我们在我的公司使用 git，根据您对可视化工具的要求，我会拒绝。tortoisegit 来了，但还没有到。GitX 和 GitNub 之类的工具在 OS X 中很棒，但它们并不能完全涵盖您所描述的所有内容。
不过，给它时间。Git 正在以相当快的速度发展，并且由于这种增长，对可视化工具的需求也在增加。
您可能会遇到的最大问题是范式转变。这不是最容易掌握的东西，而且你的团队中的一些人会感到沮丧，因为他们已经习惯了使用 Git 及其更分布式的特性（尽管我不喜欢称它们为分布式 SCM）。
话虽如此，使用 Git 和我的公司都很棒，我很乐意看到另一家公司加入其中。
从 VSS 迁移到 Subversion 已经是一个很好的升级。Subversion 将为您提供出色的功能，例如原子提交、出色的 GUI、与 IDE 的集成、出色的 Windows 体验、变更集的概念、可靠的存储库等。对于具有中小型团队的典型 Windows 公司，我认为 subversion 是一个很棒的工具。
如果您对分布式 VCS 感兴趣，那么您应该关注 git、hg、bzr。就 Windows 支持而言，hg 和 bzr 领先于 git。但是，有一个用于 Windows (msysgit) 的移植命令行版本的 git，它将更改合并回主 git。git 社区也在快速增长，因此我希望 Windows 体验会有所改善。
Git支持混合场景，服务器可以是CVS/SVN，个人开发者可以使用git-svn在本地工作，管理本地分支。这种设置提供了两全其美的效果。然而，由于对 Perl SVN 库的依赖，git-svn 在 Windows 上是不稳定的。在这种情况下，使用 git 的好功能并不像开发人员共享分支等那么容易。
鉴于您的项目不是开源的，我认为 Subversion 可能会提供您需要的所有功能。一旦 Git 达到您需要的 Windows 可用性栏，您就可以将您的 SVN 存储库导入 Git。
除非您的公司对分支和合并很重视，否则我会选择 SVN，否则，您将需要仔细考虑 DVCS。
我一直在做一个开源项目，存储库存储在 CVS 中，然后迁移到 SVN，然后迁移到 Git。每一步都是一次重大升级。SVN 迁移到 Git 的主要动机是让贡献者更容易维护他们自己的分支，让它们保持最新，将它们推送给开发人员，并让开发人员轻松地以最少的努力应用它们。
当谈到git的图形工具时，到目前为止我使用的唯一有用的工具是 gitk（它为您可视化修订树），我自己在过去半年一直在使用 git，正如其他人所说的那样, TortoiseGit还很早，还有一些问题需要解决。
在工作中，我们一直在评估三种不同的 DVCS（即 git、mercurial (hg)和bazaar），并在一个人满为患的晚上向公司的其他人展示了它们。Mercurial 收到了最积极的回应，并且它有一个Tortoise变体。
我建议你做同样的事情。找一个可以提供 git 替代方案的人（例如 mercurial 或 bazaar） ，并在您的公司一起在DVCS上进行演示。告诉你的同事 DVCS 有多棒比告诉老板更重要，因为他们最终会使用它。因此，如果他们接触过这些工具并亲自体验一下，就会更有教育意义。
当我们介绍它时，我们还假设人们没有进行版本控制，因此我们快速解释了基本概念，例如checkin-checkout与commit-merge以及为什么人们进行版本控制。基本上，它就像Eric Sink 关于版本控制的文章，但被精简为基本要素。
由于您来自 VSS（我很抱歉），您可能想看看SVN。然而，在我看来，分布式和集中式方法之间的唯一区别是通过对等网络共享代码增加了复杂性。
Windows 的默认 git GUI 很糟糕，并且容易陷入重新扫描循环。我现在使用命令行客户端，只要您可以处理使用 vi 来制作日志条目，这似乎很好。我刚开始使用 github，这还可以，但导航很糟糕。
就个人而言，我所做的几乎所有事情都使用 Subversion 和 Apache。Subversion 效果很好，文档齐全，易于设置且免费。
大多数典型规模的公司真的需要分布式源代码控制吗？
Git 非常适用于开源项目，在这些项目中，来自世界各地的人们在截然不同的时间就一个项目进行协作，其中签入的有效性取决于绩效和信任网络。
在一家公司，例如，提交需要 QA 分析或配置经理的批准和/或文档，或者为了使修订号与错误报告中的一致，我会提交 Git 等分布式控制确实没有意义，从某种意义上说，范式转变是没有必要的；它还不能很好地适应现有的 CM 流程（一个社会问题）；它不能很好地与现有工具、第三方和其他工具集成；并且它对 Windows 的支持很差。
不是说不好；我非常怀疑它是否适合大多数企业环境。我期待其他一些回应以获得洞察力。
我是 GIT 的新手，在使用了几周后不得不说它真的很棒，一旦你掌握了命令行提示符。
回答您的问题“Git 准备好了吗？” => 我认为是（命令行学习曲线除外。）
我认为你和你的团队/公司应该问自己“你准备好使用 git 了吗？”。一旦开始使用它，您显然将拥有触手可及的强大功能。
学习 git 的第一步是：
就在 Spoike 提到 TortoiseHg for Mercurial 之后，Bazaar 的 Windows 独立下载最近确实包括 TortoiseBzr，尽管它被标记为实验性的。
我在很多版本之前尝试过它，发现它不稳定，但从那时起它可能已经有了很大的改进（特别是如果他们愿意将它与官方 Bazaar 版本打包在一起）。
如果你真的想要一个像乌龟一样的界面的去中心化版本控制，我会试一试，看看它们是如何公平的。
E.
当我第一次接触 Git 时，我的第一反应是“我就是不 Git”。我看到了许多强大的工具，但它们不是很直观。当我习惯使用 Git 时，我意识到我真正喜欢的唯一功能是快速便宜且简单的分支。
我尝试了一些图形前端，包括 Git 附带的 GTK。我发现这些比命令行操作更令人困惑。
如果您的公司习惯于 Subversion，并且您需要更改为 DVCS，请尝试 Mercurial。Subversion 用户很快就会有宾至如归的感觉。然而，很少有人能真正理解 Mercurial 关于分支应该是什么的想法......首先在脚上使用 DVCS 进行哪种射击（除非能够在本地提交并在推送之前推/拉其他人到主存储库）。
我每天都使用 Subversion 和 Mercurial，它们非常适合我的所有项目。我认为，除非你需要 Git 的分支能力和编辑以前版本的能力...... Subversion 或 HG 将是你最好的选择。我不会推荐 Git 作为任何人第一次接触 DVCS，而只是我的意见和经验。
有一个关于GIT的非常好的播客。
当然，我认为 Git 已经准备好了。只需确保您在项目计划中有时间让人们在切换时习惯它......
大多数第 3 方应用程序（Eclipse 除外）中是否支持 Git？对我见过的很多人来说都不是。
Git 可能不会完全取代 SVN——它们的不同之处足以让每个人都可能在一段时间内扮演自己的角色。无论如何要回答整个问题：不，它还没有准备好进入商业世界的黄金时段。也许有一天，在某些情况下（可能不是所有情况），但当然它仍然太新——很多人甚至还没有听说过！只是建议您对其进行演示以获得支持这一事实应该是一个危险信号。如果你现在去开发者那里说你想搬到 SVN，唯一不会立即理解的是那些生活在岩石下的人，谁在乎他们？
此外，更新并不总是更好。这种类型的范式转变需要时间才能被确认为一种改进——看看随着时间的推移对 Maven 的强烈反对。不要这么快就从一个经过验证的解决方案跳槽，当你的工作和声誉受到威胁时不要这么快——如果 Git 不成功，你不会推荐它。至少对于像 SVN 这样的产品，你有一个事实，它不是新的，它肯定会随着时间的推移得到证明，即使存在问题，也不能过于严厉地质疑建议，因为它仍然是大多数开发人员的默认答案。转向行业标准比转向新的和非标准的东西更难攻击建议。
不是你想听到的答案（看来你已经做出了决定），而是问问自己，好处（和分支是应该避免的，而不是鼓励的）是否真的超过了风险。