Git: Learn Interactive Commands

Alan McKenna — Wed, 15 Sep 2021 13:50:26 +0000

You probably started out using Git in the command line. That's great! But unfortunately it's common, and understandable, for people to then move straight to a GUI version of Git, such as one of the many VSCode Git extensions.

I did something similar when I first started collaborating with Git, but if I had just stuck it out with the command line I would've learned much more rapidly.

Why Use Command Line?

First Principles

Okay, I'm not saying Git GUIs are bad, they're the opposite in fact. I use them all the time nowadays for certain tasks, mainly visualising complex tree structures.

What I am saying is, if you're wanting to get the most out of Git and fully understand it, you should learn it through the command line first.

Interactive Add

Clean Up Your Commits

This is really useful when I've been writing a feature and I've maybe also updated other things along the way that I don't want to include in the same commit e.g. fixing tests, refactoring other classes etc.

This allows you to see the state of all changes and provides all the options you can use.

$ git add -i
           staged     unstaged path
  1:    unchanged        +2/-0 README.md

*** Commands ***
  1: status   2: update   3: revert   4: add untracked
  5: patch    6: diff     7: quit     8: help
What now>

We can then selectively stage specific files using the add or patch option options.

The add option stages all changes in the file, the patch option goes through all the different hunks (changes grouped together) within the file and allows you to optionally stage each hunk.

           staged     unstaged path
  1:    unchanged        +2/-0 README.md
Patch update>> 1
           staged     unstaged path
* 1:    unchanged        +2/-0 README.md
Patch update>> 
diff --git a/README.md b/README.md
index 48bee75..6056e4a 100644
--- a/README.md
+++ b/README.md
@@ -20,3 +20,5 @@ $ login --store=https://dev-mimir.com
 $ populate products
 $ node serve
+
+some change
(1/1) Stage this hunk [y,n,q,a,d,e,?]?

Interactive Rebase

Clean Up Your Branch

Okay this is my favourite Git command, it's saved my bacon more times than I can remember now. When in doubt, interactive rebase.

So when I'm working on my local branch I tend to make a lot of messy commits, sometimes they'll be in an order that don't really make sense that might cause issues down the line if we ever want to rollback, they include things that they really shouldn't, they're poorly described etc.

Before I push up to my remote branch I usually have to do an interactive rebase to clean up my branch.

$ git rebase -i HEAD~4
 pick a204433 refactor: rename TicketBoard
 pick 72ceae8 refactor: generic support tickets table
 pick ba2925d refactor: organise React folder components/services
 pick 95023db feat(wip): added TicketBoard placeholder services

 # Rebase 9c24617..95023db onto 95023db (4 commands)
 #
 # Commands:
 # p, pick <commit> = use commit
 # r, reword <commit> = use commit, but edit the commit message
 # e, edit <commit> = use commit, but stop for amending
 # s, squash <commit> = use commit, but meld into previous commit
 # f, fixup <commit> = like "squash", but discard this commit's log message
 # x, exec <command> = run command (the rest of the line) using shell
 # b, break = stop here (continue rebase later with 'git rebase --continue')
 # d, drop <commit> = remove commit
 # l, label <label> = label current HEAD with a name
 # t, reset <label> = reset HEAD to a label
 # m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
 # .       create a merge commit using the original merge commit's
 # .       message (or the oneline, if no original merge commit was
 # .       specified). Use -c <commit> to reword the commit message.
 #
 # These lines can be re-ordered; they are executed from top to bottom.
 #
 # If you remove a line here THAT COMMIT WILL BE LOST.
 #
 # However, if you remove everything, the rebase will be aborted.
 #
 # Note that empty commits are commented out

Look at all the helpful documentation that you're given with this command, you practically don't even need to remember what anything does because it's all right there.

So, if I wanted to squash the first and last two commits together, that's easy to do. I just need to follow the docs and re-order the commits and change from pick to squash

$ git rebase -i HEAD~4
 pick ba2925d refactor: organise React folder components/services
 pick 95023db feat(wip): added TicketBoard placeholder services
 squash a204433 refactor: rename TicketBoard
 squash 72ceae8 refactor: generic support tickets table

Conclusion

I hope this post has highlighted that you don't need much to get a lot out of Git. Just these few commands can give you a lot of flexibility and control, which is often something that I find lacking in some Git GUIs.

Git: Commit Messages

Alan McKenna — Tue, 14 Sep 2021 12:38:31 +0000

When I first started out with Git I was told I could save time by just using the -m flag to write the commit message at the same time. "Amazing!" I thought, "I've just saved 2 seconds. 10x Dev here I come"

Context is King

Now I realise that I was missing the opportunity to add valuable context to my commit messages. This extra context makes it easier to understand what's changed and why, which has two main advantages:

You don't have to rely on memory
Your team don't have to rely on your memory

Imagine there is an issue with the number of active Gatling users, so you want to work out why the active users were changed. What commit message is clearer?

Gatling active users fixed

Or this?

fix(load-test): Gatling active users

This change seeks to fix the active user and request rate currently in place for load-test.

Removing the ObtainAccessTokenDuringTest scenario from the simulation flattens the active users during test, as this was not working as intended.

Additionally the access token should live for 60 minutes, eliminating the need for obtaining a new one during load tests < 60 minutes.

The first commit message only tells you what has changed, which really should be obvious from your code change anyway.

Whereas the second commit message tells you what & why. The why is the context and is not always obvious from the code change.

I like to follow the rule of concise commit message headers and detailed descriptions. People should be able to glance at it and have a rough idea of what it is about without going into the full description. But importantly the detail is there if required.

Following Standards

You can take this a step further by also working to a commit message standard in your team/organisation. An example that I use is a variation of Conventional Commits.

With this standard in place you can also then use Git Hooks to automatically validate your commit messages, or use something like the GitHub Action action-commit-lint to do this.

Why?

A shared understanding of what a good commit message should looks like

A shared understanding is great because that makes reviewing other people's Pull Requests (PRs) much easier. Additionally it makes it easier to help others improve their commits during review by having something to point to.

PRs are not just about reviewing source code, the commit messages are also important for the reasons I mentioned previously.

Automate Changelogs

One of the biggest benefits I've found with following a standard is that it allows you to automate Changelog creation. This helps to reduce the number of tasks required for the person doing the release and makes sure the Changelog is always the same format.

Features

feat: some cool feature

!feat: this is a breaking change

Fixes

fix(api): fix some bug

Other

refactor: make class more readable

chore(deps): bump X version

docs: improve README.md

Conclusion

Yes, commit messages aren't the most sexy topic in software engineering, but I think they are an overlooked and important aspect of healthy collaboration.

Half of our job is reviewing other people's code, and I always have much more respect for that person if they have clean and well described commits. It's one of the differences between a Junior and a Senior.

If your team doesn't already follow a commit standard then why not suggest it and implement validation? It's such an easy change and can really improve your code health.

DEV Community: Alan McKenna

Git: Learn Interactive Commands

Why Use Command Line?

First Principles

Interactive Add

Clean Up Your Commits

Interactive Rebase

Clean Up Your Branch

Conclusion

Git: Commit Messages

Context is King

Following Standards

Why?

Conclusion