Accepted answer

are you using the team synchronise view? if so that's the problem. conflict resolution in the team synchronise view doesn't work with egit. instead you need to use the git repository view.

open the git perspective. in the git repository view, go to on brancheslocalmaster and right click → merge...

it should auto select remote trackingorigin/master. press merge.

it should show result:conflict.

open the conflicting files. they should have an old sk000l >>>> ===== <<<< style merge conflict in the files. edit the file to resolve the conflict, and save.

now in the 'git staging' view, it should show the changed file in 'unstaged changes'. right click and 'add to index'

enter image description here

repeat for any remaining files.

now from the 'git staging' view, commit and push. as git/eclipse now knows that you have merged the remote origin changes into your master, you should avoid the non-fast-forward error.


to resolve the conflicts, use git stash to save away your uncommitted changes; then pull down the remote repository change set; then pop your local stash to reapply your uncommitted changes.

in eclipse v4.5 (mars) to stash changes (a relatively recent addition, wasn't in previous egit) i do this: right-click on a top-level eclipse project that's in git control, pick team, pick stashes, pick stash changes; a dialog opens to request a stash commit message.

you must use the context menu on a top level project! if i right click on a directory or file within a git-controlled project i don't get the appropriate context menu.


this approach is similar to "stash" solution but i think it might be more clear:

  1. your current local branch is "master" and you have local changes.
  2. after synchronizing, there are incoming changes and some files need to be merged.
  3. so, the first step is to switch to a new local branch (say "my_changes"):
    • team -> switch to -> new branch
      • branch name: my_changes (for example)
  4. after switching to the new branch, the uncommitted local changes still exist. so, commit all your local uncommitted changes to the new branch "my_changes":
  5. switch back to the local "master" branch:
    • team -> switch to -> master
  6. now, when you choose team -> synchronize workspace, no "merge" files are expected to appear.
  7. select team -> pull
    • now the local "master" branch is up to date with respect to the remote "master" branch.
  8. now, there are two options:
    • option 1:
      • select team -> merge to merge the original local changes from "my_changes" local branch into "master" local branch.
      • now commit the incoming changes from the previous step into the local "master" branch and push them to the remote "master" branch.
    • option 2:
      • switch again to "my_changes" local branch.
      • merge the updates from the local "master" branch into "my_changes" branch.
      • proceed with the current task in "my_changes" branch.
      • when the task is done, use option 1 above to update both the local "master" branch as well as the remote one.


git has the most irritating way of resolving conflicts (unlike svn where you can simply compare and do the changes). i strongly feel git has complex conflict resolution process. if i were to resolve, i would simply take another code from git as fresh, add my changes and commit them. it simple and not so process oriented.


an earlier process of resolving conflicts (through the staging view) in eclipse seemed much more intuitive several years ago, so either the tooling no longer functions in the way that i was used to, or i am remembering the process of resolving merge conflicts within svn repositories. regardless, there was this nifty "mark as merged" menu option when right-clicking on a conflicting file.

fast forward to 2019, i am using the "git staging" view in eclipse (v4.11). actually, i am using sts (spring tool suite 3.9.8), but i think the git staging view is a standard eclipse plugin for working with java/spring-based projects. i share the following approach in case it helps anyone else, and because i grow weary or resolving merge conflicts from the git command line. ;-)

because the feature i recall is now gone (or perhaps done differently with the current version of git and eclipse), here are the current steps that i now follow to resolve merge conflicts through eclipse using a git repository. it seems the most intuitive to me. obviously, it is clear from the number of responses here that there are many ways to resolve merge conflicts. perhaps i just need to switch to jetbrains intellij, with their three-way merge tool.

  1. double-click on the offending file
  2. a "text compare" interface appears, with side-by-side views of the conflicting commits.
  3. identify which view is the local state of the file, or the most recent commit.
  4. make changes to the local window, either adding or redacting the changes from the offending commit.
  5. when the desired set of changes has been reviewed and updated, right-click on the unstaged file.
  6. click the "add to index" option, and your file will be added to the staged changes.
  7. this also removes the conflicting file from the unstaged list, thus indicating that it has been "marked as merged"
  8. continue this process with each additional file in conflict.
  9. when you have reivewed all conflicting files, confirm that all desired files (including additional changes) are staged.
  10. add an appropriate commit message.
  11. commit and push the "merged" files to the origin repository, and this officially marks your files as merged.

note: because the menu options are not intuitive, a number of things can be misleading. for example, if you have saved any updates locally, and try to reopen the conflicting file to confirmand that the changes you made have persisted, confusion may result since the original conflict state is opened... not your changes.

but once you add the file(s) to the index, you will see your changes there.

i also recommend that when you pull in changes that result in a merge conflict, that you "stash" your local changes first, and then pull the changes in again. at least with git, as a protection, you will not be allowed to pull in external changes until you either revert your changes or stash them. discard and revert to the head state if the changes are not important, but stash them otherwise.

finally, if you have just one or two files changing, then consider pulling them into separate text files as a reference, then revert to the head and then manually update the file(s) when you pull changes across.


as it's an issue we face more than often, below are the steps to resolve it.

  1. open the git perspective. in the git repository view, go to on brancheslocalmaster and right click → merge...

  2. it should auto select remote tracking → *origin/master. press merge.

  3. launch stage view in eclipse.

  4. double click the files which initially showed conflict

  5. in the conflict merge view, by selecting the left arrow for all the non-conflict + conflict changes from left to right, you can resolve all the conflicts.

  6. save the merged file.

  7. do a team → pull from eclipse again.

you are all set :)


just right click on a conflicting file and add it to the index after resolving conflicts.


i know this is an older post, but i just got hit with a similar issue and was able to resolve it, so i thought i'd share.

(update: as noted in the comments below, this answer was before the inclusion of the "git stash" feature to egit.)

what i did was:

  1. copy out the local copy of the conflicting file that may or may not have any changes from the version on the upstream.
  2. within eclipse, "revert" the file to the version right before the conflict.
  3. run a "pull" from the remote repository, allowing all changes to be synced to the local work directory. this should clear the updates coming down to your filesystem, leaving only what you have left to push.
  4. check the current version of the conflicting file in your work directory with the copy you copied out. if there are any differences, do a proper merge of the files and commit that version of the file in the work directory.
  5. now "push" your changes up.

hope that helps.


this guide was helpful for me

updated just a note on that about my procedure, this is how i proceed:

  1. commit my change
  2. fetch (syncrhonize workspace)
  3. pull
  4. manage conflicts with merge tool (team->merge tool) and save
  5. add each file to stage (team -> add to index)
  6. now the commit message in the stage window is prefilled with "merged xxx". you can leave as it is or change the commit message
  7. commit and push

it is dangerous in some cases but it is very usefull to avoid to use external tool like git extension or source tree


i also find it confusing to resolve merge conflicts in egit. when i am ready to commit some changes to a shared repository, the steps i have learned are as follows:

  1. right click on the project and choose team: commit....
  2. review my changes to check that i'm not committing any changes i made accidentally or unrelated changes that i forgot about. write up the commit message while i'm reviewing the changes.
  3. i'm optimistic, so i start by clicking the commit and push button. if no one else has pushed any changes, i'm done. if someone has, then the commit succeeds, and the push gets rejected.
  4. right click on the project and choose team: pull. if there are no conflicts, then choose team: push to upstream and i'm done.
  5. if there are conflicts, look through the package explorer to see which files are conflicted. right click on each conflicted file, and choose team: merge tool. it will show all the changes in both versions of the file, with any conflicts shown in red. click on the button to merge all non-conflict changes, then edit any red sections manually. there's also a button to show a three way merge that includes the common ancestor.
  6. save the changes to the file. if you want, you can compare it to head to see what changes you are making on top of the changes you just pulled.
  7. right click on the file and choose team: add to index to tell egit that you've finished merging that file. to me, this is the least intuitive step, but the git command line also uses the add command to show that a merge is finished.
  8. repeat for any other conflicted files.
  9. when all the files are merged, right click on the project and choose team: rebase: continue rebase. if there are more conflicted commits, go back to dealing with conflicts.
  10. when the rebase is complete, run your tests to see that the rebase didn't break anything.
  11. right click on the project and choose team: push to upstream.

Related Query

More Query from same tag