How can I preview a merge in git?

I have a git branch (the mainline, for example) and I want to merge in another development branch. Or do I?

In order to decide whether I really want to merge this branch in, i’d like to see some sort of preview of what the merge will do. Preferably with the ability to see the list of commits that are being applied.

So far, the best I can come up with is merge --no-ff --no-commit, and then diff HEAD.

  • git reset HEAD before checking merge changes
  • Revert merge without rebase
  • Git diff3 file “deleted by us”
  • Git: What is the fastest way to merge a working branch to master?
  • Syncing 2 branches after git merge
  • GIT - how to merge branches?
  • Merge renamed folders in git
  • Git merge conflicts when no changes done
  • 10 Solutions collect form web for “How can I preview a merge in git?”

    I’ve found that the solution the works best for me is to just perform the merge and abort it if you don’t like the results. This particular syntax feels clean and simple to me. If you want to ensure you don’t mess up your current branch, or you’re just not ready to merge regardless of the existence of conflicts, simply create a new sub-branch off of it and merge that.

    Strategy 1: The safe way – merge off a temporary branch:

    git checkout mybranch
    git checkout -b mynew-temporary-branch
    git merge some-other-branch

    That way you can simply throw away the temporary branch if you just want to see what the conflicts are. You don’t need to bother “aborting” the merge, and you can go back to your work — simply checkout ‘mybranch’ again and you won’t have any merged code or merge conflicts in your branch.

    This is basically a dry-run.

    Strategy 2: When you definitely want to merge, but only if there aren’t conflicts

    git checkout mybranch
    git merge some-other-branch

    If git reports conflicts (and ONLY IF THERE ARE conflicts) you can then do:

    git merge --abort

    If the merge is successful, you cannot abort it (only reset).

    If you’re not ready to merge, use the safer way above.

    [EDIT: 2016-Nov – I swapped strategy 1 for 2, because it seems to be that most people are looking for “the safe way”. Strategy 2 is now more of a note that you can simply abort the merge if the merge has conflicts that you’re not ready to deal with. Keep in mind if reading comments!]

    • git log ..otherbranch
      • list of changes that will be merged into current branch.
    • git diff ...otherbranch
      • diff from common ancestor (merge base) to the head of what will be merged. Note the three dots.
    • gitk ...otherbranch
      • graphical representation of the branches since they were merged last time.

    Empty string implies HEAD, so that’s why just ..otherbranch instead of HEAD..otherbranch.

    The two vs. three dots have slightly different meaning for diff than for the commands that list revisions (log, gitk etc.). For log and others two dots (a..b) means everything that is in b but not a and three dots (a...b) means everything that is in only one of a or b. But diff works with two revisions and there the simpler case represented by two dots (a..b) is simple difference from a to b and three dots (a...b) mean difference between common ancestor and b (git diff $(git merge-base a b)..b).

    If you’re like me, you’re looking for equivalent to svn update -n. The following appears to do the trick. Note that make sure to do a git fetch first so that your local repo has the appropriate updates to compare against.

    $ git diff --name-status origin/master
    D       TableAudit/
    D       TableAudit/
    A       manbuild/staff_companies.sql

    Adding to the existing answers, an alias could be created to show the diff and/or log prior to a merge. Many answers omit the fetch to be done first before “previewing” the merge; this is an alias that combines these two steps into one (emulating something similar to mercurial’s hg incoming / outgoing)

    So, building on “git log ..otherbranch“, you can add the following to ~/.gitconfig :

        # fetch and show what would be merged (use option "-p" to see patch)
        incoming = "!git remote update -p; git log ..@{u}"

    For symmetry, the following alias can be used to show what is committed and would be pushed, prior to pushing:

        # what would be pushed (currently committed)
        outgoing = log @{u}..

    And then you can run “git incoming” to show a lot of changes, or “git incoming -p” to show the patch (i.e., the “diff”), “git incoming --pretty=oneline“, for a terse summary, etc. You may then (optionally) run “git pull” to actually merge. (Though, since you’ve already fetched, the merge could be done directly.)

    Likewise, “git outgoing” shows what would be pushed if you were to run “git push“.

    If you already fetched the changes, my favourite is:

    git log ...@{u}

    That needs git 1.7.x I believe though. The @{u} notation is a “shorthand” for the upstream branch so it’s a little more versatile than git log ...origin/master.

    Note: If you use zsh and the extended glog thing on, you likely have to do something like:

    git log ...@\{u\}

    git log currentbranch..otherbranch will give you the list of commits that will go into the current branch if you do a merge. The usual arguments to log which give details on the commits will give you more information.

    git diff currentbranch otherbranch will give you the diff between the two commits that will become one. This will be a diff that gives you everything that will get merged.

    Would these help?

    Maybe this can help you ?
    git-diff-tree – Compares the content and mode of blobs found via two tree objects

    Short of actually performing the merge in a throw away fashion (see Kasapo’s answer), there doesn’t seem to be a reliable way of seeing this.

    Having said that, here’s a method that comes marginally close:

    git log TARGET_BRANCH...SOURCE_BRANCH --cherry

    This gives a fair indication of which commits will make it into the merge. To see diffs, add -p. To see file names, add any of --raw, --stat, --name-only, --name-status.

    The problem with the git diff TARGET_BRANCH...SOURCE_BRANCH approach (see Jan Hudec’s answer) is, you’ll see diffs for changes already in your target branch if your source branch contains cross merges.

    I do not want to use the git merge command as the precursor to reviewing conflicting files. I don’t want to do a merge, I want to identify potential problems before I merge – problems that auto-merge might hide from me. The solution I have been searching for is how to have git spit out a list of files that have been changed in both branches that will be merged together in the future, relative to some common ancestor. Once I have that list, I can use other file comparison tools to scout things out further. I have searched multiple times, and I still haven’t found what I want in a native git command.

    Here is my workaround, in case it helps anyone else out there:

    In this scenario I have a branch called QA that has many changes in it since the last production release. Our last production release is tagged with “15.20.1”. I have another development branch called new_stuff that I want to merge into the QA branch. Both QA and new_stuff point to commits that “follow” (as reported by gitk) the 15.20.1 tag.

    git checkout QA
    git pull
    git diff 15.20.1 --name-only > QA_files
    git checkout new_stuff
    git pull
    git diff 15.20.1 --name-only > new_stuff_files
    comm -12 QA_files new_stuff_files

    Here are some discussions that hit on why I’m interested in targeting these specific files:

    How can I trust Git merge?

    Pull Request – I’ve used most of the already submitted ideas but one that I also often use is ( especially if its from another dev ) doing a Pull Request which gives a handy way to review all of the changes in a merge before it takes place. I know that is GitHub not git but it sure is handy.

    Git Baby is a git and github fan, let's start git clone.