Is there a git-merge --dry-run option?

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

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:

Fetch the remote to your repository. For example: git fetch origin master Run git merge-base: git merge-base FETCH_HEAD master Run git merge-tree: 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.

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.

You can do git merge --abort after seeing that there are conflicts.

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

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. Merge pre-master into master OR Merge all wannabe-released branches into master

Anyway, I would follow @orange80's advice.

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)

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

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 -pparameter, you will also get the full patch text, exactly like if you were doing a git diff on every changed file.

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 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).

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.

Make a temporary copy of your working copy, then merge into that, and diff the two.

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.