我现在使用的是 SVN，过去我使用过 CVS 和 VSS。 SVN 是我目前最喜欢的书籍，但我听说过很多关于 git 的信息。在使用过 git 的人中，您的经验有哪些优缺点？
【问题讨论】：
--depth 1，您也会获得巨大的其他开销，如果您的连接不稳定且速度较慢，甚至可能无法获得它
标签： git version-control
很好的问题，我使用 SVN 已经有一段时间了，感觉很舒服。但我不得不多次使用 Git 从不同的开源项目中获取源代码。我仍然没有花时间真正了解它。值得吗？
我还想问，使用分布式版本控制而不是普通 VCS 作为颠覆有什么优势。
【讨论】：
我对 git 没有很多经验，但是：
优点：
（除了能够拥有本地存储库并推送到公共存储库之外，我还没有真正“需要”事物的分布式方面。）
缺点：
git add 的修改）这一事实采取了需要一段时间才能掌握【讨论】：
Skeet 大部分都有，但是：
专业版：
【讨论】：
在 git 中合并要简单得多，因为创建分支是默认设置，而不是额外的选项。因此，当您必须合并某些内容时，您只需提交它，然后合并两个分支（现有分支和 git 为您上次签入自动创建的新分支）。
此外，使用 git 时，您始终拥有整个存储库。您可以在离线时签入并稍后合并（因为合并要简单得多）。
缺点是 GIT 在 Windows 上的 USB 驱动器上几乎无法使用。 Windows 禁用这些缓存，而 GIT 可以处理数百万个小文件。此外，仍然缺乏 IDE 支持。我不确定后者是否真的是一个问题。 GIT自带的UI挺好看的。
另外，我不是 100% 高兴您必须一直“添加”现有文件 [编辑] 和大量功能。对于初学者来说，它们是压倒性的，而且通常不清楚为什么要使用某个选项/命令。我的意思是，CVS 附带了 20 个命令。 GIT 有 73 个，每个都有很多选项（这还不包括管道命令......）。
【讨论】：
Windows 支持令人震惊，所以我转到 Mercurial，另一个同样出色的 DVCS。
例如，当您在办公室的服务器中有一个存储库并且您在现场工作时，DVCS 的优势就会变得明显。能够在不访问服务器办公室的情况下进行本地提交（必要时进行回滚）非常棒！
【讨论】：
很多人会否认这一点，但源代码管理工具的选择会影响您的工作方式。我过去经常使用 Subversion，直到我发现了 Git。我主要避免在 Subversion 中进行分支。每当我无法避免时，我更喜欢设置本地镜像（使用 svk）。虽然在 Subversion 和 Git 中都可以轻松完成分支，但只有 Git 使合并（和变基！）变得有趣，Subversion 一直是合并时间的一大难题。
我真正喜欢 Git 的第二件事（除了已经提到的所有要点）是“索引”，一个保存下一次提交的暂存区域，并且可以仅添加已更改文件的单个块给它。
【讨论】：
最新版本的Git可以直接在Window'命令提示符下工作，我就是这么用的。这个过程现在对我来说相当简单。
我还在外部硬盘驱动器和我的 jumpdrive 上安装了 Git。每当在一台新计算机上，我都会运行一个脚本来临时设置包含 Git 工具的路径。然后就可以继续开发了！
【讨论】：
专业版：
缺点：
【讨论】：
使用 git 与使用其他版本控制系统非常不同。
拥有本地存储库非常重要。这意味着您可以在不打扰任何人的情况下使用版本控制系统的全部功能（这对于 git 来说很重要）。如果您的项目中存在有争议的问题，您可以私下处理它 - 通过创建分支、堆叠补丁和完善它们。这样你就可以带着熨烫的补丁集回来。但即使在“正常操作”中，如果您可以在向公众展示补丁之前清理它们会更好，事实上，如果您有健全的补丁，而不仅仅是“一天结束”的快照，调试会容易得多。
在我提交更大的补丁集之前，我通常会将新代码上的补丁重新排序并将错误修复直接压缩到补丁中。所以补丁看起来我从来没有犯过任何错误。之后，我的私人分支重新建立在 HEAD 之上，然后推送。我通常从不使用合并，因为它只会弄乱历史记录。
简而言之：它可以让您的历史保持干净。
这让您对自己的工作有非常不同的看法。它允许您将当前状态视为单个补丁的添加，这些补丁创建的历史不仅是日志，而且是您故意放在那里的东西。补丁集是您构建应用程序的基石 - 如有必要，可以移动到正确的位置。
我永远不会自愿回到我在 git 之前使用的任何其他版本控制系统或任何不支持变基和本地分支和提交的版本控制系统。
【讨论】：
其他注意事项：
优点：
缺点：
【讨论】：
命令数
虽然 svn 和其他现代 VCS（如 hg 或其他）都是不错且有用的工具，但 git 是一个充满机床的商店。这同时占优势和劣势。虽然 svn 有 30 个命令（根据 'svn help'），但 git 提供了 130 个手册页，每个手册页或多或少地描述了一个命令。原因之一是 git 公开了大多数用户作为命令行工具所需要的较低级别的功能。但即使没有这些低级命令，git 也提供了许多非常强大的工具，并且在我所知道的任何其他 VCS 中都找不到（参见 git-bisect、git-filter-branch、git-cherry 或 git-reset 示例）。虽然手头有这些工具非常有帮助，但初学者很难理解他们需要和需要知道哪些命令，哪些不需要。
开发模式
一个类似的话题是 git 足够强大，可以支持非常不同的操作模式。这对初学者来说很困难，因为没有真正的“最佳实践”文档，因为最佳实践没有内置到 git 中。所以你必须自己决定你是否
由于您拥有本地存储库，您甚至可以使用与您正在处理的项目完全不同的操作模式，只需在推送/发布它们之前调整您的更改集。
变化路径
根据您的观点，另一件事也算得上是优缺点是，使用 git 比使用任何集中式 VCS 更复杂，甚至比大多数其他分布式 VCS 更复杂。
使用集中式 VCS，您通常只需进行提交，所做的更改就会转到存储库。在 git 中，更改在到达最终目的地之前可能会经历很多步骤。典型的步骤是（括号中不是那么常见的步骤）：
由于您可以跳过索引，因此至少涉及 2 个步骤，但通常还有更多。这需要更深入地了解您在做什么并输入更多命令。另一方面，这使您可以控制这些步骤中的每一个。你可以
所有这些权力和决定使初学者很难开始使用 git。一旦掌握了，他们就可以对代码进行极大的控制。
写入权限
任何分布式 VCS 的一个主要优点是贡献者不需要写入权限即可从 VCS 中受益。每个具有读取权限的人都可以克隆存储库，在必要时创建分支并开始堆叠放置补丁集。在没有写访问权限的情况下使用 cvs 是一件非常痛苦的事情——使用 git，获取补丁的方式并没有太大的不同。 这不仅是技术上的优势，还可以省去这个菜鸟是否真的应该获得写入权限的复杂讨论。
【讨论】：
【讨论】：
优点：
缺点：
autocrlf 在 Windows 中的奇怪行为
无法移动/重命名文件或 dir insode repo 并保留其提交历史记录（git mv 只是从 repo 中删除文件，重命名并再次将其添加到 repo，从而丢失所有历史记录）
【讨论】：