使用之后，你的git的优缺点是什么？
我现在正在使用SVN，过去我使用过CVS和VSS。 SVN是我目前最喜欢的书，但是我已经听说过很多关于git的东西。 在使用git的人中，你的经验有什么优点和缺点？
我对git没有太多的经验，但是：
优点：
- 这真的很快
- 当地提交摇滚
- 快速启动一个新的存储库（没有configuration等）
- github很容易使用
（我还没有真正“需要”分布式的东西，除了能够拥有本地存储库并推向公共领域之外）。
缺点：
- Windows支持仍然滞后，我相信 – 你不能只从一个正常的命令提示符使用它
- 缺乏IDE和Explorer集成
- 我花了一段时间才find一本好的介绍性文章 ，这些文章都是基于“红豆”这本书的。
- 事实上，“添加”一个变化的文件只添加在这个时间点的内容（所以它可以显示为提交的阶段，仍然有需要另一个
git add修改）花了一段时间来掌握
命令数量
虽然svn和其他现代VCS（如hg或其他）是好的和有用的工具git是一个充满机床的商店。 这同时作为专家和审核员。 虽然svn有30个命令（根据'svn help'），但git发送了130个手册页，其中每个页面都或多或less描述了一个命令。 其中一个原因是，git暴露了大多数用户将需要的较低级别的函数作为命令行工具。 但即使没有这些低级命令，git也会提供许多非常强大的工具，而且在我所知的任何其他VCS中都没有find（请参阅git-bisect ， git-filter-branch ， git-cherry或git-reset ）。 虽然手头有这些工具是非常有帮助的，但是初学者很难理解他们需要什么命令，哪些需要知道，哪些不需要。
发展模式
一个类似的话题是，git足够强大，可以支持非常不同的操作模式。 这对初学者来说很困难，因为没有真正的“最佳实践”文档，因为最佳实践不是build立在git之上的。 所以你必须决定你自己
- 只要使用合并来避免与您工作的目录冲突
- 使用私人分行，重新分配到上游头
- 使用上游分支
- 定期合并（飞鱼）
- 合并完成后
- 使用一个项目维护者，树维护者，子系统维护者，驱动程序维护者和贡献者的树，每个级别从下面的级别（linux内核）
由于您拥有本地存储库，因此您甚至可以使用与您正在处理的项目完全不同的操作模式，并在推送/发布之前调整您的更改集。
变化的道路
另一个也被视为pro和con的东西取决于你的观点，使用git比使用任何集中式VCS和更复杂的大多数其他分布式VCS更复杂。
使用集中的VCS，通常只需执行提交，并将所做的更改传送到存储库。 在git中，更改可能会经过相当多的步骤，然后才会到达最终目的地。 典型的步骤是（在括号中不是很常见的步骤）：
- 工作目录（编辑）
- 索引又名暂存区（git add）
- 本地存储库（git commit）
- （其他本地分支）（git rebase，git cherry-pick，git merge）
- （子维护者的存储库）（git push，git pull，mail）
- 上游存储库（git push，git pull，mail）
正如你可以跳过索引至less有2个步骤，但通常还有更多。 这需要更深入的了解你在做什么，并input更多的命令。 另一方面，这可以让你控制每一个这些步骤。 您可以
- 决定哪些垃圾/行将进入提交，哪些不是
- 决定你在哪个地方的分支想要哪些补丁
- 决定你的哪个补丁发布
- 修复，压缩，修复，拆分，重新sorting您的修补程序，然后再发布它们
- 决定你自己信任哪些人并接受补丁
- 把项目的一部分委托给你信任的其他维护者。
所有这些权力和决定使初学者很难开始使用git。 一旦掌握，他们将对代码进行巨大的控制。
写访问
对于任何分布式VCS来说，一个主要的优点是贡献者不需要写入权限就可以从VCS中受益。 每个拥有读权限的人都可以克隆版本库，在必要时创build分支，并开始堆叠放置补丁集。 使用cvs而无需写入权限是一件非常痛苦的事情 – git的补丁程序并没有太大的区别。这不仅是技术上的优势，而且也节省了复杂的讨论，无论这个noobie是否真的能够写入。
优点：
- 快 – 非常快。
- 与SVN相比，创build新的回购非常容易
- 完整的回购只包含在一个.git文件夹中 – 它不会在代码的每个文件夹中添加一个.SVN文件夹（不是什么大问题，但我喜欢）
- 分支比较容易
- GitHub的！
缺点：
- 无法签出存储库的一部分（如只有一个文件夹或只有一个文件）
- 不跟踪空文件夹
- 坏的Windows支持（不打扰我很多 – 我使用Linux）
- 我仍然没有find一个好的Git GUI工具（我使用SVN的KDESVN）。 如果您习惯于使用CLI，那么不是一个大问题。
很多人会否认这一点，但是源代码pipe理工具的select会影响你的工作方式。 我曾经在Subversion上工作过很多，直到我发现了Git。 我大多避免在Subversion中分支。 每当我无法避免它，我更喜欢设置一个本地镜像（使用svk）。 尽pipe在Subversion和Git中分支都很容易，但是只有Git才能使合并（和重新分配！）变得有趣，Subversion在合并时一直是一个皇室的痛苦。
第二件事，我真正喜欢Git（除了已经提到的所有要点）之外，还有一个“索引”，一个保存下一个提交的暂存区域，以及仅仅添加更改文件的单个块的可能性。
Windows的支持是令人震惊的，所以我转移到另一个DVCS Mercurial ，这是很好的。
例如，当您在办公室的服务器上有一个存储库，并且您在现场工作时，DVCS的好处就会变得明显。 无需访问您的服务器办公室即可完成本地提交（必要时进行回滚）非常棒！
优点： 为什么Git比X好
使用git与使用其他版本系统的工作非常不同。
拥有本地存储库非常重要。 这意味着你可以使用版本控制系统的全部function（这对git有很大的帮助）而不会打扰任何人。 如果您的项目中存在争议性问题，您可以私下处理 – 通过创build分支，堆叠补丁和打磨它们。 这样，你可以回来一个被淘汰的补丁集。 但是即使在“正常运行”的情况下，如果您在向公众展示之前清理您的修补程序，效果会更好。事实上，如果您拥有理智的修补程序，而不仅仅是“结束date”快照，debugging将变得更加容易。
在我提交更多的补丁之前，我通常会将修补程序重新sorting，并将修补程序直接插入到我的新代码中。 所以补丁看起来像我从来没有犯任何错误。 之后，我的私人分支在HEAD之上重新装订，然后推出。 我通常从不使用合并，因为它只会混淆历史。
总之：它可以保持你的历史清洁。
这给你一个非常不同的看法你的工作。 它允许您将当前状态视为添加单个修补程序，以创build不仅仅是日志的历史logging，而且是您故意放置的logging。 修补程序集是您从应用程序构build应用程序的砖块，如有必要，请移至正确的位置。
我永远不会主动回到我在git之前使用的任何其他版本控制系统，或者任何不支持rebase和本地分支和提交的版本控制系统。
在git中合并更简单，因为创build分支是默认的，而不是一个额外的选项。 所以当你需要合并的时候，你只需要提交它，然后合并两个分支（现有的和最后一个签入时自动创build的新分支）。
而且，在使用git时，你总是拥有整个仓库。 您可以在离线状态下办理登机手续并稍后合并（因为合并要简单得多）。
缺点是GIT几乎不能在Windows上的USB驱动器上使用。 Windows禁用这些caching，GIT可与数百万个小文件一起工作。 另外，IDE支持仍然不足。 我不确定后者是否真的是一个问题。 GIT的用户界面非常好。
此外，我不是百分之百的高兴，你必须“添加”现有的文件[编辑]和大量的function。 对于初学者来说，他们是压倒性的，而且为什么要使用某个选项/命令通常是不清楚的。 我的意思是，CVS自带了20个命令。 GIT自带73，每个都有很多选项（这不包括pipe道命令…）。
其他考虑：
优点：
- 灵活：不强制执行一个真实的工作stream程
- 如此之快的版本控制成为一项小任务
- 轻量级的分支，简单的合并和分段区域允许个性化的工作stream程
- 更加强大
- 非常紧凑的回购
缺点：
- 没有内置的访问控制
- 二进制文件的弱工具。 不压缩对repo中的二进制文件所做的更改，并且存储二进制文件可防止在Windows中自动处理行结束符。
- 可能更难学，因为它更灵活，更强大。 并不总是遵循CVS / SVN语义，不是围绕文件组织的。
最新版本的Git可以直接在Window的命令提示符下工作，这就是我使用它的方式。 现在这个过程对我来说是相当微不足道的。
我也有Git安装在外部硬盘驱动器和我的jumpdrive。 每当在一台新电脑上，我都会运行一个脚本来临时设置包含Git工具的path。 那么你可以继续发展！
Skeet大部分都是，但是：
优点：
- 分枝！ 在独立的分支上处理大量的function是非常好的，并且仍然能够对它们进行版本控制，而不是在一个分支上进行多种事情。 一旦你决定了你喜欢分支，你必须爱上Git与SVN相比的轻松
很好的问题，我一直在使用SVN很长一段时间，感觉很舒服。 但是我不得不多次使用Git来从不同的开源项目中获取源代码。 但我还没有花时间去真正了解它。 这值得么？
我也会问，使用分布式版本控制作为颠覆的普通VCS有什么好处。
优点：
- 上面提到的一切
缺点：
-
Windows中autocrlf的奇怪行为
-
不可能移动/重命名文件或目录insode回购和kepp其提交历史logging（ git mv只是从回购文件中删除文件，重命名并再次将其添加到回购，从而失去了所有的历史）
