How to get better at using Git at work
By: Edwin Silva
Tags: Beginner Coding, Self Improvement, Technology, Git, Development

Mistakes I made and things I’ve learned the hard way😭

Included a lot of redundant code in a Pull Request. Made way too many changes in a single Pull Request. Committing instead of stashing my changes. Creating a new branch from a feature branch

Redundant code in a Pull Request.

The redundant code in this case is everything, that isn’t necessary to finish a task. Some examples:

Debugging

Unused imports

Commented out code

Changes that have nothing to do with the task.

I mainly use Javascript & Typescript and use a lot of console logs, which I only use for testing purposes and shouldn’t be included in the repository. Furthermore, you may forget to remove the console log, and expose private data about others or make your software more vulnerable. So remove them before pushing your changes. The same applies to unused imports. If you are not using them, then don’t include them. If you are like me and use Javascript and Typescript, then a single line inside a tslint file can automate this.

tslint rules for checking for console.log and unused imports

Stop commenting out code, because you afraid to delete it in case you gonna need it in the future.

This may have been one of my biggest struggles until I realized, how easy it is to revert changes using git.

The last issue is about making changes that aren’t part of the task you are working on, this is bad practice. Imagine if your team needed to fix a mistake made because of some bug you introduces in one of your commits. The team can only see that you worked on tasks A, B, and C, which has nothing to do with the current bug the team is experiencing. If you had made a separate commit for your change, the team would have an easier time locating the bug in question.

Way too many changes in a single Pull Request

At the beginning of my career as a software developer, I kept working on the same branch and only made a pull request when I finished the task I was assigned to. This in itself isn’t a big problem, depending on the size and changes required to finish the task.

Imagine creating a large pull request that solves a lot of problems. You commit it and create a pull request. Your code gets a review, and everything looks fine on the surface, and your code passes the review. Then at some point later, a bug occurs on the master branch, which your code got merged into. The master branch is then reverted to the previous state and all the problems your commit has solved are now lost, even the parts which weren’t causing the mentioned bug. You could argue that it was the fault of the reviewer for approving the code, and likewise, you could also say that it was the fault of the developer creating the PR. Personally, I would put the blame apon myself, since I wrote the code, and I made the PR.

Had I made a smaller PR’s, then it would have been easier to understand the code I wrote. The impact would also be less, since I could just remove the commit, which caused the bug, instead of removing everything.

Committing instead of stashing my changes

I´m the type of person that can be working on multiple branches at the same time. Sometimes it´s to take a breather from a difficult task, other times because my current task requires a second task to be completed before it can be attended to. If are like me, and tend to switch between branches then you have definitely come across this git message:

error: Your local changes to the following files would be overwritten by checkout: path/to/file

Please commit your changes or stash them before you switch branches.

Aborting

And because these changes would be needed later, I always chose to make a commit that would have some non-informative message like “Work in progress”, since nothing was finished. In the end, I would have multiple commits, which would have nothing to do with the tasks. This would be a living hell to navigate through to determine what and when changes were introduced. Then I learned GIT STASH.

Instead of having to commit some half-done code, you can use the git stash command, to temporarily stash your uncommitted changes to storage on your local machine. When you need to retrieve the code, you can use git stash pop, to retrieve the stashed changes.

After I learned to use git stash instead of git commit on unfinished code, it has gotten a lot easier to read and navigate through the commit history of my projects, since I didn’t need to go through countless redundant commit messages.

Creating a new branch from a feature branch

This issue may be one of the most annoying ones to do. Usually, when I finished my task, I would create a new branch to begin solving my next one. The problem was, that I always created the new branch from the current branch I was working on. Normally this would not give me any issues, since I worked with smaller teams of 2–3 people, where everybody had dedicated and isolated tasks.

But as I began working with more people, it became an issue of merge conflicts. Imagine having created several new branches from a previous branch. All the new branches are now an identical copy of the previous branch you worked on, with the same modified files.

Then one of your team members creates a new pull request and merge it into master. If the new code contains changes to the same files as the ones you made a pull request for, then a lot of merge conflicts could occur. You would then have to fix the same merge conflicts on all the pull requests you made since they all inherited the same branch.