评估git和合并似乎没有按照我预期的方式

我试图评估如果从svn移动到git将是一个可行的选择。我听说git中的合并比svn中的合并好得多，但在测试中我没有看到。评估git和合并似乎没有按照我预期的方式

这里是我做了什么：

创建一个名为main.c中

#include <stdio.h>  

function main() { 
    int myNum = 10; 

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

    return 0; 
}

git的初始化，git的添加，git的承诺-m “的main.c”。，并推到原点主
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; 
}

我以前主要添加函数，提交和努力推动，它告诉我，我的主分支是不是最新的，所以我做的git拉出身主人把它最新的，然后我得到的冲突
```
<<<<<<< HEAD 
function main() { 
    int myNum = 10; 
======= 
function main() 
{ 
    int myNum = 10; 
>>>>>>> f0aceffb16f0a24638493367f4be6f2a09e22a82 
```

问题：有人可以告诉我，如果我做错了吗？是否有某些步骤让我离开，从而导致自己的悲伤？也许我真的不明白合并应该比svn简单吗？

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

来源

2012-06-25 Christopher Nguyen

Just因为合并更简单并不意味着你永远不会有冲突。冲突是不可避免的。 –

你有没有在推动过后更改了'function main（）{'这一行？ – CharlesB

@JBNizet非常真实。我期待冲突，但这似乎很容易不会自动合并？ –

的Git无法猜测你想要什么，当你做出如下修改到同一线（S）。没有SCM可以做到这一点。一个人必须告诉它什么版本应该“赢”。

有一些角落情况下，git的合并不是颠覆更干净。我面前没有他们，但坦率地说，在现代颠覆的情况下，合并不会有实质性的差异。

您对是否要使用git不会回落到一些合并黑魔法的决定。这将归结为git如何运作整体。

对于我来说，有什么其他SCM的分离Git是如何工作的。因为它使用了一个加法模型（新的提交是图形的增加）并且每个提交都是散列的，所以使用git很难失去任何东西。这种复杂的合并变得糟糕，并导致一个邪恶的混乱，你不知道你将如何倒回？在合并之前提交git reset --hard。将你的分支重置为11次提交，稍后再决定应该提交10次提交？没问题，只需将分支移回第10个提交。决定你的最新功能分支应该是基于开发而不是主人？只需几条命令即可进行更改。

Git的不可改变的性质和内容的散列给我的东西我从来没有与SVN。置信度。自信如果我把事情搞砸了，我可以想出办法回到我所在的位置。充满信心，我可以检查我的变化，并确保他们在与他人分享之前是正确的。我不会感到恐慌：“哦，不......我刚刚对每个人做了什么？“

此外，虽然它不是我经常使用，能够直接拉动从其他开发商的变化，甚至申请通过电子邮件发送补丁文件对我来说是很好的灵活性。

来源

2012-06-25 21:57:41 wadesworld

感谢您的信息。合并不会成为决定的最终结果;只是当我正在做一些研究为什么选择git over svn的时候我很好奇。我很欣赏诚实地告诉我，合并时不一定会有任何实质性差异。 –

你既改变了接近行， Git在合并这样的接近区域时比较谨慎，但是如果在完全不同的区域进行了更改，那么合并将会很顺利。

某些合并工具（如kdiff3）会自动解决此合并问题，并且大部分时间，但我相信Git不希望冒险合并自动解决。

来源

2012-06-25 22:04:37 CharlesB

评估git和合并似乎没有按照我预期的方式

回答

相关问题