selbekk

Before I dive into this, I just want to say - there are a lot of ways to work with Git. Whatever you do might work for you, and if it does, I'm happy for you 🥰. This article is going to share my particular workflow when dealing with version control. Perhaps you'll find a few tips or tricks you haven't seen before?

I love working with git in the terminal. I've understood there are some really neat GUI tools now that probably makes this much easier, but I learned git from the terminal, and by God I'll stay in the terminal.

This article will show you the aliases I use, how I tend to work on a feature, and a neat little tool for dealing with GitHub at the end.

Aliases

If you're not familiar, aliases are basically shortcuts you can specify in your terminal configuration file (.bashrc, .zshrc or .bash_profile are all typical names of this file). For Git, you can even specify them in the .gitconfig file.

To open your Git config file, navigate to your home folder, and open .gitconfig in your favorite editor. It'll look something like this:

[user]
	email = selbeezy@gmail.com
	name = Kristofer Giltvedt Selbekk
[push]
	default = "current"
[init]
	defaultBranch = main

It might even be empty, based on your setup.

To add aliases, you could add a [alias] section. To create a shortcut for committing, for example, you could add the following:

[alias]
	cm = "commit"

Now, if you write git cm -m "Some commit message", it will work just the same as git commit -m "Some commit message". Neat-o!

I have set up quite a few aliases to handle my workflow. Here are the ones I use the most:

• git cob new-branch - Same as git checkout -b. Checks out a new branch.
• git diffs - Same as git diff --staged. Shows the code that has been staged (added with git add).
• git rull - Same as git pull --rebase. Great for when you have commited something to your branch before fetching the remote changes to it.
• git cman - Same as git commit --amend --no-edit. Great for when you have forgotten to remove a console log or whatever, and just want to add any staged changes to the last commit without changing the commit message.
• git fush - Same as git push --force. Great for when you pushed before using git cman 😅

I know there are tons of hour long articles out there that give you lots more of these if you're interested. These are, however, the ones I use every day.

Workflow

So you now know my aliases. But how do I use them?

Getting ready to work

First, I start a feature by checking out the main branch, and fetching any remote changes.

$ git co main
$ git pull

Next, I check out a new branch. Some projects have strict guidelines on what to call your branches, but if I don't have any guidelines, I tend to just use a short, yet descriptive phrase.

$ git cob add-ghost-button-variant

Staging and commiting my work

Now, the hard part – coding. For brevity's sake, I'm just going to skip over that for now, and assume I did everything perfectly.

While some people add a tiny bit of code, and then stage and commit it, I tend to write entire features in one go before commiting anything.

Since I do work like that, I often need to stage code by the file. So instead of using git add ., I tend to use git add src/my-file.js, for example.

If I want my commits to only include a certain part of a file, I can use the git add -p flag. This lets me add parts of a file (even down to single lines) at a time, which makes it easy to stage the correct parts at a time.

$ git add -p package.json

Alrighty, commit time! Let's commit my code. I typically just use the -m flag, and write however many lines I need. Lots of people doesn't know this is even an option!

Often, you don't need to add comments to your code in order to explain it - especially when it's a comment explaining why it was changed. Instead, use the commit history as your documentation source, by adding a few paragraphs about the changeset and why it was done a particular way.

$ git cm -m "Add a ghost variant 👻

This commit adds a ghost variant of buttons. It was discovered as a variant we need inside of input fields, like when you want to create a password input with a \"reveal password\" button in it."

Oh, and pro tip - use some emojis! Emojis are fun and shows up in Github and changelogs.

Fixing my errors

Next up, I probaby added some more commits, before realizing I screwed up my first commit. Gah. Luckily, there's a flag called --fixup that helps us out. I stage the changes that fix my original commit, and then commit them with git cm --fixup. Finally, I use the rebase utility to automatically squash these commits into the original commit.

$ git cm --fixup hash-of-commit-i-want-to-fix
$ git rebase --auto-squash ^hash-of-commit-i-want-to-fix

The rebase command has a --auto-squash flag that automatically orders the fixup commits for us. Now, we can inspect the commit history with git log, and see that the fixup commit has disappeared. Just like magic!

Using the Github CLI to handle pull requests

Finally, it's time to have somebody review our code. Let's push our new branch up to GitHub!

$ git push

Now, I'd typically have to exit my terminal, open my browser, navigate to my repo and branch, create a pull request, and fill out any details.

What if… you could do all of that from the terminal as well? Meet the GitHub CLI tool - gh.

If you're on a mac, you can install it with brew install gh. If you're using Linux or Windows, you can look up your own installation guide in the official docs.

Once it's installed, you can log in with gh auth login, and follow the instructions.

Now, we're ready to create our pull request! All it takes is three words:

$ gh pr create

This starts an interactive guide that lets you fill in a title, description and any metadata you want. This is basically the last thing I do before I start a new feature, or review other pull requests.

…And that's my terminal workflow for Git!

I hope this taught you a few new tricks, and if not, at least taught you how I do things. 🤷‍♂️

If you have any tips of your own, let me know on Twitter!