5 Good Practices I Follow When I Code Using Git

Nowadays using Git is almost a rule and of course tools like GitHub, GitLab and Bitbucket are almost a standard.

To me, it really doesn’t matter the size of the project that I am coding, it could be for my current job, a freelance one or my personal apps: I always use Git.

I think that habit is like a cane to walk the road to perfection. That’s why I do not just use Git but also always follow some best practices that I have learned.


  1. Use branches for features, AB tests, fixes, etc.
  2. Commit often.
  3. Use clear commit messages.
  4. Always use pull requests.
  5. Keep master releasable.


1. Use branches for features, AB tests, fixes or whatever

This allows me to make much more atomic changes, not getting distracted, identify branches easily and of course translate all these advantages into pull requests afterward. I usually use this convention: feature/name-of-feature, abtest/name-of-abtest, fix/name-of-fix

2. Remember the old checkpoints: commit often

     Screenshot of Cisco Heat: All American Police Car Race. Image from Moby Games

Do you remember the checkpoints on the games you play? Every time you screw it up you’re able to start again from your last checkpoint. Commits to me are the same thing.

Just started coding a feature? Make the initial commit. Improved a little bit the feature? Make a commit. Wanna try a different approach? Commit what you have done until that moment and then refactor whatever you want.

By doing this, I avoid having comments, messy and commented code and things that I will need to clean later but more importantly I can always go back to stable states of my code.

3. The clearer the commit message is, the better

I always use descriptive titles for my commits. Also, if I have been working for a while and/or have touched many classes, I write a short title and then summarize the changes with bullet points.

Thanks to git commit –amend you can easily commit your changes and describe them without having tons of commit lines.

Another good practice related to this is to squash your commits down into one that summarizes all the changes you have made.

4. Always use pull requests, always

It doesn’t matter if I work with other people or on my own, I find great to use pull requests every time I want to merge my code with my base branches. By doing it I can detect issues, wrong code style, commented lines, mistakes, things to improve, etc.

5. Backups are important, keep master releasable

I usually use at least two different base branches: develop and master.

Master is the codebase that reflects the releasable product. This is very handful when you have to release hot-fixes on production because you just create the fix branch from master. It always has to remain releasable.

Develop on the other hand is the base branch where I merge all my feature, fix and AB test branches. After I integrate everything, do the proper testing, I am sure it is releasable and make the RC from it, I merge develop into master.

Leave a Reply

Your email address will not be published. Required fields are marked *