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 not only use Git but also always follow some good practices that I have learned. Now it is time to share them.
1. Use branches for features, AB tests, fixes, whatever
This practice allows me to make much more atomic changes, not getting distracted, identify branches easily and of course, translate all these advantages into pull requests afterwards.
2. Remember the old checkpoints: commit often
Do you remember the checkpoints on the games you play? Every time you screw it up you are 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.
Another good practice related to this is to merge all related commits into one to avoid having a lot of noise among all the commit messages.
Note: these are two stories that talk entirely about the importance of commit messages: The Secret to Great Commit Messages and Light of a Thousand Commits.
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, use base branches.
I usually use at least two different base branches: develop and master.
Master is the code base that reflects the latest product released to the users. This is very handful when you have to release hot-fixes on production because you just create the fix branch from master.
Develop, on the other hand, is the base branch where I merge all my feature branches or things that I am coding that were not released to the users yet. After I integrate everything with develop, do the proper testing and release based on that code, I merge develop into master.
Did you like what you read?
Recommend this story (by clicking the ❤ button) so other people can see it!
You can also react on Twitter @santihollmann
