Advanced GIT — Merge, History & Diffs

Merge seems to be a very simple topic, but it on first glance. We’ll learn what’s difference between ^ and ~ in GIT and uncover the full potential of the GIT log. This article continuous series of “Advanced GIT”. We’ve already talked about References, Git code store areas and what’s git. Let’s continue our journey 🏇.

Merge commits are just commits

ℹ️: Make notice that this commit has 2 parents

Merge commit

Fast forward

Fast forward occurs when there are no commits on the base branch after the feature branch was created.

fast forward commit

No fast forward

git merge --no-ff — will force a merge commit, even when one isn’t necessary

force merge commit

Merge conflicts

Merge conflicts occur when you try to merge, but files have significantly changed. GIT will wait until conflicts are resolved

Merge conflict

GIT RERERE — Reuse Recorded Resolution

GIT can remember how you solved the previous merge conflict and in the next commit reuse the same resolution.

Useful for long-lived branches (like refactoring) or rebasing.

How to enable it:

git config rerere.enabled true
add --global flag to enable in all projects

Example:

When we’ve committed conflict resolution, GIT has recorded it.

Now, let’s undid merge and try again.

The resolution is automatically applied.

History & Diffs

XKCD Bad commits

Good commits are important

Informative commits help preserve the history of code

When they’re helpful:

debugging & troubleshooting
creating release notes
code reviews
rolling back
associating the code with an issue or ticket

Rules of a good commit message

commit message is in the future tense fix
Short subject followed by a blank line

A description of the current behaviour, and a summary of why the fix is needed. Don’t forget to warn of the side effects.

informative commit message
encapsulates one logical idea
Doesn’t introduce breaking changes (tests should pass)

GIT Log

git log — the basic command that shows you the history of your repository

“Why my app is slow? It has been working since yesterday” — typical situation at the workplace

Typical usage:

git log --since="yesterday"
git log --since="2 weeks ago"
git log --name-status --follow -- <file> — log files that have been renamed or moved
git log --grep <regexp> — Search for commit messages that match a regular expression

ℹ️: You can combine different flags:

GIT log diff-filter

Selectively include or exclude files that have been:

A — added
D — deleted
M — modified
and more

Referencing commits

^ or ^n :

^= ^1 : the first parent commit
^n : the n-th parent commit

~ or ~n :

~ = ~1 : the first commit back, following 1st parent
~n : number of commits back, following only 1st parent

ℹ️: ^ and ~ can be combined

commit reference example

Preface:

B and C are parents of node A
Parents are ordered left-right
A is the latest commit

Then we have the following equality:

GIT show — look at the commit

git show <commit> — show commit and contents
git show <commit> --stat — show file changed in the commit
git show <commit>:<file> — look at the file from the commit

Diff

shows you change between:

commits
staging area and repository
what’s in the working area

git diff — unstaged changes

git diff --staged — staged changes

Diff commits and branches

Diff branches

git branch --merged master — Which branches are merged with the master, and can be removed?

git branch --no-merged master — Which branches aren’t merged with the master yet?

In this article, we’ve looked at merging in deep, discussed “good” commits, and how we can reference commits. Next time we will talk about how we can fix mistakes. Subscribe to not miss any new updates.