5 Git Mistakes I made as Junior Developer


When starting at my new job, I felt pretty confident using Git – at least for the first week. It was not long until I realised that I had picked up a few habits that were not advantagous when working on larger projects and I decided to share some of these in this blog post.

Relying heavily on either the Terminal or GUI

It seems 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 that always wanted to use the terminal. The truth is that its not really so one-sided, neither is necessary 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 the best way is to familiarise yourself with the visual monitoring features of your IDE (viewing quickly what changes have been made this commit etc.) and then use the terminal to manage your commits and branches.

Using Shortcuts and Aliasing too often

Shortcuts and aliasing (aliasing here means replacing several or longer commands with custom shortcuts) are helpful, but can also lead to unwanted side effects. “git add .” 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 you 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.

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 at the code review. I generally suggest only making formating 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 sort of changes creeping into your commits is by using 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!

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

A mistake I made surprisingly often, but is 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 that 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 those changes that are actually new ones. 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)!

Doing a hard Reset

We always hear that this is something that shouldn’t be done, but for personal projects, its rare that I don’t end up falling back on a hard reset once I messed up. It’s important to realise that this should not be done lightheartedly in a professional setting. A hard reset can undo a lot of changes that another colleague has 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 experience developer to help you out.

Newsletter
Please enter a valid email!
Please agree to the terms!