CVS到Git迁移的具体商业案例是什么？

Question

我被要求证明将小团队从CVS/SVN移到git是合理的.

到目前为止,从我的阅读中,我可以确定三个主要好处:

• 速度
• 易分支
• 分散式
• SVN不提供的更多功能(部分文件提交,登台等...)

速度

有一些支持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的一些缺点:

• 本地提交意味着丢失代码的可能性更大,因为我的开发机器比我们的SVN服务器更容易受到攻击,并且在将其推送到我们的公共存储库之前,我的工作处于危险之中.
• 离线工作没有明显的优势,因为大多数开发人员在离线时永远不会在项目上工作.

我觉得好像我必须遗漏或误解git的基本内容,并且很难证明交换机的商业案例.我非常感谢您的投入,以便更好地理解所涉及的问题,特别是如果您能够确定具体的用例,其中git将是一个比CVS/SVN更优越的解决方案,而不仅仅是逐步更好的解决方案？

Answer 1

要正面达到你的高水平积分:

1. 速度是锦上添花
2. 当人们说"轻松分支"时,他们实际上意味着"轻松融合".CVS并没有真正合并,而且Subversion的开发人员已经承认它的合并方法是垃圾,并且它保持这种方式.
3. 暂存,部分文件提交等.这些偶尔的便利是Git支持合并的结果.再次,不是我认为本身就是"核心"优势.

要了解真正的优势,Git可以让你停止摆弄来回纠缠代码的机制,并专注于你想要的代码.这可以通过开发稳定的内核版本和各种长期存在的功能分支来实现.开发人员的辛勤工作是决定要合并的代码.一旦做出决定,这样做的机械过程由计算机处理.

对于具有多个分支并且在Git中微不足道的CVS来说,最简单的问题之一是修复错误或在多个分支中传播一些其他更改.假设您在主线或一个客户分支中进行了更改.经过一些QA和现场测试后,您决定其他3个客户分支也应该得到修复.在CVS中,这是一个类似的过程

1. cvs log 固定分支以识别修复错误的修订版AB
2. cvs diff -rA:B > bugfix.patch 保存更改,以便您可以重新应用它们
3. cvs update 到另一个分支
4. patch -p1 -i bugfix.patch 应用更改
5. cvs commit 记录变化.
6. 对每个要修复的分支重复步骤3-5.

步骤4和5非常容易出错,尤其是在存在合并冲突的情况下.除非你非常自律,否则将不会记录错误修复首先发生的位置,或者任何易于将其与其他分支相关联的记录.请注意,第1步,第2步,第3步和第5步都涉及与服务器通信,对于曾经使用Git的人来说,这似乎很慢.

相比之下,与Git:

1. git log 固定分支以识别修复错误的修订版C.
2. git checkout 要修理的分支
3. git cherry-pick C 应用修复程序.
4. 对要修复的每个分支重复步骤2和3.
5. git push

cherry-pick步骤将记录提交消息中提供bugfix的内容,以便以后查找.如果存在合并冲突,则必须在第一时间解决它们,但Git的'rerere'(REpeat REmembered REsolution)会在此之后为您自动化它,如果它是相同的冲突,可以避免错误的机会.这个过程中只有第5步涉及与服务器通信,而且速度非常快,因为Git确切地知道它需要通过线路发送的最小数据.

对于新功能开发,Git提供更强大的功能.你可以在一个分支上完成你的工作,而不用担心让其他人搞乱你正在进行的工作,然后当它完成时,将该分支合并到你想要的任何地方.这是Git的真正力量,那些只使用过CVS或SVN的人并不欣赏.git merge实际上是有效的,而且效果非常好.如果您希望在多个分支上使用该功能,则可以将其合并到每个分支,历史记录将准确反映它们都来自该功能分支.