Git best practices are important. Here, we share what the top Git best practices are — especially for Git commit.
Table of Contents
What Is a Git Commit?
Checking in code is the essential step with any version control system. In Git, this is referred to as git commit. This operation allows individual developers to contribute their work back to an ever-evolving codebase.
But not all commits are the same. A bad check-in can lead to broken builds and regressions. Plus it can delay development teams, and even a release.
Below are our git commit best practices to help you have higher-quality check-ins to prevent delays.
Back to top5 Git Commit Best Practices
Branch Frequently, Commit Often
Deciding on a correct branching strategy is vital to streamlining the commit process. Whatever your strategy, communicate to the team how you want to branch. You also want to direct developers to use smaller, short-lived branches. Using this method has proven to minimize bad check-ins.
With short-term branches, you reduce check-out times, improve traceability, and expedite code reviews. By committing more frequently, you help to eliminate confusion and decrease the chance of a time-consuming merge.
It is also important not to include a large number of changes in a single branch. Even though this seems like an efficient way to develop, it can create problems later. To prevent regression, ensure that each check-in has a single purpose. This will make diagnosing bugs and tracing changes a lot easier.
Make Small, Single-Purpose Commits
By committing only small sections of code, everyone on your team can quickly understand what work has been completed. And if something goes wrong, smaller commits make it easier to revert bad check-ins, which helps you maintain a stable codebase.
It’s easier for developers to understand the submitted code when only related changes are checked in. Think of a commit like a wrapper around a set of changes. Everything inside the wrapper accomplishes one purpose. If you are fixing two separate bugs, there should be two separate commits.
Write Short, Detailed Commit Messages
When writing a commit message, start with a short summary of your change. Write your summary in present tense, limit the subject line to 50 characters, and always leave the second line blank. This separates your subject line from the message to ensures only the subject line displays.
Keep in mind that your team members will need to be able to read this message and understand exactly what you have done. Make sure that you provide enough detail to answer:
- What changed from the last version?
- How did it resolve the issue?
- Why did you make the change?
Some bad examples are:
- Address workitem xxxyyy.
- Fixed a bug.
- Refactored X and Y. Added files.
- Who broke this code?????
Some better examples include:
- Add search for username in group view.
- Fix dynamic field init method to show status.
- Small changes to text editor to enhance user experience.
Test Code and Require Reviews
If you’re hesitant about your commit passing a build or test, don’t do it. Bad commits make tracing bugs and resolving conflicts a nightmare. You should test your code often, and commit once.
To help protect the quality of your codebase, it is important to require code to not only pass a build, but also be reviewed. Using code reviews creates a quality gate that can promote knowledge sharing and code reuse.
Pick a code review tool that does not bottleneck development. When code is ready to be checked in, it should launch a code review.
Preserve History and Traceability
When checking in a change, make sure all affected files and unit tests are included. This is especially important when working between branches. Providing related test cases and files with your commit ensures that others can use your check-in without breaking their builds.
If different projects or branches are governed by unique policies, keep them in separate codelines. While this may seem like an administrative burden, the right source code management tool makes this a simple task.
For security and audit purposes, make sure that your changes can be understood by other developers. It is important when using Git to not alter your local history.
[Related Blog: 8 Version Control Best Practices]
Back to topGo Beyond Git Best Practices
Helix TeamHub solves complex development challenges for your Git developers. It lets you have multiple Git repos inside a project. Each repo is visible in the context of the project. This lets you see how repos are interrelated. And you can watch the team making changes to each in one place.
Multi-Repo Git Code Reviews
With Helix TeamHub, you can also create one code review that encompasses work being done by team members across multiple repos. This is especially useful when the are strict dependencies between the work being done by the teams, and the code needs to go into production simultaneously in order to work. Each individual commit in the review can be required to:
- Pass a build.
- Be reviewed.
- Satisfy assigned tasks.
- Be approved by a specified number of developers.
This ensures that each of the changes is thoroughly examined before merging. Once all have passed their gates, all the work will be merged atomically.
You can reduce bad check-ins and improve productivity with Helix TeamHub. See for yourself. You can try Helix TeamHub for free for up to 5 users and 1 GB.