Merging Branches With a Conflict: Conflicts And Resolutions

Commands discussed in this section:

  • git merge
  • git diff
  • git status
  • git show
  • git ls-files

Merging Branches With a Conflict

What could be more fun than creating a conflict! Our conflict with consist of the same file in two branches, but with conflicting changes in the same location of the file.

We’ll explore what approaches there are to resolve the conflict, and then we’ll resolve the conflict. (Sounds almost as dramatic as a made-for-TV movie.)

For this example, let’s back up in time a bit, before the “git merge test” command we did in the Merging Branches: Without a Conflict page.

We’ll start with the state of the repository like this:

An excerpt from gitg –all gives us this nice diagram:

Then while on the master branch, let’s say we:

  • Inserted a line into the README file between the first and second lines:Â Â Â Â This line was inserted from the ‘master’ branch.
  • Then we committed the change to the master branch

The session is shown below:

$ cat READMEThis is the README file. This line was inserted from the 'master' branch.One more line.$ git add README$ git commit -m 'README changed in the master branch'[master 3330113] README changed in the master branch 1 files changed, 1 insertions(+), 0 deletions(-)

The commit history now looks like this:

The Plot Thickens: The Conflicted Line

Then we switched to the test branch and inserted a different and conflicting line in the test branch’s version of the README file (the scarey music starts in the background as the plot thickens…):

  • Inserted the following line into the README file between the first and second lines:Â Â Â The ‘test’ branch version is here.
  • And we commited the change to the test branch.

The session is shown below:

$ git checkout testSwitched to branch 'test'$ [some-unnamed-editor] README$ cat READMEThis is the README file. The 'test' branch version is here.One more line.$ git commit -a -m 'README changed in the test branch'[test c406564] README changed in the test branch 1 files changed, 1 insertions(+), 0 deletions(-)

Can’t you really feel the conflict now?! (We’d have some conflicts with you, the git reader, if we named the editor we used above. However, there are no tools for resolving which editor is best. We know which is best except for the fact we gitguys don’t agree…)

gitg –all shows us the current commit history:

The two branches are clearly diverging.

Git Agrees There Is A Conflict

We’ll switch back to the master branch and then start to merge the test branch onto the master branch:

$ git checkout masterSwitched to branch 'master'$ git merge testAuto-merging READMECONFLICT (content): Merge conflict in READMEAutomatic merge failed; fix conflicts and then commit the result.

The git merge test command resulted in the conflict we created:
“CONFLICT (content): Merge conflict in README “.

Show Merge Status: git status

Let’s dig into ways to resolve the conflict and end all the drama. git status always helps and tells us where are:

$ git status# On branch master# Changes to be committed:## new file: plan## Unmerged paths:# (use "git add/rm ..." as appropriate to mark resolution)## both modified: README#

The Changes to be committed section shows us that the new file plan is ready to be committed and had no conflicts.

The Unmerged paths section shows us that both branches modified the README file, so we’ll need to do something to resolve the conflict.

Just Try To Ignore Git’s Warning

If we try to ignore git’s warning about the conflict and try to git commit, we get this:

$ git commitU READMEfatal: 'commit' is not possible because you have unmerged files.Please, fix them up in the work tree, and then use 'git add/rm ' asappropriate to mark resolution and make a commit, or use 'git commit -a'.

Git reflects life: Trying to ignore conflicts doesn’t work in git either.

Let’s Investigate

Clearly, git cannot live with conflict and is forcing us to resolve it.

Let’s look at the contents of the README file:

$ cat READMEThis is the README file.<<<<<<< HEAD This line was added from the 'master' branch.======= The 'test' branch version is here.>>>>>>> testOne more line.

Git inserted:

<<<<<<< HEAD

to mark the beginning of the conflicting section from the master branch (where the HEAD reference is pointing).

Git also inserted:

=======

to mark the ending of the conflicting section from the master branch, and inserted:

>>>>>>> test

to mark the end of the conflicting section from the test branch.

Telling Git The Conflict Is Resolved

You inform git that a conflict is resolved by adding the conflicting file to the index.

So at this point, we could resolve the whole thing by using an editor, changing the file, adding the file to the index and committing it:

$ [some-unnamed-editor] READMEChoose what we want to have in the conflicting section and save our updated version.$ git commit -a -m'README conflict resolved'

But there are too many fun git commands to play with first.

git diff

git diff gives a quick way of showing the differences between the two conflicting versions:

$ git diffdiff --cc READMEindex 56df44d,9585db7..0000000--- a/README+++ b/README@@@ -1,3 -1,3 +1,7 @@@ This is the README file.++<<<<<<< HEAD + This line was added from the 'master' branch.++=======+ The 'test' branch version is here.++>>>>>>> test One more line.

The output above looks a bit odd at first, but is displaying the differences in the conflicts. It is sometimes easier to see differences when Merging With a GUI.

The first 2 columns are used to report whether or not the line is in either of the two versions of the README file:

  • The first column is for the current branch (the master branch in this case).
  • The second column is for the test branch.

The column can contain any of these 3 chracters:

  • “+” (a “plus sign”) means the line was missing from the previous version.
  • “-” (a “minus sign”) means the line was added to the previous version.
  • “Â ” (a space) means the line was not changed.

Let’s start with the following output from git diff:

This is the README file.^^

The two leading spaces mean both the master and test versions of the file had this line.

Let’s look at the next line:

++<<<<<<< HEAD^^

The “++” at the beginning of the line means both the master and test did not have this line (or the line would need to be added to the master and test version to make it the same as the current version).

It makes sense neither version would have included that line because the git merge command added the line to the current version.

Next:

+ This line was added from the 'master' branch.^^

The space in the first column means the master branch included the line and the + in the second column means the test branch did not include this line.

Display Another Branch’s Version Of A File

We can see the complete contents of the README file from the test branch. Simply prefix the branch name and colon (“test:“) to the file:

$ git show test:READMEThis is the README file. The 'test' branch version is here.One more line.

Which Files Need Merging?

In addition to using git status, to see which files need merging, we can also use git ls-files -u:

$ git ls-files -u100644 b0ed415d15862ac5582b51e4de65528e86934cd2 1 README100644 56df44dd62daa9a16ab69f49e7f25df54054dae3 2 README100644 9585db7d9c2d9ca05075f67a878f2554886d7b1a 3 README

Every line, above, lists the filename README, reporting it clearly needs to be merged. But why is it listed 3 times? Because git has 3 versions of the file, labeled 1, 2, and 3 immediately before the README filename. The versions are:

  • 1: The “common ancestor” of the file (the version of the file that both the current and other branch originated from).
  • 2: The version from the current branch (the master branch in this case).
  • 3: The version from the other branch (the test branch)

We can see the different versions of the files like this by prepending :stage#: where “stage#” is the number shown above.

$ git show :1:READMEThis is the README file.One more line.$ git show :2:READMEThis is the README file. This line was added from the 'master' branch.One more line.$ git show :3:READMEThis is the README file. The 'test' branch version is here.One more line.$ git show :4:READMEfatal: Path '4:README' does not exist (neither on disk nor in the index).

Resolve the conflict

After we have resolved the conflict (by changing the README file the way we want for this git merge), we have to tell git that the conflict is resolved by adding the conflicted file to the index.

In this case, we need to add README to the git index. git status will then no longer complain about the README file having a conflict:

$ git add README$ git status# On branch master# Changes to be committed:## modified: README# new file: plan#

We’re ready to commit the merge:

$ git commit[master 368a14a] Merge branch 'test'

The git log command shows the resolved conflict:

$ git logcommit 368a14a034eda95ee401bb56b3bb8df04b84ab0cMerge: 3330113 c406564Author: Tim Flagg <me@gitguys.com>Date: Fri Mar 25 13:26:10 2011 -0700 Merge branch 'test' Conflicts: READMEcommit c40656482d0d2f0b9c9b37f74ea84a9c54929a56Author: Tim Flagg <me@gitguys.com>Date: Thu Mar 24 17:04:00 2011 -0700 README changed in the test branchcommit 3330113bda8d3544ef6f05275970cd4dd705ef03Author: Tim Flagg <me@gitguys.com>Date: Thu Mar 24 16:48:19 2011 -0700 README changed in the master branch...

gitg –all shows the merge:

End of conflict. Fade to commercial.

Next: Merging With A GUI
Previous: Merging Branches: Without A Conflict

Related:

Creating And Playing With Branches
Git Object: Commit

Recent Articles

What is the deal with the Git Index? What is the Git Index?

The git "index" is where you place files you want committed to the git repository. Learn more about the git index and git commit by selecting this link.

Visualising Branches And Their Commits | Git Show-branch

We explain and discuss the use of the git show-branch, gitg, gitk and qgit in this Tutorial. Complete with examples.

“Tracking Branches” And “Remote-Tracking Branches”

Both Tracking Branches and Remote Tracking Branches are created on the git client when a git clone command is used.

Temporarily Stashing Your Work

Git Stash is used when you want to record the current state of the working directory and index, without committing, to come back to complete later.

Shared Repositories Should Be Bare Repositories

Bare Repositories - When creating a central repository that will be shared by other users, the repositories should be created with the --bare option.

Related Stories

Leave A Reply

Please enter your comment!
Please enter your name here

Stay on op - Ge the daily news in your inbox