Not trying to get you wrapped up in some advanced and confusing Git practices, so I want to share with you some best practices to start with that worked for me through the years as an experienced DevOps engineer.
Prerequisites
- Git
Solution
commit best practices
If you want to nurture the best part of the whole DevOps and CI/CD practices make sure to make frequent and minimal commits if that makes sense.
The key point is to keep commits as small and meaningful as possible. For instance: fixing a bug, refactoring or developing minor features. Think of it as a commit per Jira task. Besides, it’s important to not commit unrelated changes. For example if a bugfix needs to be pushed, don’t commit refactoring code too. On the other side, don’t half-ass the refactoring commit as well.
This way you are most likely preventing a certain amount of merge conflicts and preventing or at least lowering the possibility of introducing any unexpected bugs.
Other often underrated best practice would be writing detailed commit messages. Abstract and unclear messages such as: “feature X”, “update #2”, “querty” are so bad lol.
Instead, focus on writing precise and clear sentences in present tense. For instance:
- feat: Include elasticsearch library
- fix: Resolve bug making users randomly signed out
- <JIRA-task-ID>(feat): Introduce simple subscription form
Decide on Git commit messages practice in the early project stage. The earlier, the better.
Related: The right way to write Git commit messages.
Also, always make sure to test your code before committing anything whatever it’s your own local environment or even some test, feature and bugfix env. The latter would be better though.
decide on a Git branching strategy
Determining certain Git flow that “just” works and aligns pretty well with the Agile methodology if any is another many times overlooked practice.
I did go a little deep into details here: Git 101: branching strategies.
do not push directly to the main branch
Okay, I think we all have been guilty of lazy pushing to the main branch. Who gives a “thing” you know?! Right, but that should never be the case whatever working for another company, individual or even on yours weekend projects.
Branching out has many pros among:
- Keeping the Git commit history clean.
- Identifying bugs and vulnerabilities easier.
- Isolating features, bugfixes and refactoring from each other.
make the most out of PRs
Most Pull Requests I’ve been dealt with as a committer were just mindlessly approved including the LGTM message. Pull requests can be a place where you can learn new things too if properly applied. It shouldn’t be an ego thing, right. Everyone has to start from somewhere. It’s not about criticizing your own code, it’s about quality, improvements and feedback being the last part of the DevOps cycle.
As for being reviewer, it’s your responsibility to not be lazy and enforce good coding practices.
tagging
Mostly, try to use tags when releasing new version of your code by applying the famous Semantic Versioning (v.X.Y.Z) by any chance.
To create a new tag from current checked out branch, run:
git tag v2.0.1
Related: Git 101: tags.
stay away from rewriting the main branch history
By any means, do not rebase the main branch. It will rewrite the main branch Git history hence won’t be preserved at all. Leads to a mess as you won’t know how and when commits were merged. You are welcomed to disagree in the comment section below.
Related: Git: merge vs rebase.
experiment
Do not be afraid to experiment with less known and used Git commands as:
The more you experiment the better. You are going to make mistakes for sure, but that’s how you learn and progress.
Conclusion
To find more neat Git commands and hacks, simply browse the Git category. Feel free to leave a comment below and if you find this tutorial useful, follow our official channel on Telegram.