5 Git mistakes I made as a junior developer

1. Relying heavily on either the Terminal or GUI

It seems that most developers are pretty polar when it comes to deciding whether a GUI or the terminal is better to use with Git. I found myself to be of the type of developer who always wanted to use the terminal. The truth is that it's not really so one-sided, neither is it necessarily superior in all situations. Of course, the terminal is generally a lot faster than clicking through a GUI, but also a lot more prone to error (as I would find out). I found that the best way is to familiarise yourself with the visual monitoring features of your IDE (quickly viewing what changes have been made in this commit, etc.) and then use the terminal to manage your commits and branches.

2. Using shortcuts and aliases too often

Shortcuts and aliasing (replacing several or longer commands with custom shortcuts) are helpful, but they can lead to unwanted side effects. The git add . command has been one of the biggest culprits for me, often adding a lot of unwanted files to the commit without the user even noticing.

As I already shared in my git aliasing blogpost, using shortcuts for some of the more common workflows is a pretty useful feature that can save a lot of time. Unfortunately, it can be a pain when you are so accustomed to their convenience that you start using them even when it’s not appropriate. Aliases that do too much can be especially annoying, causing you to execute unwanted actions that are harder to reverse.

3. Commiting irrelevant changes

Do you often look at a file and think, "Hmmm, this line break is really messing up the aesthetics of the file. Maybe I should remove it"? Most do. Unfortunately, this can lead to a pretty overwhelming changelog in the code review. I generally suggest only making formatting changes (or any changes for that matter) on the files that are directly linked to the task that you are working on. Another common unwanted change is to have unused imports at the top of the file

The best way to avoid these sorts of changes creeping into your commits is to use an effective GUI tool to monitor and spot these quickly. I also suggest getting into the habit of double-checking before you commit and push!

4. Forgetting to check out the master branch before creating a new branch

Forgetting to check out the master branch before creating a new branch is a mistake that I made surprisingly often, and that was almost always very annoying. The problem with this is that if the branch that your now current branch is based on was already merged with the master branch, you are going to need to undo almost all the changes from the old branch that did not make it into the master. This is because all the old changes from the base branch will appear as new changes in combination with the changes that are actually new.

The lesson: never make branches from a branch that is not the master, unless you are deliberately doing it (for example, to test out a quick alternative implementation of a feature)!

5. Doing a hard Reset

We always hear that this is something that shouldn't be done, but for personal projects, it's rare that I don't end up falling back on a hard reset once I messed up. It's important to realize that this should not be done lightheartedly in a professional setting.

A hard reset can undo a lot of changes that another colleague may have made on a given branch - I got a big slap on the wrist for this one! If you find yourself stuck and wanting to hit the restart switch, try and see if you can’t just revert everything or ask a more experienced developer to help you out.