git 合并冲突_GIT：合并冲突

git 合并冲突

The merge that we saw in the last chapter was relatively easy for Git to solve. But in reality, not all conflicts are going to be easy. Earlier we made changes to different lines in the same file in both our branches. Can you guess what will make up a hard conflict then?

在上一章中看到的合并对于Git来说相对容易解决。 但实际上，并非所有冲突都会变得容易。 之前，我们对两个分支的同一文件中的不同行进行了更改。 您能猜出什么将构成一场艰难的冲突吗？

Absolutely right! Changes made in the same line, or rather same areas of the file will result in a hard conflict. Git cannot determine which version you want to keep in the final project. In a simple conflict, Git conveniently merged both versions to the file.

绝对正确！ 在同一行或文件的相同区域中进行的更改将导致硬冲突。 Git无法确定您要在最终项目中保留哪个版本。 在一个简单的冲突中，Git方便地将两个版本合并到文件中。

Let's go on and set up a hard conflict for Git. Check out which branch you are in just to be sure. Let's say you are on the signin_feature branch. Open up any one of your files and make some changes. Remember to commit this change.

让我们继续，为Git设置一场艰难的冲突。 请确定您在哪个分支中。 假设您在signin_feature分支上。 打开您的任何文件并进行一些更改。 记住要进行此更改。

Then, checkout the master branch and make the changes to the SAME file, but in a different way.

然后，检出master分支并以另一种方式对SAME文件进行更改。

Now that you are on master, commit this change and try merging the two branches. Just like in the last chapter, we see Git has detected a merge conflict and has tried automerging it, but it has failed. Uh-Oh.

现在您已经掌握了，请提交此更改并尝试合并两个分支。 就像上一章一样，我们看到Git检测到合并冲突并尝试自动合并，但是失败了。 哦，哦。

Git has detected changes to the same line and doesn't understand which file you would like to keep in the final project. Whenever Git comes across such a conflict, it leaves it up to the user (you!) to resolve that conflict manually. Open up the conflicted file and hmm? There seem to be some weird punctuation marks inside the file. We didn't write these, then who did?

Git已检测到同一行的更改，并且不知道您要保留在最终项目中的文件。 只要Git遇到这样的冲突，它将由用户(您！)自行解决。 打开冲突的文件，嗯？ 文件中似乎有一些奇怪的标点符号。 我们没有写这些，那是谁写的？

That's right, Git marks the area where the conflict occurred. Pretty smart and helpful, eh? They are called conflict markers. The angled brackets indicate that the whole area is conflicted. The row of equal signs is the separator between the two versions. The top version is labelled head which is a special term for the latest commit. The bottom version is labelled signin_feature, no prizes to guess what it means.

没错，Git标记发生冲突的区域。 很聪明，乐于助人，是吗？ 它们被称为冲突标记。 尖括号表示整个区域冲突。 等号行是两个版本之间的分隔符。 最高版本标记为head ，这是最新提交的特殊术语。 最底层的版本标记为signin_feature ，没有奖品来猜测它的含义。

Git has given us full power to edit and keep whichever version we want in the final project. Now that we have resolved the conflict, we need to tell Git that its done. Resolve all other conflicts (if any). Let's add our change to the staging area and run $ git commit.

Git赋予了我们编辑和保留最终项目中所需版本的全部能力。 现在我们已经解决了冲突，我们需要告诉Git它已完成。 解决所有其他冲突(如果有)。 让我们将更改添加到登台区域并运行$ git commit 。

Notice that Git knows we are resolving a conflict and has already prepared a commit message for us. There, the conflict has been resolved and the two branches merged successfully. Keep in mind that in such cases, Git relinquishes all control over resolution of merges and it completely depends upon you to solve it.

请注意，Git知道我们正在解决冲突，并且已经为我们准备了提交消息。 在那里，冲突已解决，两个分支成功合并。 请记住，在这种情况下，Git放弃了对合并分辨率的所有控制，这完全取决于您来解决它。

Handling merges manually might seem a bit difficult and complicated, but then it ensures you have the right version in your final project. So that was all about merging.

手动处理合并似乎有些困难和复杂，但是可以确保最终项目中使用正确的版本。 因此，这就是合并。

VCS such as Git are useful when you work on a personal project, but they show their true power when you collaborate with others. When you collaborate , you need to store your repositories remotely. Let's learn more about interacting with remote repositories next!

当您处理个人项目时，Git之类的VCS很有用，但是当您与他人合作时，它们会发挥出真正的作用。 进行协作时，您需要远程存储存储库。 接下来，让我们了解更多有关与远程存储库进行交互的信息！

翻译自: https://www.studytonight.com/github/conflict-in-git

git 合并冲突