In a git merge conflict, what are the BACKUP, BASE, LOCAL, and REMOTE files that are generated?

Question

I assume the LOCAL and REMOTE files are just what their name suggests, but what are BASE and BACKUP for?

Nickeliferous

Answer 1

Git performs a three-way merge, finding the common ancestor (aka "merge base") of the two branches you are merging. When you invoke git mergetool on a conflict, it will produce these files suitable for feeding into a typical 3-way merge tool. Thus:

• foo.LOCAL: the "ours" side of the conflict - ie, your branch (HEAD) that will contain the results of the merge
• foo.REMOTE: the "theirs" side of the conflict - the branch you are merging into HEAD
• foo.BASE: the common ancestor. useful for feeding into a three-way merge tool
• foo.BACKUP: the contents of file before invoking the merge tool, will be kept on the filesystem if mergetool.keepBackup = true.

Hanhhank

No. LOCAL is the version in HEAD. BACKUP was the version that was on-disk before you invoked mergetool. It probably contains the diff3 conflict markers and you may have edited it before invoking mergetool. – Hanhhank

See here also : https://mcmap.net/q/16906/-which-version-of-the-git-file-will-be-finally-used-local-base-or-remote – Clustered

here is a good article explaining merging cases including the three-way merging : git-scm.com/book/en/v2/… – Tiaratibbetts

the words LOCAL/REMOTE is somehow misleading, makes me thinking they are referring to "my changes"/"remote changes", but actually usually in context of "merge into master", LOCAL is the target branch which is other's modification, and REMOTE is the source branch which is my modifications. :) – Telephoto

They are... Are you doing a rebase? Because the sides are reversed in a rebase. – Hanhhank

@TingQianLI I find your description of "other's modification" and "my modifications" equally confusing when I don't care "who" made changes. I only care what branch what version belongs to, and that is as you say LOCAL = Target and Remote = source. – Antiphonal

@VictorChoy use the git merge-base command (providing it with the refs that you want to merge) – Hanhhank

I try this, but I find the file in commit is different in android studio merge layout that have same window with three-way merge, LOCAL, BASE version, Remote. @EdwardThomson – Dustpan

Answer 2

In case of pulling (merging) in changes from a online repository into your local copy, you can understand REMOTE, LOCAL and BASE as:

• REMOTE = Your local file including own modifications ('as on the filesystem')
• LOCAL = The remote file inside the online repository ('changes made by other users')
• BASE = The origin of both files ('without any modifications')

The terms are from the point of view of the online repository which is what 'local' refers to. See also the wikipedia article about three-way merge.

Coalfish

Upvote for using a graphic. The reason this stuff is hard to understand is that most merge tools use only text. And, CLI is no substitute for a chart to make GIT make sense. I wish I could upvote more times. (Some people need to embrace that CLI is one of many tools and not the only one, and sometimes it's the wrong tool.) – Packer

The graphic also made this make more sense for when doing merges in my own local repository. "Local" and "remote" are confusing names if the "remote" commit is actually a commit within my "local" repository. Too many names have multiple meanings in git. – Packer

Did something change? I've tested this, and the LOCAL file contains "done by me", and the REMOTE contains "done by others". Both in TortoiseGit and in git mergetool. – Alpinist

In accepted answer local is considered as 'ours' side? Can someone explain diferences in acepted answer? – Theosophy

REMOTE is mine?!! that is confusing! – Vulturine

This is not true. Local is always the branch that your Git-HEAD is pointing at currently. => Merge: - BASE: The origin of both files ('without any modifications`) - LOCAL: The branch you are pulling into - REMOTE: The branch you are pulling – Smokejumper

I agree with @Shanakor , the answer is wrong. The so called local or remote basically indicates what git does in terms of “check out/switch branch” . If you are currently at branch A, and if you run git merge B, git stay in your Branch A for merge command, so local is A; if you are currently in Branch A, and you run git rebase B, (or rebase onto), internally, git check out /switch to B, and then the local is of course B; – Masto

Answer 3

According to https://git-scm.com/docs/git-mergetool

When git mergetool is invoked with this tool (either through the -t or --tool option or the merge.tool configuration variable) the configured command line will be invoked with $BASE set to the name of a temporary file containing the common base for the merge, if available; $LOCAL set to the name of a temporary file containing the contents of the file on the current branch; $REMOTE set to the name of a temporary file containing the contents of the file to be merged, and $MERGED set to the name of the file to which the merge tool should write the result of the merge resolution.

However, there seems to be a difference between a rebase command and a merge command.

Merge uses your local branch as LOCAL and the branch you're merging in as REMOTE

Rebase uses your local branch as REMOTE and the branch you're rebasing onto as LOCAL

Norford

Answer 4

I agree with @Shanakor ,one of the the answer is wrong. The so called local or remote basically indicates what git does in terms of “check out/switch branch” . If you are currently at branch A, and if you run git merge B, git stays in your Branch A for merge command, so local is A; if you are currently in Branch A, and you run git rebase B, (or rebase --onto B), internally, git check out /switch to B, and then the local is of course B;

See: https://git-scm.com/docs/git-rebase

Quote: If is specified, git rebase will perform an automatic git switch before doing anything else. Otherwise it remains on the current branch.

Masto