A computer screen displays a terminal with the command prompt and the text "sudo" being typed.

My Git Workflow

• 4 min read • Tech

Git recently turned 20. I’ve been using it for almost half that, and while it was pretty confusing at first, it’s since become second nature.

This post is far from a comprehensive tutorial — it’s just a few helpful habits, aliases, and tips that have made it a bit easier to work with Git day-to-day. Some are things I picked up from pairing with excellent devs at work, while others are things I’ve stumbled upon from messing around over the years.

Hero image by Gabriel Heinzer on Unsplash. sudo is a great fallback command that I’ve used many times over the years.1

Version Control 101

Back in college, my project folders went something like this:

my-project-final
my-project-final-FINAL
my-project-final-FINAL-v2
my-project-final-FINAL-v2-UPDATED
Look familiar?

Version control (like Git) is a way of freeing you from this chaos. It tracks changes to your code, lets you collaborate with others, and gives you the freedom to experiment without fear of losing work. A good intro to the core concepts can be found at GeeksForGeeks.

It was created by the legendary Linus Torvalds in 2005, to help manage development of the Linux kernel — a large, complex, and distributed project. Since then, it’s been adopted by developers everywhere.

Branching & Naming Conventions

I usually start each branch name with the relevant issue number, e.g. 45-fix-lazy-loading.

Having the number in the branch name makes the pull requests2 easier to track, and know what issue it’s associated with. It can be especially useful on larger issues that are broken into multiple PRs.

Git Aliases

I use Oh My Zsh to manage my terminal. It comes with a great Git plugin that provides tons of helpful aliases, way more than I could ever manage to remember, and things in Git I don’t dare ever attempt! But here are a few I use regularly:

AliasCommandUse Case
gcmgit checkout $(git_main_branch)Quickly switch to the main branch
glgit pullPull latest changes — usually after merging a PR
gcogit checkout

Switch to a branch — e.g. gco 45-fix-lazy-loading

gcbgit checkout -b

Create a new branch — e.g. gcb 46-revert-fix-lazy-loading

💡 Yes, that “revert fix” branch name is a joke.

Custom Aliases

You can define your own Git aliases in your .gitconfig under [alias]. Here are two I find very handy:

git open

At Shopify, we had a great command that opened the current branch as a draft PR on GitHub. Among the myriad of git aliases, there didn’t seem to be any for this, so I recreated something similar (with the help of ChatGPT):

[alias]
    open = "!f() { \
        REPO_URL=$(git remote get-url origin); \
        REPO_URL=$(echo \"$REPO_URL\" | sed 's/.*github.com[/:]\\([^/]*\\)\\/\\([^\\.]*\\).*/github.com\\/\\1\\/\\2/'); \
        BRANCH=$(git rev-parse --abbrev-ref HEAD); \
        open \"https://$REPO_URL/compare/main...$BRANCH?quick_pull=1\"; \
    }; f"

Just taking it for granted that this works. Writing that kind of regex myself? 🫠

git rup

My usual flow is as follows:

  1. git add .
  2. git commit -m "Description of change"
  3. git push origin branch-name
  4. Open GitHub to make a PR.

So I thought, why not combine this all into a one-liner, and thus git rup was born, which:

  • Adds and commits all current changes with a message
  • Pushes the branch to origin
  • Opens the PR page on GitHub comparing with main

Example usage: git rup "Update image handling"

[alias]
    rup = "!f() { \
        git add . && git commit -m \"$1\" && \
        git push --set-upstream origin $(git rev-parse --abbrev-ref HEAD) && \
        REPO_URL=$(git remote get-url origin); \
        REPO_URL=$(echo \"$REPO_URL\" | sed 's/.*github.com[/:]\\([^/]*\\)\\/\\([^\\.]*\\).*/github.com\\/\\1\\/\\2/'); \
        BRANCH=$(git rev-parse --abbrev-ref HEAD); \
        open \"https://$REPO_URL/compare/main...$BRANCH?quick_pull=1\"; \
    }; f"

Why rup? Ah, it’s a Sligo thing.

Commit Messages

On a team, I of course write proper detailed commit messages and PR descriptions. But when working solo, I keep things simple. Mostly it’s just a standalone feature with a single commit so the branch and PR title are descriptive enough. In these cases I just write “Ronseal” in the PR description.

Why Ronseal? It does exactly what it says on the tin.

Wrap-Up

There’s nothing too fancy here — just a few habits and workflow tips accumulated over the years that have helped me, and hopefully help someone reading this one day.

I have a companion piece to this which looks at the Github side of things over at GitHub Tips And Tricks.

Footnotes

  1. sudo stands for “superuser do.” It gives you elevated permissions to run commands that regular users can’t. If a command doesn’t work in terminal, often running sudo <command> does the trick. It’s powerful, but risky! ↩

  2. A pull request (PR) is how you propose changes to a project in GitHub. The name is a bit confusing as you’re actually pushing your changes to a shared repo and asking others to “pull them in” (hence, pull request). ↩

Related Posts

Contents