1

我正在尝试评估从 svn 迁移到 git 是否是一个可行的选择。我听说 git 中的合并比 svn 中的合并效果好得多，但在我的测试中我还没有看到。

这是我所做的：

  • 创建了一个名为 main.c 的文件

    #include <stdio.h>    

function main() {
  int myNum = 10;

  printf("Hi, my num is %d\n", myNum);

  return 0;
}

  • git init, git add ., git commit -m "Created main.c", 并推送到origin master

  • 在 main.c 文件中，我故意不遵守编码标准并且错误地命名了函数。

  • 另一个用户出现并更改代码以符合编码标准（花括号移到下一行），提交并推送

    #include <stdio.h>    

function main()
{ //This was changed to a specific coding standard
  int myNum = 10;

  printf("Hi, my num is %d\n", myNum);

  return 0;
}

  • 我在 main 之前添加了一个函数，提交并尝试推送，它告诉我我的 master 分支不是最新的，所以我做了一个 git pull origin master 来更新它，然后我得到了冲突

    <<<<<<< HEAD
function main() {
  int myNum = 10;
=======
function main()
{
  int myNum = 10;
>>>>>>> f0aceffb16f0a24638493367f4be6f2a09e22a82

问题：谁能告诉我我是否做错了？我是否遗漏了某些步骤，从而导致自己悲伤？也许我真的不明白合并应该比svn简单吗？

感谢您抽出宝贵时间，
克里斯

4

2 回答 2

1

当您对同一行进行两次更改时，Git 无法猜测您想要什么。没有单片机可以做到这一点。人类必须告诉它哪个版本应该“获胜”。

在某些极端情况下，git 的合并比 subversion 更干净。我面前没有它们，但坦率地说，在现代颠覆中，合并不太可能有实质性差异。

您对是否使用 git 的决定不会归结为某种合并黑魔法。这将归结为 git 的整体运作方式。

对我来说，git 与其他 SCM 的区别在于它是如何工作的。因为它使用了一个附加模型（新提交是对图表的添加）并且每个提交都经过哈希处理，所以使用 git 很难丢失任何东西。那个复杂的合并很糟糕，导致一团糟，你不知道你会如何倒带？只是git reset --hard在合并之前提交。将您的分支重置回 11 次提交，然后决定它应该是 10 次提交？没问题，只需将分支移回第 10 次提交即可。决定你的最新特性分支应该基于开发而不是主分支？只需几个命令也可以进行更改。

Git 的不可变特性和内容的散列给了我一些我在 SVN 中从未有过的东西。信心。相信如果我把事情搞砸了，我可以想办法回到原来的位置。有信心在与他人分享之前检查我的更改并确保它们是正确的。我没有那种“哦不……我刚刚对每个人做了什么？”的恐慌。

此外，虽然这不是我经常使用的东西，但直接从另一个开发人员那里提取更改，甚至应用通过电子邮件发送给我的补丁文件的能力是很好的灵活性。

于 2012-06-25T21:57:41.283 回答
1

你们都更改了关闭的行，Git 在合并这样的关闭区域时很谨慎。但是，如果在完全不同的区域中进行了更改，则合并将正常完成。

像 kdiff3 这样的一些合并工具会自动解决这个合并问题，而且大部分时间都是正确的，但我相信 Git 不希望自动解决有风险的合并问题。

于 2012-06-25T22:04:37.823 回答