mkasberg
mkasberg

Reputation: 17272

How does merging conflicts in Git compare to merging conflicts in Subversion?

When I work in Subversion, I always do an svn update before an svn commit. If there are any conflicts, I am warned when I do the update. Then, in my working directory, I get filename.java, filename.java.mine, filename.java.r10, and filename.java.r13. Based on those files, I figure out how to resolve the conflict, mark it as resolved, and commit.

I'm relatively new to Git, so I'm trying to figure out what the equivalent of the above workflow is for git. What git commands will possibly result in merge conflicts? Are there equivalents of the above files that will show up in my working directory?

Upvotes: 3

Views: 344

Answers (1)

twalberg
twalberg

Reputation: 62369

There are a number of git sub-commands that can result in merge conflicts, including merge (and pull since it's essentially fetch followed by merge), cherry-pick, rebase and others. git deals with merge conflicts in a fundamentally different way, though. Rather than creating individual files for the different versions, it creates a single file that has sections marked with delimiters to indicate which part of the three-way merge equation they came from. So you edit a conflicted file and either remove the sections you don't want, and the delimiters, or if neither side is exactly right, replace it with an appropriate manually-merged hybrid, then git add and git commit. The delimiters are a sequence of 7 <, =, and > (and sometimes |, if you have the diff3 format configured) characters that look something like this:

<<<<<<<
stuff from your version of the file
|||||||
stuff from the common ancestor of the two
=======
stuff from the version you're merging in
>>>>>>>

If you're not using diff3-styled conflict markers, the | delimiters and the common ancestor lines are missing.

You can type git help merge to read more about it.

Upvotes: 2

Related Questions