How can I effectively review an existing git merge?

Question

I would like to review git merge commits, for merges that have already been done and pushed to the server.

My team has had a couple times recently when work was (temporarily) lost from a bad merge. Its not clear if we are executing the merge incorrectly, or if we are making bad conflict-resolution fixes during the merge. I'd like to take a close look at our team merges for a little while, to make sure everything is copacetic; but I don't know to use git or associated tools to do this effectively.

The closest I've come is the 'gitk' tool. When I look at a merge node in that tool, the diff view seems to show the desired information, but I find it extremely difficult to quickly understand whether a particular chunk of merge result came from parent A, parent B, or from a conflict-resolution fix. (Is that called a patch?)

I own a copy of Beyond Compare, which has a merge presentation mode, but when I set it up with 'git mergetool' it seems to only want to process a current merge - I don't know how to feed it one out of the git history.

Please tell me how to more effectively use the tools I have, and/or what other tools I could use to make these reviews manageable.

Answer 1

You can diff the merge against either parent:

git diff <1st-parent-hash> <merge-commit-hash>
git diff <2nd-parent-hash> <merge-commit-hash>

Or use the 1st/2nd parent syntax. If the merge commit is abc123:

git diff abc123^1 abc123
git diff abc123^2 abc123

Answer 2

I hear Tower is pretty good.

You can use github's compare capability to compare between commits, tags or even branches. As seen on GitHub

Compare View URLs

We wanted Compare View to be something we could link to from external sites and services anytime we were referring to a range of commits in a git repository. As such, we thought it would be worthwhile to document the basic structure of a Compare View URL:

    http://github.com/<USER>/<REPO>/compare/[<START>...]<END>

Where <USER> and <REPO> are obvious, and <START> and <END> are branch names, tag names, or commit SHA1s specifying the range of history to compare. If <START> is omitted, the repository's default branch is assumed

As for a more effective branching methodology, I'd recommend using this. Worked in a couple of startups I've been with --> http://nvie.com/posts/a-successful-git-branching-model/