I’ve been working as a software developer since 2008. In 2014 I was lucky enough to get involved with a team who used Git in a way that really made sense to me. It made collaboration easy and improved overall quality of both product and developers.

Since then I have introduced it to a fair number of people, but I have still not come across a site or blog that mirrors my thoughts well enough. So for my next on-boarding of new team members, I decided to get it down on “paper”.

The following assumes you’ve got some basic knowledge of Git though. Otherwise I think it may be best to finish reading my intro, go through a Git Basics tutorial and then come back here to read on!

Command line… or not?⌗

My first meeting with Git was actually a workshop where the organizer took a head dive straight into the git internals. While interesting, it did little to actually teach me how to work with Git. Neither have I ever really needed that insight. To me it’s like not having to know assembler to be able to write programs.

The Git tutorials I have come across usually starts by introducing the command line. Something like this:

git init
touch some-new-file.txt
git add .
git commit -m "Added my first file, yey!"

And then they go on with different git commands to create branches, merge, push, pull, stash, etc. Maybe rebase is mentioned, but I’m usually told pretty quickly that that is an advanced topic so best leave it for now. I don’t think focusing solely on the command line is a good approach to learning Git.

Let’s talk about GUI instead⌗

For many people that’s like swearing in church and I don’t see why. In fact, let me present my GUI of choice: GitExtensions.

In my opinion, the greatest feature is the commit dialog:

Git Extensions Commit Dialog

Maybe not very sexy, but it’s straight to the point. (numbers explained further below)

The main benefit is that it let’s me easily switch between files, review my changes and stage only parts of the file! I can even reset those pesky changes I didn’t really mean to do (or maybe better, I can actually discover those changes instead of committing them unknowingly).

Sometimes I meet developers who say they know Git and use it everyday. Great I think… only to discover that it was only half a truth. They were really just using Git as backup tool. A place to put their code by the end of the day. Sorry, but that’s just wrong.

I blame the “command line git tutorials” that tells us the way to go is this:

git add .
git commit -m "Got shit done. Lunch time..."

One of my motivations for writing this post is to show that there’s an alternative.

In the commit dialog above I’ve marked with numbers 1-7 the different changes that I made (yes, it’s not code, but who says Git can’t be used for other things?).

Here’s what I would do with them:

  1. Trailing white space. Reset the change.
  2. Typo, stage line.
  3. Typo, stage line and make a new commit including the typo in 2.
  4. Accidentally deleted a word. Reset.
  5. Stage the hunk and commit it.
  6. Too many blank lines, reset some of them.
  7. Stage the hunk and commit it.

Commit Dialog Gif

Please don’t tell me “git add –patch notes/how-i-git-it.txt” is easier.

I use this dialog continuously throughout the day to review my changes, and to make commits that can later be moved, squashed, reset, etc (I recommend Seth Robertson - On Sausage Making. It’s a quick read.).

“Okay, so that’s possible, but it seems like a lot of work. This doesn’t really play nice with how I develop.

I’ve been mentoring quite a few people with Git and code review practices, and sometimes I get that feedback.

The two main arguments against how I do things are these:

  1. It’s slow going.
  2. It’s nitpicking.

And yeah, I actually agree. It will slow you down and it is nitpicking until you get it right. I had those same feelings back when I was learning the fundamentals of Git and having other developers review my code. I didn’t like it much at first, mainly because it was something new that I wasn’t used to. But me being new in the team, I really had no choice but to learn. So that’s what I did, and I am so grateful for that today. Going slow and steady I produce less bugs and regressions, and with a team who’s also doing it like this, I spend less time doing code review than I otherwise would have.

There are many more benefits, but I want to try keep this post more on the how and not the why.

For the next part of How I Git It, let’s talk about Rebase.