Git Aliases for Merging Branches

Every Git repository has a master branch that acts as the primary branch. Some version-control programs call this the ‘trunk’. Technically you can rename the master branch in Git, or have multiple unrelated orphan ‘master’ branches if you want—but I am not getting into all of that.

Instead, today I simply want to share two aliases I use for merging branches into master and why I use them. I will assume you are familiar with the general concept of ‘branching’ in version-control software.

To Fast-Forward or Not

When merging a branch Git will try to ‘fast-forward’ the merge by default. Vincent Driessen provides a nice illustration of the difference between Git’s default, fast-forward behavior (on the right) and performing a non-fast-forward merge (on the left). He describes an interesting workflow that avoids fast-forward merges, but that is beyond the scope of what I want to discuss. I just wanted to point you to his writing to help provide a visualization of fast-forwarding.

Personally I will sometimes perform fast-forward merges, and other times I will avoid them. I use two aliases for this.

git master-collapse

Alias Definition: git checkout master && git merge --ff-only @{-1} && git branch -d @{-1}

I use this alias when I am on a branch that I want to fast-forward merge into master. The name ‘collapse’ comes from the fact that it deletes the history of that branch, making it appear as if all of those commits were part of the master branch from the start. I have the habit of always creating a new branch before changing any code. However, not every branch I make feels like it carries enough specificity to be worth remembering in the repository history, e.g. a branch with three small commits fixing three unrelated bugs. I prefer to ‘collapse’ branches like that into master.

git master-attach

Alias Definition: git checkout master && git merge --no-ff @{-1} && git branch -d @{-1}

The only difference between this alias and the previous is the option given to git-merge. This alias forces the creation of a merge commit, even when a fast-forward would be possible. I like to use this for branches representing distinct features because it maintains a history of exactly when development of said feature forked away from the master branch, as well as when I ‘attach’ the completed feature back to master. This approach is particularly useful for projects where I am tracking and merging branches from multiple developers. Vincent Driessen’s above-mentioned article provides great insight into how this approach can be beneficial.

In conclusion, there is nothing particularly special or ground-breaking about these two aliases. They are merely shortcuts for well-established techniques in branch management that I often see in Git repositories. Hopefully some of you may find them useful.

Advertisements

Add Your Thoughts

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s