0

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

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

  • 速度
  • 轻松分支
  • 分散式
  • SVN 不提供的更多功能（部分文件提交、暂存等...）

速度

由于它的速度，有一些支持 git 的论据，但是，对于提到 Git 的卓越速度的常见回应是 3 秒和 13 秒之间的差异可以忽略不计。

一个真实的例子：

我白天做大量工作，晚上回家前完成稳定的工作。
在一个大型提交中，我添加了数百个文件以及更改、移动和重构现有文件，CVS 将在我穿上外套并整理我的办公桌之前执行提交。这与 git 有何不同？

轻松分支

Git 的分支被许多人称赞为它的强项之一。然而，对于许多工程师来说，CVS/SVN 中的分支似乎就足够了，尤其是使用现代 IDE，无论实际使用哪种 RCS，它都能使整个体验和工作流程几乎相同。

当我想尝试一个想法时，我在 Eclipse 中右键单击我的项目节点，选择“切换到不同的分支”，选择“新建”，输入名称然后我就走了，提交和更新而不会“污染主线”为CVS 显然可以。当我确定这个分支中的新想法稳定且良好时，我再次右键单击该项目，选择“与另一个分支或版本合并”，选择 HEAD，我们又回到了 HEAD，但已经实现了工作更改......如何git会改善我的体验吗？

真正分布式

使用分布式 RCS 的主要优势似乎是灾难恢复。然而，类似的属性在 CVS 和 SVN 中也是固有的。对于标准实践用法尤其如此：

现在我认为这是标准做法，早上要做的第一件事是检查存储库是否有过夜所做的任何更改，并在需要时进行更新/合并，如果我今晚回家发现我的存储库已被烧毁到早上起来，我会迷路的……嗯……什么都没有。我会创建一个新的存储库，将我的本地文件提交到服务器，其他 5 名员工也会这样做，可能会有一些合并大惊小怪，但不会超过我们提交本地更改的情况一个已经存在的服务器，我们又离开了。没什么大不了。

GIT 分期

另一个经常提到的功能是暂存区。这在 SVN/CVS 中没有等价物，并且允许开发人员“制作他的提交”以包含在您想要的文件中。 

通常，当提到这一点时，我只会想到变更集。暂存区有何不同？

事实上，我什至看到了使用 Git 的一些缺点：

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

我觉得好像我一定遗漏或误解了 git 的一些基本知识，并且很难证明切换的商业案例的合理性。我非常感谢您的意见，以更好地理解所涉及的问题，特别是如果您能确定具体的用例，在这些用例中 git 将是一个比 CVS/SVN 从根本上优越的解决方案，而不是简单的渐进式更好的解决方案？

4

2 回答 2

5

正面击中你的高水平点：

  1. 速度是锦上添花
  2. 当人们说“容易分支”时，他们实际上的意思是“容易合并”。CVS 并没有真正进行合并，Subversion 开发人员已经承认它的合并方法很糟糕，并且一直保持这种状态。
  3. 暂存、部分文件提交等。这些是 Git 支持合并的结果偶尔带来的便利。同样，我认为这本身不是“核心”优势。

要了解真正的优势，Git 让您停止摆弄来回纠缠代码的机制，而专注于您想要的代码在哪里。稳定内核版本的开发和各种长期存在的功能分支就是例证。开发人员的艰苦工作是决定要合并哪些代码。一旦做出决定，这样做的机械过程将由计算机处理。

在具有多个分支的 CVS 上存在问题并且在 Git 中微不足道的最简单的事情之一是修复错误或跨多个分支传播一些其他更改。假设您对主线或一个客户分支进行了更改。在一些 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 步骤将在提交消息中记录错误修复来自哪个提交，以便以后轻松查找。如果存在合并冲突，您必须第一次解决它们，但如果是相同的冲突，Git 的 'rerere' (REpeat REmembered REsolution) 会在之后自动为您解决，从而避免出错的机会。此过程中只有第 5 步涉及与服务器通信，而且速度非常快，因为 Git 确切地知道它需要通过网络发送的最少数据。

For new feature development, Git offers even more power. You can do your work on a branch, without risking messing other people up with your work in progress, and then when it's done, merge that branch to wherever you want. This is the real power of Git, that people who've only used CVS or SVN don't appreciate. git merge actually works, and works extraordinarily well. If you want that feature on several branches, you can merge it to each of them, and history will accurately reflect that they all descend from that one feature branch.

于 2012-04-19T14:36:54.713 回答
2

如果您使用 git 的时间足够长，您就会开始意识到它实际上更方便。我没有使用 CVS 的任何经验，但我使用过 SVN（其座右铭是“CVS 做得对”）。

首先，Git 的分布式特性确实是一件幸事。如果不将您的工作推送到另一个存储库（例如 GitHub），您将无法工作一周，因此如果您的计算机发生故障，您并不会真正丢失您的工作。

你所说的“如果我的回购死了，我会创建另一个”有一个问题。你失去了所有的历史！这意味着你之前的所有提交、发布等都消失了。它不像你想象的那么舒服。

此外，您每天提交一次，而我们中的许多人每天执行许多提交。事实上，许多较小的提交更易于管理，并且在出现错误时更容易恢复。使用 Git，每次提交都很快。使用 Svn，所有这些都通过网络和 ssh，这需要更多时间。

集中式存储库还有其他一些不太方便的东西。例如，如果您有一个包含版本化+未版本化内容的目录，那么在 Git 中重命名它很简单。使用 svn 重命名它需要您编写存储库的整个地址（两次）以避免错误地对未版本化的文件进行版本控制。这总是伴随着提交。如果您正在重新组织几个目录，那么您将有尽可能多的无用提交。

在 SVN 中，如果您添加几个文件并提交，然后执行svn ls，除非您svn update. 但是在 Git 中，由于您拥有存储库，因此不需要这些东西。

最后，它们都起作用了，所以你找不到任何一个重大缺陷，所以你可以转移到另一个。然而，这是一个方便的问题（至少对我来说）。如果你为 Windows 编程，当然你可以做任何事情，但是一旦你在 Linux 中做同样的事情，你会感觉好多了，因为很多事情都变得更有意义了。就像我说的，它们都可以工作，但有些设计更好。我相信 Git vs CVS 或 SVN 就是这种情况。

我的建议是，试试 Git。使用它一段时间。尝试它的不同功能，几个月后你会得出结论，你更喜欢 Git 还是 CVS。

于 2012-04-19T14:00:12.910 回答