Resolving Merge Conflicts

This web page describes a couple options of what to do if a push results with the message:

rejected master -> master (non-fast-forward)

This message means that the push failed, even though it might appear otherwise.


When two or more members of your team are working on the same file at the same time, then you will end up with a merge conflict. Suppose team members Alice and Bob pull their repo and start changing at roughly the same time. If Alice pushes her changes first, then when Bob pushes his changes, git will probably be unable to merge the changes automatically. In this case, Bob will have to figure out how to resolve the conflict.

In more detail, suppose Alice and Bob start off with version 1 of from the remote repo. Alice makes some changes resulting in version 2A on her local repo, and Bob makes some changes resulting in version 2B on his local repo. [Note: Git doesn't keep track of files using this kind of version numbers.] Next, Alice pushes her changes without any problems, so the remote repo now has version 2A of and a record of how to get from version 1 to version 2A. Now when Bob tries to push his changes, he is telling the remote repo how to get from version 1 to version 2B. However, what the remote repo needs to know is how to merge versions 2A and 2B into a version 3. To resolve this conflict, Bob performs a pull so that his local repo contains a mix of versions 2A and 2B; any differences between Bob's and Alice's files will be marked. Once Bob has resolved the differences, he can push version 3 to the remote repo.


Step 1: right click your project -> Team -> Pull

This will retrieve the version from the remote repo. Any files that need attention will have a red marker in the Package Explorer view on the left of your Eclipse window. These files will also be modified indicating the differences between your local repo and the remote repo. For example:

public class Hello {
    public static void main(String[] args) {
<<<<<<<< HEAD
        System.out.println("Hello Universe!!!");
        System.out.println("Hello World!!!");
>>>>>>>> branch 'master' of

The "textual conflict markers" show that the local repo has a statement printing Hello Universe!!! while the remote repo has a statement printing Hello World!!!.

What if no files have been marked?

It is possible that no files are marked. The likely scenario is that another team member pushed different files to the remote repo. In this case, you can skip Step 2 and Step 3, and proceed to Step 4.

Step 2: Edit the files that have markers

Every file with markers needs to be edited, which includes removing the markers. For example:

public class Hello {
    public static void main(String[] args) {
        System.out.println("Hello World and the Universe!!!");

Step 3: "Add" the Files

Once you have edited and saved the files with conflicts, then, for each of these files, in the Package Explorer view

right click on the file -> Team -> Add to Index

At this point, the red markers in the Package Explorer should disappear.

Step 4: Push

Finally, right click on the project -> Team -> Commit

Possibly at this point, you might get a peculiar message about whether you want to modify your commit.

No changed items were selected. Do you wish to amend the last commit?

The answer is yes.

Now the commit window should show up with a merge commit message already in place, so Commit and Push. If you get another merge conflict after the Commit and Push, you will need to repeat Steps 1-4.

The Nuclear Option

Sometimes, you might reach the point where nothing you do will resolve the conflict. At this point, it is probably easiest to start over by doing the following.

Avoiding more issues means that you need to communicate with your team about who has the primary duty to edit which files. Of course, it might be unavoidable to edit the files of other team members. If you need to do this, you need to communicate to your team about what you are doing.