Checklist before committing/pushing

Β·

3 min read

Checklist before committing/pushing

I have been working full-time as a software engineer for only 2 months, and it's safe to say I have already made so many mistakes when it comes to git and version control. In attempt to avoid more mistakes, here are some basic tips, rules and questions I have compiled for you to keep in mind as you work on your branch! (These are all based off of my own experience and I would assume that they will not be applicable to everyone!)

Commit or Push?

So what's the difference between committing and pushing? When should you do what?

First of all, you cannot push without making a commit. Pushing always comes after committing. The question then becomes, "Should this just be a commit? Or is it time to push?"

A commit is just saved to your local machine. Commits should be small, single purpose changes, ideally small tasks and changes to the code that are tightly-related. Once you feel like you have something working, you can commit those changes and save them locally.

All a push does is sync the remote version with your local version. All your commits are maintained, but they are now on the remote repo.

In an ideal world, you would push with every commit. This would ensure never losing your work, as the remote branch would almost always be up to date with your local. However, in the real world, there are some questions you might want to ask yourself before pushing every time you make a commit. Here is the main one from my experience:

  • How is our team's CI/CD set up?

For my team, a build runs on TeamCity for every push on every branch. This means that every time I push changes, these builds are running. I probably wouldn't want to push every small change due to cost of TC and also getting in the way of other branch builds.

As a last rule of thumb, each commit and push should try to maintain the highest level of code-quality. You should avoid commented code and broken features. I have heard people talk about making each commit/push "PR-worthy", although this definitely doesn't apply to every scenario.

In the end, git is a history of the code. Try to make each commit/push logical and readable, like a story. This will help those reviewing it (and yourself) understand what changes were made, why they were made, and what is going on.

Checklist

Now that you know if you are going to make a commit or a push, here some basic questions you should ask yourself before doing so:

  • Compile?
  • Rebased/pulled recently?
  • Latest version of main/master? (if you have taken care of the previous one, this shouldn't be an issue)
  • Version bump?
  • Build?
  • Tests? (Don't forget about integration tests and test:ci...)

Making the Commit

Now that you have gone through this checklist, you should be good to make the commit!

Keep your commit messages short and specific. You don't want to be too vague with what you have done, but also, you can't write a novel. The reader should have a decent idea of what you did, especially whether it was a feature, or bug fix, etc. I believe most commit messages should be under 50 characters.

Hopefully this helps!

Β