theirs - how to resolve conflicts in git eclipse




How to resolve merge conflicts in Git (20)

git fetch
git checkout your branch
git rebase master

In this step you will try to fix the conflict using your prefer IDE

You can follow this link to check ho to fix the conflict in the file
https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/

git add
git rebase --continue
git commit --amend
git push origin HEAD:refs/drafts/master (push like a drafts)

Now every thing is fine and you will find your commit in gerrit

I hope that this will help every one concerning this issue.

Is there a good way to explain how to resolve merge conflicts in Git?


Bonus:

In speaking of pull/fetch/merge in the above answers, I would like to share an interesting and productive trick,

git pull --rebase

This above command is the most useful command in my git life which saved a lots of time.

Before pushing your newly committed change to remote server, try git pull --rebase rather git pull and manual merge and it will automatically sync latest remote server changes (with a fetch + merge) and will put your local latest commit at the top in git log. No need to worry about manual pull/merge.

In case of conflict, just use

git mergetool
git add conflict_file
git rebase --continue

Find details at: http://gitolite.com/git-pull--rebase


  1. Identify which files are in conflict (Git should tell you this).

  2. Open each file and examine the diffs; Git demarcates them. Hopefully it will be obvious which version of each block to keep. You may need to discuss it with fellow developers who committed the code.

  3. Once you've resolved the conflict in a file git add the_file.

  4. Once you've resolved all conflicts, do git rebase --continue or whatever command Git said to do when you completed.


A safer way to resolve conflicts is to use git-mediate (the common solutions suggested here are quite error prone imho).

See this post for a quick intro on how to use it.


Check out the answers in question Aborting a merge in Git, especially Charles Bailey's answer which shows how to view the different versions of the file with problems, for example,

# Common base version of the file.
git show :1:some_file.cpp

# 'Ours' version of the file.
git show :2:some_file.cpp

# 'Theirs' version of the file.
git show :3:some_file.cpp

CoolAJ86's answer sums up pretty much everything. In case you have changes in both branches in the same piece of code you will have to do a manual merge. Open the file in conflict in any text editor and you should see following structure.

(Code not in Conflict)
>>>>>>>>>>>
(first alternative for conflict starts here)
Multiple code lines here
===========
(second alternative for conflict starts here)
Multiple code lines here too    
<<<<<<<<<<<
(Code not in conflict here)

Choose one of the alternatives or a combination of both in a way that you want new code to be, while removing equal signs and angle brackets.

git commit -a -m "commit message"
git push origin master

For those who are using Visual Studio (2015 in my case)

  1. Close your project in VS. Especially in big projects VS tends to freak out when merging using the UI.

  2. Do the merge in command prompt.

    git checkout target_branch

    git merge source_branch

  3. Then open the project in VS and go to Team Explorer -> Branch. Now there is a message that says Merge is pending and conflicting files are listed right below the message.

  4. Click the conflicting file and you will have the option to Merge, Compare, Take Source, Take Target. The merge tool in VS is very easy to use.


Here's a probable use-case, from the top:

You're going to pull some changes, but oops, you're not up to date:

git fetch origin
git pull origin master

From ssh://[email protected]:22/projectname
 * branch            master     -> FETCH_HEAD
Updating a030c3a..ee25213
error: Entry 'filename.c' not uptodate. Cannot merge.

So you get up-to-date and try again, but have a conflict:

git add filename.c
git commit -m "made some wild and crazy changes"
git pull origin master

From ssh://[email protected]:22/projectname
 * branch            master     -> FETCH_HEAD
Auto-merging filename.c
CONFLICT (content): Merge conflict in filename.c
Automatic merge failed; fix conflicts and then commit the result.

So you decide to take a look at the changes:

git mergetool

Oh me, oh my, upstream changed some things, but just to use my changes...no...their changes...

git checkout --ours filename.c
git checkout --theirs filename.c
git add filename.c
git commit -m "using theirs"

And then we try a final time

git pull origin master

From ssh://[email protected]:22/projectname
 * branch            master     -> FETCH_HEAD
Already up-to-date.

Ta-da!


I either want my or their version in full, or want to review individual changes and decide for each of them.

Fully accept my or theirs version:

Accept my version (local, ours):

git checkout --ours -- <filename>
git add <filename>              # Marks conflict as resolved
git commit -m "merged bla bla"  # An "empty" commit

Accept their version (remote, theirs):

git checkout --theirs -- <filename>
git add <filename>
git commit -m "merged bla bla"

If you want to do for all conflict files run:

git merge --strategy-option ours

or

git merge --strategy-option theirs

Review all changes and accept them individually

  1. git mergetool
  2. Review changes and accept either version for each of them.
  3. git add <filename>
  4. git commit -m "merged bla bla"

Default mergetool works in command line. How to use a command line mergetool should be a separate question.

You can also install visual tool for this, e.g. meld and run

git mergetool -t meld

It will open local version (ours), "base" or "merged" version (the current result of the merge) and remote version (theirs). Save the merged version when you are finished, run git mergetool -t meld again until you get "No files need merging", then go to Steps 3. and 4.


I find merge tools rarely help me understand the conflict or the resolution. I'm usually more successful looking at the conflict markers in a text editor and using git log as a supplement.

Here are a few tips:

Tip One

The best thing I have found is to use the "diff3" merge conflict style:

git config merge.conflictstyle diff3

This produces conflict markers like this:

<<<<<<<
Changes made on the branch that is being merged into. In most cases,
this is the branch that I have currently checked out (i.e. HEAD).
|||||||
The common ancestor version.
=======
Changes made on the branch that is being merged in. This is often a 
feature/topic branch.
>>>>>>>

The middle section is what the common ancestor looked like. This is useful because you can compare it to the top and bottom versions to get a better sense of what was changed on each branch, which gives you a better idea for what the purpose of each change was.

If the conflict is only a few lines, this generally makes the conflict very obvious. (Knowing how to fix a conflict is very different; you need to be aware of what other people are working on. If you're confused, it's probably best to just call that person into your room so they can see what you're looking at.)

If the conflict is longer, then I will cut and paste each of the three sections into three separate files, such as "mine", "common" and "theirs".

Then I can run the following commands to see the two diff hunks that caused the conflict:

diff common mine
diff common theirs

This is not the same as using a merge tool, since a merge tool will include all of the non-conflicting diff hunks too. I find that to be distracting.

Tip Two

Somebody already mentioned this, but understanding the intention behind each diff hunk is generally very helpful for understanding where a conflict came from and how to handle it.

git log --merge -p <name of file>

This shows all of the commits that touched that file in between the common ancestor and the two heads you are merging. (So it doesn't include commits that already exist in both branches before merging.) This helps you ignore diff hunks that clearly are not a factor in your current conflict.

Tip Three

Verify your changes with automated tools.

If you have automated tests, run those. If you have a lint, run that. If it's a buildable project, then build it before you commit, etc. In all cases, you need to do a bit of testing to make sure your changes didn't break anything. (Heck, even a merge without conflicts can break working code.)

Tip Four

Plan ahead; communicate with co-workers.

Planning ahead and being aware of what others are working on can help prevent merge conflicts and/or help resolve them earlier -- while the details are still fresh in mind.

For example, if you know that you and another person are both working on different refactoring that will both affect the same set of files, you should talk to each other ahead of time and get a better sense for what types of changes each of you is making. You might save considerable time and effort if you conduct your planned changes serially rather than in parallel.

For major refactorings that cut across a large swath of code, you should strongly consider working serially: everybody stops working on that area of the code while one person performs the complete refactoring.

If you can't work serially (due to time pressure, maybe), then communicating about expected merge conflicts at least helps you solve the problems sooner while the details are still fresh in mind. For example, if a co-worker is making a disruptive series of commits over the course of a one-week period, you may choose to merge/rebase on that co-workers branch once or twice each day during that week. That way, if you do find merge/rebase conflicts, you can solve them more quickly than if you wait a few weeks to merge everything together in one big lump.

Tip Five

If you're unsure of a merge, don't force it.

Merging can feel overwhelming, especially when there are a lot of conflicting files and the conflict markers cover hundreds of lines. Often times when estimating software projects we don't include enough time for overhead items like handling a gnarly merge, so it feels like a real drag to spend several hours dissecting each conflict.

In the long run, planning ahead and being aware of what others are working on are the best tools for anticipating merge conflicts and prepare yourself to resolve them correctly in less time.


If you are using intelliJ as IDE Try to merge parent to your branch by

git checkout <localbranch>
git merge origin/<remotebranch>

It will show all conflicts like this

A_MBPro:test anu$ git merge origin/ Auto-merging src/test/java/com/.../TestClass.java CONFLICT (content): Merge conflict in src/test/java/com/.../TestClass.java

Now note that the file TestClass.java is shown in red in intelliJ Also git status will show

Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified:   src/test/java/com/.../TestClass.java

Open the file in intelliJ, it will have sections with

  <<<<<<< HEAD
    public void testMethod() {
    }
    =======
    public void testMethod() { ...
    }
    >>>>>>> origin/<remotebranch>

where HEAD is changes on your local branch and origin/ is changes from the remote branch. Here keep the stuff that you need and remove the stuff you don't need.After that the normal steps should do. That is

   git add TestClass.java
   git commit -m "commit message"
   git push

If you want to merge from branch (test) to master, you can follow these steps:

Step 1: Go to the branch

git checkout test

Step 2: git pull --rebase origin master

Step 3: If there are some conflicts, go to these files to modify it.

Step 4: Add these changes

git add #your_changes_files

Step 5: git rebase --continue

Step 6: if there is still conflict, go back to step 3 again. If there is no conflict, do following: git push origin +test

Step 7: And then there is no conflict between test and master. You can use merge directly.


Merge conflicts could occur in different situations:

  • When running "git fetch" and then "git merge"
  • When running "git fetch" and then "git rebase"
  • When running "git pull" (which is actually equal to one of the above-mentioned conditions)
  • When running "git stash pop"
  • When you're applying git patches (commits that are exported to files to be transferred, for example, by email)

You need to install a merge tool which is compatible with Git to resolve the conflicts. I personally use KDiff3, and I've found it nice and handy. You can download its Windows version here:

https://sourceforge.net/projects/kdiff3/files/

BTW if you install Git Extensions there is an option in its setup wizard to install Kdiff3.

Then setup git configs to use Kdiff as its mergetool:

$ git config --global --add merge.tool kdiff3
$ git config --global --add mergetool.kdiff3.path "C:/Program Files/KDiff3/kdiff3.exe"
$ git config --global --add mergetool.kdiff3.trustExitCode false

$ git config --global --add diff.guitool kdiff3
$ git config --global --add difftool.kdiff3.path "C:/Program Files/KDiff3/kdiff3.exe"
$ git config --global --add difftool.kdiff3.trustExitCode false

(Remember to replace the path with the actual path of Kdiff exe file.)

Then every time you come across a merge conflict you just need to run this command:

$git mergetool

Then it opens the Kdiff3, and first tries to resolve the merge conflicts automatically. Most of the conflicts would be resolved spontaneously and you need to fix the rest manually.

Here's what Kdiff3 looks like:

Then once you're done, save the file and it goes to the next file with conflict and you do the same thing again until all the conflicts are resolved.

To check if everything is merged successfully, just run the mergetool command again, you should get this result:

$git mergetool
No files need merging

Merge conflicts happens when changes are made to a file at the same time. Here is how to solve it.

git CLI

Here are simple steps what to do when you get into conflicted state:

  1. Note the list of conflicted files with: git status (under Unmerged paths section).
  2. Solve the conflicts separately for each file by one of the following approaches:

    • Use GUI to solve the conflicts: git mergetool (the easiest way).

    • To accept remote/other version, use: git checkout --theirs path/file. This will reject any local changes you did for that file.

    • To accept local/our version, use: git checkout --ours path/file

      However you've to be careful, as remote changes that conflicts were done for some reason.

      Related: What is the precise meaning of "ours" and "theirs" in git?

    • Edit the conflicted files manually and look for the code block between <<<<</>>>>> then choose the version either from above or below =====. See: How conflicts are presented.

    • Path and filename conflicts can be solved by git add/git rm.

  3. Finally, review the files ready for commit using: git status.

    If you still have any files under Unmerged paths, and you did solve the conflict manually, then let Git know that you solved it by: git add path/file.

  4. If all conflicts were solved successfully, commit the changes by: git commit -a and push to remote as usual.

See also: Resolving a merge conflict from the command line at GitHub

DiffMerge

I've successfully used DiffMerge which can visually compare and merge files on Windows, macOS and Linux/Unix.

It graphically can show the changes between 3 files and it allows automatic merging (when safe to do so) and full control over editing the resulting file.

Image source: DiffMerge (Linux screenshot)

Simply download it and run in repo as:

git mergetool -t diffmerge .

macOS

On macOS you can install via:

brew install caskroom/cask/brew-cask
brew cask install diffmerge

And probably (if not provided) you need the following extra simple wrapper placed in your PATH (e.g. /usr/bin):

#!/bin/sh
DIFFMERGE_PATH=/Applications/DiffMerge.app
DIFFMERGE_EXE=${DIFFMERGE_PATH}/Contents/MacOS/DiffMerge
exec ${DIFFMERGE_EXE} --nosplash "[email protected]"

Then you can use the following keyboard shortcuts:

  • -Alt-Up/Down to jump to previous/next changes.
  • -Alt-Left/Right to accept change from left or right

Alternatively you can use opendiff (part of Xcode Tools) which lets you merge two files or directories together to create a third file or directory.


See How Conflicts Are Presented or, in Git, the git merge documentation to understand what merge conflict markers are.

Also, the How to Resolve Conflicts section explains how to resolve the conflicts:

After seeing a conflict, you can do two things:

  • Decide not to merge. The only clean-ups you need are to reset the index file to the HEAD commit to reverse 2. and to clean up working tree changes made by 2. and 3.; git merge --abort can be used for this.

  • Resolve the conflicts. Git will mark the conflicts in the working tree. Edit the files into shape and git add them to the index. Use git commit to seal the deal.

You can work through the conflict with a number of tools:

  • Use a mergetool. git mergetool to launch a graphical mergetool which will work you through the merge.

  • Look at the diffs. git diff will show a three-way diff, highlighting changes from both the HEAD and MERGE_HEAD versions.

  • Look at the diffs from each branch. git log --merge -p <path> will show diffs first for the HEAD version and then the MERGE_HEAD version.

  • Look at the originals. git show :1:filename shows the common ancestor, git show :2:filename shows the HEAD version, and git show :3:filename shows the MERGE_HEAD version.

You can also read about merge conflict markers and how to resolve them in the Pro Git book section Basic Merge Conflicts.


Simply, if you know well that changes in one of the repositories is not important, and want to resolve all changes in favor of the other one, use:

git checkout . --ours

to resolve changes in the favor of your repository, or

git checkout . --theirs

to resolve changes in favor of the other or the main repository.

Or else you will have to use a GUI merge tool to step through files one by one, say the merge tool is p4merge, or write any one's name you've already installed

git mergetool -t p4merge

and after finishing a file, you will have to save and close, so the next one will open.


This answers is to add an alternative for those VIM users like I that prefers to do everything within the editor.


TL;DR


Tpope came up with this great plugin for VIM called fugitive. Once installed you can run :Gstatus to check the files that have conflict and :Gdiff to open Git in a 3 ways merge.

Once in the 3-ways merge, fugitive will let you get the changes of any of the branches you are merging in the following fashion:

  • :diffget //2, get changes from original (HEAD) branch:
  • :diffget //3, get changes from merging branch:

Once you are finished merging the file, type :Gwrite in the merged buffer. Vimcasts released a great video explaining in detail this steps.


Try Visual Studio Code for editing if you aren't already. What it does is after you try merging(and land up in merge conflicts).VS code automatically detects the merge conflicts.

It can help you very well by showing what are the changes made to the original one and should you accept incoming or

current change(meaning original one before merging)'?.

It helped for me and it can work for you too !

PS: It will work only if you've configured git with with your code and Visual Studio Code.


You could fix merge conflicts in a number of ways as other have detailed.

I think the real key is knowing how changes flow with local and remote repositories. The key to this is understanding tracking branches. I have found that I think of the tracking branch as the 'missing piece in the middle' between me my local, actual files directory and the remote defined as origin.

I've personally got into the habit of 2 things to help avoid this.

Instead of:

git add .
git commit -m"some msg"

Which has two drawbacks -

a) All new/changed files get added and that might include some unwanted changes.
b) You don't get to review the file list first.

So instead I do:

git add file,file2,file3...
git commit # Then type the files in the editor and save-quit.

This way you are more deliberate about which files get added and you also get to review the list and think a bit more while using the editor for the message. I find it also improves my commit messages when I use a full screen editor rather than the -m option.

[Update - as time has passed I've switched more to:

git status # Make sure I know whats going on
git add .
git commit # Then use the editor

]

Also (and more relevant to your situation), I try to avoid:

git pull

or

git pull origin master.

because pull implies a merge and if you have changes locally that you didn't want merged you can easily end up with merged code and/or merge conflicts for code that shouldn't have been merged.

Instead I try to do

git checkout master
git fetch   
git rebase --hard origin/master # or whatever branch I want.

You may also find this helpful:

git branch, fork, fetch, merge, rebase and clone, what are the differences?


git checkout branch1

git fetch origin

git rebase -p origin/mainbranch

If there are merge conflicts, fix them. Then, continue the rebase process by running: git rebase –-continue

after the fixing you can commit and push your local branch to remote branch

git push origin branch1




git-conflict-resolution