Photo by veeterzy on Unsplash

Speed Up Your Git Workflow

Antoine Ghilissen
4 min readDec 2, 2020


Git is a lot of things. But one of the things I like the most about it is that it can be so painful to use, it is funny (as long as I am not the victim). From the classic XKCD comic to the Git Koans, I find those very entertaining. Some are even useful: Oh Shit, Git!.

When I started using git, one of the things that were instrumental in my understanding were the visual representations of git commands. Articles such as this one and this one are good examples.

Do not get me wrong; I am far from being a git power-user! I use it to share my work with a small team of fellow data scientists, to back up my work, and as a project portfolio. I am nowhere near a software developer juggling between developing features, fixing bugs, and managing production code. I am, however, still literate enough to laugh at the websites listed above.

Do not worry. I am not writing this article to let you know I laugh at nerdy jokes. I have been using git regularly (almost daily this year), and I picked up a few tricks to stay away from all this git fuss. Hopefully, you will find some of these useful too.


The .gitignore file, as its name indicates, is a list of files git will not take track. It is the best way to stay organised, particularly because I work with Jupyter notebooks regularly (I do not wish to save the checkpoint folder), I also like to have a file hanging around in the project folder, as well as my virtual environment folder.

There are a few solutions around to generate this file, but I got used to using, and especially its command line interface. A quick gig keyword1,keyword2 >> .gitignore and it is all taken care of. In case of doubt about the keywords, I have a handy alias in my bashrc (see below). And for my and virtual environment folder: echo -e "\nVirtualEnvFolder" >> .gitignore

After creation, it will need to be added, committed and pushed just like any other file.

Another way to generate the .gitignore is to use the extra scripts from git-extras.

The git config Command (or the .gitconfig File)

Running git config --global will generate and "feed" the .gitconfig file.

The first encounter with this command is most likely when you configured git with git config --global "John Doe" and git config --global "". But there is a lot more to it, including a few options that can be enabled to make life a lot easier. Such as:

  • git config --global credential.helper cache --timeout=10 to cache your credentials for 10 seconds. Very handy to avoid entering your password 3 times during an SSH authentification!
  • git config --global help.autocorrect 10 to correct typos and run the reviewed version of the command after 1 second (the integer is in 10th of a second).
  • git config --global init.defaultBranch Main to change the default branch name to Main, for example (Master by default)
  • git config --global commit.template ./defaultcommitmessage.txt to use the defaultcommitmessage template every time you commit.
  • git config --global status to see the git status with git st instead of git status. If the autocorrect is activated, git corrects the aliases as well. You can even pipe external applications with !.
  • git config --global core.editor nano to change the default editor to nano, if you are not comfortable with vi.

To remove a parameter, either git config --global --unset help.autocorrect, or manually edit the ~/.gitconfig file.


As seen above, the.gitconfig file can manage aliases, and if managed by git, you will have access to the autocompletion of arguments as well. However, the .bashrc file can also be very convenient to manage those. I, for one, prefer the .bashrc way, and I have the following aliases setup:

These are aliases for relatively simple tasks, but they make using git a little more user friendly to use on a daily basis.


git rebase is a powerful command acting on the commits. With it, you can fix a typo in a commit message, split a commit (or merge commits), and it can also move commits between branches. Suffice to say it is a little overwhelming at first!

Thankfully articles like this one are very insightful. If on top of that, you use the “interactive” shell: git rebase -i, you should stay out of trouble!

Final thought

You probably feel like you suck at git… Do not worry. It is not you, it is git! It is one of these tools that takes a long time to master (if at all possible). As you can see from the many humorous articles about git, a lot is going on with the terrible user experience (Right now, I am thinking about the Hobgoblin).

Thankfully there is one last command that will save you every time: