如何将您的工作方式从 CVS 迁移到 Git？

问题描述

我们正在将旧的 CVS 服务器迁移到 git，但我收到了过去 30 年来一直在使用 CVS 的一位主要开发人员的反对。我认为他在掌握 git 方面遇到了一些困难。他给了我他的意见，我想知道如何挑战或解决其中的一些问题：

1. "无法将提交合并到不同的分支，因为 我认为小项目正在奏效，但对于我们的项目，我们仍然 需要创建单独的分支来移动特定的修复程序。” 上下文：目前，每次我们创建一个版本（每个季度）时，他都会创建一个特殊的发布分支。一些客户升级到新版本，但其中很多仍然在旧版本上收到频繁的修复。当他在一个较旧的分支中实施修复并希望将此修复包含到其他发布分支时，他会遇到很多合并冲突。我认为主要问题源于您不能只是合并这一事实有着截然不同历史的分支。

2. "创建新分支并从特定分支移动修复，而不是 工作，在 CVS 中你可以只标记某些提交，然后移动它们 到你想要的那个，该选项不会在 Git 中退出”上下文：与第一个相同的问题。

3. “没有像 CVS 那样每个文件的历史树（我们通常检查所有 每个分支的某些文件的更改）或者如果我们想查看列表 在所有文件中并在每个更新日期对其进行排序，该选项不会 在 Git 中退出”上下文：他显然希望看到 git 中特定文件在不同分支中的演变，而不仅仅是在当前活动分支中。

4. “一般来说，提交文件需要相当多的时间，与 CVS 相比，我们甚至在 Git 中花费更多时间来提交文件。”背景：我认为这主要是因为他的合并有很多冲突。

解决方法

我发现说服某人新系统是好的最好方法是善于使用它，然后向他们展示你可以用它做什么。

我很少将争论视为说服某人采用新技术（语言、操作系统、源代码控制系统等）的成功方法

“告诉我如何让这个新系统像我的旧系统一样运行”这个问题只是意味着他们想保留旧系统。

问题“我如何说服我的同事 git 是好的？”远远超出了堆栈交换帖子中可以回答的内容，但我重申，“展示优势”。

话虽如此，这里有一些想法可能有助于解决您提出的具体问题。

1. 对旧分支的新修复。您可能会发现可以使用cherry-pick 将新修复应用到旧分支，而无需将新分支中的所有更改合并到旧分支中。 当然，请记住，新修复可能取决于新分支中的其他更改，但无论您使用何种源代码管理系统，这都适用。

2. 看起来很像 (1.)。参见 (1) 的答案。

3. 文件的历史记录。 以下行将显示文件的提交历史。

git log -- 文件路径

如果文件在此过程中已被重命名，--follow 选项仍将对其进行跟踪。

git log --follow -- 文件路径（注意：--follow 没有空格。next -- 周围有空格）

如果您想查看每次提交所做更改的差异，请添加 -p 选项

git log --follow -p -- 文件路径

请注意，文件路径是从 git 存储库顶部到文件的路径，还应包含文件名。

真正的概括是：人们不喜欢他们不知道如何使用的东西。 如果你和你的同事都学习了 git 提供的所有东西，你可能会成为忠实的粉丝。

,

1 - 每个修复/票证（我假设它在一个功能分支上）可以通过只重新定位与修复相关的修订来反向移植（这并不意味着你不会遇到冲突......冲突会出现，当然，如果 git 不能正确地变基，正如预期的那样）。

2 - 它与#1 不同吗？听起来不像。

3 - 这是什么意思？您可以执行 git log --all some-random-file 并获得其历史记录。您甚至可以添加 --graph 并且 git 甚至会尝试从不同的分支创建一棵树（至少 gitk 可以，所以我认为 git 也可以）。

4 - 我敢打赌 git 在本地提交比在中央服务器上提交 cvs 花费的时间少得多。 cvs 允许你在有冲突时提交东西吗？

总的来说，我会说：git 有非常不同的工作流程，需要时间来适应它，但我很难找到一个在使用 DVCS 后决定回到集中式的人。

欢迎来到 SO。