Don’t Make These 3 Git Mistakes
Tags: Github, Git, Gitlab, Programming, Coding

Don’t Make These 3 Git Mistakes

Time and time again I noticed in tutorials people make “mistakes” when using Git. Surprisingly, as you can expect from them to know what they are doing. I also sometimes noticed senior developers do them, too.

These “mistakes” aren’t critical as they don’t break anything but they reveal that some developers, even seasoned ones, have a misconception of good practice when using Git. It’s probably because they have been accustomed doing so during the years and now have become a habit. Therefore it is important that you must avoid them to begin with, so it won’t become a habit for you.

In this article I’ll show to you common mistakes some senior developers make when using Git that you should not start making and I’ll also show you a better approach.

Photo by Vanna Phon on Unsplash

1. Using semicolon when chaining multiple Git commands

When people are executing multiple Git commands they sometimes use the ; to chain them in one line, e.g. git add .;git commit -m "some stuff"; git push . In most cases it works. But why it’s so bad?

The issue with using ; is that once one of the Git commands fails, all the subsequent commands will be executed no matter what. As you can imagine this can lead to undesirable effects if a Git command relies on the correct results of the previous Git commands.

A more secure way is either to execute every single Git command one by one. But a better way would be to use && instead of ; . What the && will do is that it only executes the next Git command if the previous one is executed correctly. This is also known as short circuit and basically works like an if-case: If, and only if, a Git command is executed correctly, the next Git command will be executed. Otherwise it will skip all subsequent Git commands all together.

2. Using git push -f

Using git push -f or git push --force is pretty common in some companies. Sometimes it is even required to force push a commit, e.g. after git commit --amend or after git rebase . So, if it is required, then why is it bad?

First of all it is best to use git push -f resp. git push --force only on a branch with you alone as the sole author. Otherwise it can lead to synchronization issues. Because force push means you are pushing no matter what — even if you are overwriting someone else’s commit.

In most of the cases, a better choice would be git push --force-with-lease . This ensures the commit is pushed only when you are the last one to commit.

The only option when git push --force is preferable to git push --force-with-lease is when you deliberately want to overwrite another person’s commit.

3. Using aliases too often

I don’t advice against using aliases. I use aliases myself to save myself time. I’ve seen lots of seniors who use aliases all the time and are super productive. Kudos to them. So why is it so bad?

The issue is, aliases are only local. Once you move to another working environment, e.g. you get a different computer, your current computer is broken and you have to use a brand new machine, or you change employer you can’t use the aliases anymore, because they are stored on your local machine.

Some developers have memorized only the aliases by muscle memory and are clueless once their machine is broken and have to work on a new machine where there are no Git aliases. It’s like they have become junior developers again without their aliases.

The most secure way is to use the original Git commands. If you still want to use aliases, I’d recommend you to create a Git cheatsheet on an online Git repository like GitHub, GitLab, BitBucket, etc. This way you can pull from that once you have to switch your machine.