Git is a powerful tool in your development arsenal providing remote storage, versioning, and collaboration. When working on a team, it’s an effective way to allow individual contributors a clean copy of the code base without stepping on another’s toes. Every language framework and utility I’ve ever used has a set of communal best practices, and git is no different.
Never push to the main branch.
Though sometimes tempting, pushing to the main branch directly should be avoided (In some projects, the standard branch could be staging or dev). Instead, consider creating a branch from the project’s default, comitting your changes here, and submitting that branch as a PR. This workflow not only forces peer review, but also minimizes merge conflicts when multiple developers are writing to the same file. Modern git hosting solutions like Github even support Branch protection rules as an enforcement mechanism.
Write descriptive and meaningful commit messages.
When scrolling through a projects history, too often I’ve seen “Fixing!” as the commit message several times in a row (I’m guilty of doing this in the past myself). Think of commit messages like code comments, they may seem obvious at the time of writing, but developers of the future (yourself included) will thank you for the specificity.
Rebase frequently.
Branches are intended to be an isolated copy of the code for you to make changes without impacting another’s work. While working in isolation, it’s common for other team members to continue contributing to the repository. In these cases, it’s important that your isolated copy remains to date with any changes that may have ocurred since creating the working branch. This can be accomplished by rebasing. Just as your initial branch was based on the source branch, you can re-base your current working copy on the source branch at any time. Doing this frequently prevents merge conflicts and other unexpected complications when it’s time to submit your PR.
Commit early and often.
Committing regularly has many benefitis. First and foremost, at its core, git is a history utility and when experiementing with code, history is your friend. The more of it you have, the better. Additionally these small chunks of code provide your teammates with a peek at your progress which fosters collaboration.
PRs to match features!
When submitting a PR, it’s important to match it to an explicit feature, bug, or user story. When a teammate comes along to review your work, there’s no mystery to its purpose. It can also be helpful in the future when reviewing a project’s history. Should you ever need to roll back the code for any reason, it’s clear and descript where to do so.
Squash & Merge!
Over the course of developing a new feature, chances are there are plenty of commits on your branch (especially if you’re following the advice from above). When the feature is ready to submit for review, squash those commits into one. This will maintain a consistent and clean git history on your main branch that’s easy to understand. Again, if you need to roll back to a previous version, it’s much simpler with a clean and linear history.
Bonus! Configure CI/CD
Although it’s not a direct feature of git, CI/CD pipelines are helpful for automatically running your test suite, generating builds, and even deploying your new features automatically. When paired with git, these pipelines can be triggered automatically with each commit, or on commits to specific branches. Automating these prorcesses allows you to focus on other things, like writing code. Further, when used in conjunction with branch protection rules, you can prevent regressions from sneaking their way into the code base.
With today’s workflows using git is a no-brainer. Following best practices can pay dividends individually, and when used together those dividends compound.
