Null
September 13, 2018

10 Code Commit Best Practices for Streamlined Development

Version Control

Checking in code is the essential task of a version control system. Often referred to as a commit, this operation allows individual developers to contribute their work to the evolving codebase. But not all commits are the same. A bad check-in can lead to broken builds and regressions.

Below are 10 tips for ensuring quality commits and a single source of truth.

Use Short-Lived Feature Branches

The correct branching strategy is key to streamlining the commit process. Smaller, short-lived branches are a proven way to minimize bad check-ins.

Unlike long-lived feature branches that can quickly become unwieldy, short-term branches are manageable. They reduce check-out times, improve traceability, and expedite code reviews. This means commits occur more frequently and without confusion.  

Have a Single Intent

It’s tempting to include a number of changes in a single check-in. Like committing code with a bug fix and a new feature, for instance. Even though this seems like an efficient way to develop, it creates downstream problems if any of those changes need to be rolled back.

To prevent regression, ensure that each check-in has a single purpose. This will make diagnosing bugs and tracing change flow a lot easier. 

Keep the Scope of a Check-In Narrow

Break tasks into smaller chunks. This may require some planning at the outset, but it will make reverting check-ins a lot simpler. To help you keep a narrow scope, consider segmenting tasks based on system requirements.

So, you could have a task that deals with infrastructure and refactoring. And another task that focuses on the user interface.

Describe the Reason for a Change

Use the change comments feature within the versioning tool to clearly explain why the change was made. Keep in mind that your team members will be able to see how you made the respective change by comparing the before and after revisions.

But it will be a lot harder for them to know the reason for the change. Leaving a detailed comment with every commit increases codebase literacy and fosters collaboration.

Make Passing a Build a Requirement

If you’re hesitant about your commit passing a build or test case, don’t commit. Bad commits make tracing bugs and merge conflicts a time-consuming process.

To ensure your check-in will pass the build, create a trigger that runs your commit through a build engine before your code can be checked in.

Use Code Reviews

Protect the quality of your mainline by having all code reviewed before check-in. Version control systems, like Helix Core, include their own code review tool. This means a code review request is immediately triggered when your code is ready for check-in.

And code reviews are more than a quality gate for your single source of truth. They promote knowledge sharing and code reuse.

Include All Affected Files

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. 

Ensure the Check-In is Traceable

For security and audit purposes, make sure that every change can be easily traced. This means not only who made the change, but why and how.

Look for a version control system that includes per-file access logs and visualization tools for side-by-side file comparisons. 

Have Reversible Check-Ins

All check-ins should be easily reversible. But luckily, if you follow these simple tips, you’ll be able to quickly revert a change and reapply it later if needed.

You can get help from your version control system, too. With Helix Core, you can undo an entire changelist without losing your audit trails. 

Use the Same Policies for All Your Projects

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.

Helix Core uses a branching structure called Streams. This feature makes it easy to implement policies across branches. Plus, you can have dedicated Streams for specific tasks — from release and innovation to back-end and front-end code.

Quality Commits: The Foundation for Effective Version Control

It’s clear that checking in code is a critical step in software development. But commits aren’t created equal. A bad commit can not only break the build – it can lead to delayed releases and unhappy customers. By following these 10 best practices, you can protect your single source of truth and develop better software faster.

Helix Core: The Key to Following Code Commit Best Practices

Reduce bad check-ins and improve productivity when you try Helix Core for free. A full version of Helix Core, which comes with Helix Swarm for code reviews, is free for up to five users.