I’ve been with Axosoft for almost two years now, and when I started, GitKraken, the company’s Git GUI, was so new it was still in private beta. Working for the marketing team, primarily on web projects, I needed to work collaboratively and use Git on a daily basis.

I had worked with Git before, but prior to Axosoft, I was a web team of one, meaning I rarely, if ever, had to collaborate with other developers on projects. As such, the extent of my Git knowledge was git status, git commit, and, when feeling saucy:

git commit -a -m 'look at me condensing my actions into one command like a big boy.'

It’s timely that as I write this, I’ve just finished reading a blog article by Avdi Grimm (that references GitKraken, as it happens), in which he makes a point I had never really considered:

One of the difficult, and at times disheartening lessons I’ve learned over the years is that there is a fine line in software between skills that actually increase your leverage, versus the ones which just make you feel smarter.

– Avdi Grimm, Having the appearance of good design

Git from the command line, for me, achieves the latter; when using the CLI for Git, I could perform simple commands that made me feel like I was doing something powerful, and maybe I was doing something powerful, but the truth is, I didn’t really know what I was doing. I understood some basics, but I did not, at all, have a sound conceptual grasp of anything outside of those simple commands. Reading up on Git piqued my interest enough to dive further in, but I hit a roadblock, and it started to feel unlearnable.

When I started with Axosoft, we were asked to use GitKraken because a) Axosoft believes in the product and in how strongly it performs (and did even in those early stages of the app’s development); and b) Axosoft wanted devs across the company to put the app through its paces and identify bugs, UX issues, etc.

So, I used GitKraken, and I used Git—truly collaboratively—for the first time. And I started to not only get used to performing tasks quickly, but to actually start making sense of how those tasks were working. Processes were simpler, I was far more productive, and I finally had a visual representation of Git that I felt I could understand.

Merging vs Rebasing

A good example of this, and one of my most satisfying ‘ah-ha!’ moments, is with merging and rebasing. Merging is a pretty straightforward concept to understand: you take a branch, merge into another branch, and that target branch now has the changes of both. What I didn’t understand until I could actually see the process, was that this is facilitated by a merge commit. To understand why this is useful in a collaborative environment, it’s probably best to explain with an example.

In the example setup below, I have a branch and I have master. This setup exemplifies a common situation: I have branched off master, made some changes, but have not finished working on the branch. Meanwhile, master has changed, and those changes are ones I’d find useful to have in my branch.

I have two options: I can merge master into branch-from-master, or I can rebase branch-from-master onto master. The former is entirely non-destructive and leaves a footprint of the process:

However, it’s easy to see how keeping things clean could become difficult when applying this method frequently, while lots of updates are happening around you. In order to avoid this potential conceptual spaghetti of merge commits, a friend recommended I rebase instead.

Whoa! I can actually see the difference, and it makes sense! The changes in master have been slotted into branch-from-master, as if my changes in that branch, and in master, were conducted on my one branch. master still has its commits intact, but it’s as if those commits were conducted on both branches at the same time.

Although this loses the footprint of merging, it keeps everyone’s repos looking clean, with histories that are easier to traverse and interpret. We have literally rewritten the commit history.

This is why, when it’s time to push my branch, it tells me I’m behind the remote. I could see how I had rewritten the history of that branch, so I could understand why a force push to my remote was acceptable under these circumstances. I want to reflect the history revision there, too, so I have to get just a little destructive. However, I can now also understand why there is the Golden Rule of Rebasing.

Using GitKraken has provided me with a visual way to learn some Git fundamentals that have made me more competent and confident with using Git collaboratively. Using a GUI for Git has allowed me to take the step from knowing how and when to do something, to knowing why and what it’s actually doing.