我被要求证明将小团队从CVS / SVN转移到git是合理的。
到目前为止，从我的阅读中，我可以确定三个主要好处：
有some arguments赞成git因为它的速度，然而，提及Git优越速度的常见回应是3到13秒之间的差异可以忽略不计。
一个现实生活中的例子：
我白天做了很多工作，晚上回家之前把稳定的东西送到了家里 在一个大提交中，我已经添加了几百个文件以及更改，移动和重新计算现有文件，CVS将执行提交，然后我可以穿上外套并整理我的桌面。 这与git有什么不同？
Git的分支被很多人称赞为其中一项强项功能。然而，CVS / SVN中的分支对于许多工程师来说似乎已经足够了，特别是对于现代IDE来说，无论实际使用哪种RCS，整个体验和工作流程都几乎相同。
当我想尝试一个想法时，我右键单击Eclipse中的项目节点，选择“切换到不同的分支”，选择“新建”，输入名称，我就离开，提交和更新，而不是“污染”主线'如CVS明显的那样。 当我确定此分支中的新想法稳定且良好时，我再次右键单击该项目，选择“与另一个分支或版本合并”，选择HEAD，我们又回到了HEAD，但实施了工作变更......如何git会改善我的经历吗？
使用分布式RCS的主要优势似乎是灾难恢复。然而，类似的属性也是CVS和SVN中固有的。对于标准实践用法尤其如此：
现在我认为标准做法是早上做的第一件事就是检查存储库是否有任何变化，如果需要的话做更新/合并，如果我今晚回家并找到我的存储库已经早上被烧到地上，我会失去......好吧......什么都没有。我会创建一个新的repo，将我的本地文件提交给服务器，其他5个员工会做同样的事情，可能会有一些合并大惊小怪但不会超过我们已经将我们的本地更改提交到已经存在的服务器，我们再次离开。没什么大不了的。
GIT暂存
经常提到的另一个特征是临时区域。这在SVN / CVS中没有等价物，允许开发人员“制定他的提交”以包含在您想要的文件中。
通常，当提到这一点时，我只想到变更集。 暂存区域有何不同？
实际上，我甚至看到使用Git的缺点：
我觉得我必须错过或误解git的基本内容，并且很难证明交换机的商业案例。我非常感谢您的投入，以便更好地理解所涉及的问题，特别是如果您能够确定具体的用例，其中git将是一个比CVS / SVN更优越的解决方案，而不仅仅是逐步更好的解决方案？
答案 0 :(得分：5)
直接达到你的高水平积分：
要了解真正的优势，Git可以让您停止摆弄来回纠缠代码的机制，并专注于您想要的代码。这可以通过开发稳定的内核版本和各种长期存在的功能分支来实现。开发人员的辛勤工作是决定要合并的代码。做出决定后，这样做的机械过程由计算机处理。
在具有多个分支的CVS上存在问题的最简单的事情之一是在Git中微不足道的是修复错误或在多个分支中传播一些其他更改。假设您在主线或一个客户分支中进行了更改。经过一些QA和现场测试后，您决定其他3个客户分支也应该得到修复。在CVS中，这是一个像
这样的过程cvs log固定分支以识别修复错误的修订版A-B cvs diff -rA:B > bugfix.patch保存更改以便您可以重新应用cvs update到另一个分支patch -p1 -i bugfix.patch申请更改cvs commit记录更改。步骤4和5相当容易出错，尤其是在存在合并冲突的情况下。除非你非常自律，否则将不会记录错误修复首先发生的位置，或者任何易于将其与其他分支相关联的记录。请注意，第1步，第2步，第3步和第5步都涉及与服务器通信，对于曾经使用过Git的人来说，这似乎很慢。
相比之下，与Git：
git log固定分支以识别修复错误的修订版git checkout要修复的分支git cherry-pick C以应用此修复程序。git push cherry-pick步骤将记录提交消息中提供错误修正的内容，以便以后查找。如果存在合并冲突，则必须在第一时间解决它们，但Git的'rerere'（REpeat REmembered REsolution）会在此之后为您自动化它，如果它是相同的冲突，可以避免错误的机会。只有这个过程中的第5步涉及与服务器通信，而且速度非常快，因为Git确切地知道它需要通过网络发送的最小数据。
对于新功能开发，Git提供更强大的功能。你可以在一个分支上完成你的工作，而不用冒着让正在进行的工作搞乱其他人的风险，然后当它完成时，将该分支合并到你想要的任何地方。这是Git的真正力量，那些只使用过CVS或SVN的人并不欣赏。 git merge实际上有效，而且效果非常好。如果您希望在多个分支上使用该功能，则可以将其合并到每个分支，历史记录将准确反映它们都来自该功能分支。
答案 1 :(得分：2)
如果你已经使用git足够长的时间，你会开始意识到它实际上更方便。我没有任何关于CVS的经历，但我有SVN（其座右铭是“CVS做对了”）。
首先，Git的分布式性质确实是一种祝福。如果没有将你的工作推到另一个存储库（例如GitHub），你就不会工作一周，所以如果你的计算机出现问题，你就不会失去工作。
你所说的“如果我的回购去世，我会创造另一个”有一个问题。你失去了所有的历史！这意味着您之前的所有提交，发布等都已消失。它并不像你想象的那么舒服。
此外，您每天都会提交一次，而我们中的许多人每天都会执行多次提交。实际上，许多较小的提交更易于管理，并且在出错时更容易还原。使用Git，每次提交都很快。使用Svn，所有这些都通过网络和ssh，这需要更多的时间。
集中存储库还有其他一些不太方便的东西。例如，如果你有一个版本化+无版本的东西的目录，在Git中重命名是很简单的。使用svn重命名它需要您编写存储库的整个地址（两次）以避免错误地对未版本控制的文件进行版本控制。并且总是提交一个提交。如果要重新组织几个目录，则会有无用的提交。
在SVN中，如果您添加一些文件并提交，然后执行svn ls，则您看不到新文件会解开svn update。但是在Git中，既然您拥有了存储库，那么就没有必要这样做了。
最后，所有这些都有效，所以你无法找到任何重大缺陷，所以你可以转移到另一个。然而，这是一个方便的问题（至少对我而言）。如果你为windows编程，当然你可以做任何事情，但是一旦你在Linux中做同样的事情，你会感觉好多了，因为很多东西更有意义。就像我说的，它们都有效，但有些设计更好。我相信Git与CVS或SVN就属于这种情况。
我的建议是，试试Git吧。使用它一段时间。尝试它的不同功能，几个月后你会得出结论，无论你更喜欢Git还是CVS。