I'm merging in a remote branch that may have a lot of conflicts. How can I tell if it will have conflicts or not?
I don't see anything like a --dry-run
on git-merge
.
I'm merging in a remote branch that may have a lot of conflicts. How can I tell if it will have conflicts or not?
I don't see anything like a --dry-run
on git-merge
.
As noted previously, pass in the --no-commit
flag, but to avoid a fast-forward commit, also pass in --no-ff
, like so:
$ git merge --no-commit --no-ff $BRANCH
To examine the staged changes:
$ git diff --cached
And you can undo the merge, even if it is a fast-forward merge:
$ git merge --abort
0
iff the merge is possible.
Commented
Jul 7, 2014 at 14:30
git checkout .
doesn't revert the files to pre-merge status.
git diff --cached
(or --staged
) displays only those changes.
--no-ff
was necessary to prevent it from being automatically committed. (It's not necessary in more recent versions of Git.)
I just had to implement a method that automatically finds conflicts between a repository and its remote. This solution does the merge in memory so it won't touch the index, nor the working tree. I think this is the safest possible way you can solve this problem. Here's how it works:
git fetch origin master
git merge-base FETCH_HEAD master
git merge-tree mergebase master FETCH_HEAD
(mergebase is the hexadecimal id that merge-base printed in the previous step)Now suppose that you want to merge the remote master with your local master, but you can use any branches. git merge-tree
will execute the merge in memory and print the result to the standard output. Grep for the pattern <<
or >>
. Or you can print the output to a file and check that. If you find a line starting with 'changed in both' then most probably there will be a conflict.
git merge-tree `git merge-base FETCH_HEAD master` FETCH_HEAD master
git merge-tree `git merge-base clieop master` clieop master | grep -A3 "changed in both"
Simply awesome! +100
+<<<<<<< .our
, so I use a grep expression like grep -q '^+<* \.our$'
git merge-tree $(git merge-base $1 $2) $1 $2 | sed -n '/+<<<<<<< .our/,/+>>>>>>> .their/p;/^changed in both/{n;N;N;s/^/#/mg;p}' | cdiff
. It extracts the "changed in both" lines as well as the conflicting parts.
I'm assuming you just want to find out how much trouble you're getting yourself into prior to actually attempting the merge...and resetting to the last commit after a failed merge is relatively easy so I wouldn't be surprised if that is the intended approach.
That said, if you really don't want to touch your existing files in the working tree - you could create a patch and test it against the target branch. This also has the benefit of showing exactly what changes were made to which files - just open up the patch file in a text editor.
git checkout -b mycrazybranch
[change some stuff...]
git add .
git commit -m "changed some stuff"
git format-patch master --stdout > crazy.patch
git checkout master
git apply crazy.patch --check
[all good! cleanup...]
rm crazy.patch
As you can see, this will create a patch file, you can then test it with --check and see if there are any errors, then remove the patch file.
git format-patch master --stdout | git-apply --check -
git-apply
won't work. It must read git apply
.
You can do git merge --abort
after seeing that there are conflicts.
git merge other-branch --no-commit --no-ff; git merge --abort
- seems to work pretty well.
As a summary of existed answers, there are two way to check if there would be merge conflicts
git format-patch $(git merge-base branch1 branch2)..branch2 --stdout | git apply --3way --check -
Note, your current branch should be branch1
when you run above command
Another way:
git merge --no-commit branch2
# check the return code here
git merge --abort
branch1
with HEAD
, your command works from any branch.
Commented
Nov 4, 2013 at 14:51
--3way
to git apply.
My simple brute-force solution to this is:
Create a "pre-master" branch (from master of course)
Merge all the things you want to into this pre-master.
Then you can see how the merging happened without touching master.
Anyway, I would follow @orange80's advice.
git merge --abort
if there are conflicts, git reset --hard HEAD~1
if there was a merge or git reset --hard origin/master
. Creating another branch gives you a feeling of safety but if you learn how git works you will understand it is misplaced fear. When concern is about not changing the working copy, this offers no solution.
Commented
Jan 29, 2019 at 7:35
git merge --no-commit
won't abort a merge if it can be fast forwarded. git merge --abort
doesn't work if it was merged. If you want to write this as a script, it's awkward, since git merge
doesn't reply with good enough error codes to explain the different types of conflicts. Working with a fresh branch prevents a broken script from leaving your repo in a state that requires manual intervention. Sure you can't lose anything. But it's easier to build otherwise.
Commented
Oct 17, 2019 at 12:39
I made an alias for doing this and works like a charm, I do this:
git config --global alias.mergetest '!f(){ git merge --no-commit --no-ff "$1"; git merge --abort; echo "Merge aborted"; };f '
Now I just call
git mergetest <branchname>
To find out if there are any conflicts.
Undoing a merge with git is so easy you shouldn't even worry about the dry run:
$ git pull $REMOTE $BRANCH
# uh oh, that wasn't right
$ git reset --hard ORIG_HEAD
# all is right with the world
EDIT: As noted in the comments below, if you have changes in your working directory or staging area you'll probably want to stash them before doing the above (otherwise they will disappear following the git reset
above)
git branch --contains HEAD
or even more directly, just use git merge --ff-only
Commented
Dec 6, 2010 at 19:39
--dry-run
wouldn't "simply check if a merge will be fast-forward". It would return the exact output that a merge would: files, conflicts etc. Whether is will ff isn't really interesting, is it?
git stash; git reset --hard
? @BrianPhillips
Commented
Jan 15, 2015 at 20:12
Just diff your current branch against the remote branch, this will tell you what is going to change when you do a pull/merge.
#see diff between current master and remote branch
git diff master origin/master
I'm surprised nobody has suggested using patches yet.
Say you'd like to test a merge from your_branch
into master
(I'm assuming you have master
checked out):
$ git diff master your_branch > your_branch.patch
$ git apply --check your_branch.patch
$ rm your_branch.patch
That should do the trick.
If you get errors like
error: patch failed: test.txt:1
error: test.txt: patch does not apply
that means that the patch wasn't successful and a merge would produce conflicts. No output means the patch is clean and you'd be able to easily merge the branch
Note that this will not actually change your working tree (aside from creating the patch file of course, but you can safely delete that afterwards). From the git-apply documentation:
--check
Instead of applying the patch, see if the patch is applicable to the
current working tree and/or the index file and detects errors. Turns
off "apply".
Note to anyone who is smarter/more experienced with git than me: please do let me know if I'm wrong here and this method does show different behaviour than a regular merge. It seems strange that in the 8+ years that this question has existed noone would suggest this seemingly obvious solution.
git diff master your_branch | git apply --check
.
Not exactly like that. But you can use the --no-commit option, so it does not automatically commit the result after the merge. In this way you can inspect, and if desired, to undo the merge without messing with the commit tree.
I use the request-pull git command to do so. It allows you to see every change that would happen when merging, but without doing anything on your local or remote repositories.
For instance, imagine you want to merge a branch named "feature-x" into your master branch
git request-pull master origin feature-x
will show you a summary of what would happen (without doing anything):
The following changes since commit fc01dde318:
Layout updates (2015-06-25 11:00:47 +0200)
are available in the git repository at:
http://fakeurl.com/myrepo.git/ feature-x
for you to fetch changes up to 841d3b41ad:
----------------------------------------------------------------
john (2):
Adding some layout
Refactoring
ioserver.js | 8 +++---
package.json | 7 +++++-
server.js | 4 +--
layout/ldkdsd.js | 277 +++++++++++++++++++++++++++++++++++++
4 files changed, 289 insertions(+), 7 deletions(-)
create mode 100644 layout/ldkdsd.js
If you add the -p
parameter, you will also get the full patch text, exactly like if you were doing a git diff on every changed file.
master
and origin
do in the command-line options, and what about if I am for example on a local branch1
and want to do a request-pull
on a local feature branch branch2
? Do I still need origin
? Of course, one can always read the documentation.
Git introduced a --ff-only option when merging.
From: http://git-scm.com/docs/git-merge
--ff-only
Refuse to merge and exit with a non-zero status unless the current HEAD is already up-to-date or the merge can be resolved as a fast-forward.
Doing this will attempt to merge and fast-forward, and if it can't it aborts and prompts you that the fast-forward could not be performed, but leaves your working branch untouched. If it can fast-forward, then it will perform the merge on your working branch. This option is also available on git pull
. Thus, you could do the following:
git pull --ff-only origin branchA #See if you can pull down and merge branchA
git merge --ff-only branchA branchB #See if you can merge branchA into branchB
This might be interesting: From the documentation:
If you tried a merge which resulted in complex conflicts and want to start over, you can recover with git merge --abort.
But you could also do it the naive (but slow) way:
rm -Rf /tmp/repository
cp -r repository /tmp/
cd /tmp/repository
git merge ...
...if successful, do the real merge. :)
(Note: It won't work just cloning to /tmp, you'd need a copy, in order to be sure that uncommitted changes will not conflict).
cp -r repository/.git /tmp/repository/.git
, cd /tmp/repository
, git reset --hard
, git add --all
, git reset --hard
(for good measure), git status
(to check that it's clean).
I use git log to see what has changed on a feature branch from master branch
git log does_this_branch..contain_this_branch_changes
e.g. - to see what commits are in a feature branch that has/not been merged to master:
git log master..feature_branch
My solution is to merge backwards.
Instead of merging your branch into the remote "target" branch, merge that branch into yours.
git checkout my-branch
git merge origin/target-branch
You will see if there are any conflicts and can plan on how to solve them.
After that you can either abort the merge via git merge --abort
, or (if there weren't any conflicts and merge has happened) roll back to previous commit via git reset --hard HEAD~1
I want to see just the conflicts (can't see them with diff3
in GitHub, yet). Leveraging heavily from this answer above, I came up with this:
git merge --no-commit --no-ff @{upstream}
git grep -l '<<<<<<< HEAD' | xargs -I % sh -c "echo -e '\n\e[93m%\n---\e[0m' && cat %"
git merge --abort
For me, this is for checking my PRs. You can substitute @{upstream}
with whatever branch.
I hope that's helpful to someone.
If you want to fast forward from B to A, then you must make sure that git log B..A shows you nothing, i.e. A has nothing that B doesn't have. But even if B..A has something, you might still be able to merge without conflicts, so the above shows two things: that there will be a fast-forward, and thus you won't get a conflict.
I know this is theoretically off-topic, but practically very on-topic for people landing here from a Google search.
When in doubt, you can always use the Github interface to create a pull-request and check if it indicates a clean merge is possible.
Another option would be to do a "virtual" merge and easily see the result of the merge, including conflicts:
# Define the branches
origin_branch="$(git rev-parse --abbrev-ref HEAD)" #get current checked out branch
destination_branch="origin/main"
# Perform the merge-tree command (virtual merge)
git merge-tree --write-tree $origin_branch $destination_branch
And if you want to see only the conflicts, you can modify the script above as follows:
# Define the branches
origin_branch="$(git rev-parse --abbrev-ref HEAD)" #get current checked out branch
destination_branch="origin/main"
# Perform the merge-tree command and capture the output
merge_output=$(git merge-tree --write-tree --name-only $origin_branch $destination_branch)
# Extract file names with conflicts from the merge output using grep and store in an array
mapfile -t conflicted_files < <(echo "$merge_output" | grep -E '^CONFLICT*' | awk '{print $NF}')
# Display the list of file conflicts
echo "Conflicts found in the following files:"
printf '%s\n' "${conflicted_files[@]}"
Make a temporary copy of your working copy, then merge into that, and diff the two.