What is a Version Control System?

Ever wonder how software development teams manage complex codebases without overlapping each others’ work? How do they roll back changes to an earlier version of a code base if they mess up? The answer is in version control systems. These systems are used by software teams to track codebase changes, roll back or forward versions, and consolidate changes from multiple developers into a single version.

Little do most hardware engineers know, they can also take advantage of a version control system to help them track project progress and create official releases for manufacturing. Version control systems of the past were invoked through a console, but today’s modern version control systems for hardware engineers will run in the background of your design tool. If you’ve never used a version control system, we created this essential guide to help you get started and understand some of the core definitions used in version control.

Version Control Systems Overview

All version control systems perform some function surrounding tracking and maintenance of each version of a project, as their name implies. There are a few key functions a version control system performs, which are summarized in the following table. These operations are provided in more detail in a later section in this article.

Version control systems were originally invented by Bell Labs while developing UNIX. Today, they are ubiquitous in data management systems and they are an important management tool for tracking releases of a project. In the hardware world, this means design teams can track the entire history of a project between each version of the device, and between each release to production.

What Can Be Tracked in Version Control Systems?

Technically, any data that is part of a project can be committed to a version control system and the changes can be tracked. Hardware-specific version control systems are normally built into CAD tools, so they will only work with native CAD formats, production files, and any ancillary files that are accepted as part of a CAD project’s file structure. For some CAD tools, this could literally be any file, while other CAD software will only accept native project file formats.

Software version control systems have historically been independent utilities like Git, where they are accessed from commands in a console. They may also be accessible from inside a project management system, or they can integrate with a 3rd party version control system via an API. Because software and firmware developers do not have their own version of a CAD tool, they are not bound by a single version control system and they tend to pick systems based on integration capabilities.

Collaboration With Version Control

The collaborative process implemented in a version control system is outlined in the graphic below. Consider a project with a long revision history, called the “Main Branch” in this example. This graphic starts through creation of a branch coming off of the main branch in a project’s revision history. The idea below is to fork the project (this operation is explained in more detail below), however this could be done through cloning.

After the new branch is created from the existing revision history, it can go through its own modification and testing process. Along the way, the changes in the new branch can be saved to the version control system (commit changes) so that the changes can be rolled back if needed. Eventually, when the branch is completed, a pull request can be issued so that the team can review the changes implemented in the branch. Once the changes are ready for acceptance, the team will need to compare the new branch with the Main Branch, and then changes can be merged into a single branch.

Important Version Control Operations

The version control operations listed in the table above are meant to facilitate collaboration while groups of developers work together on a project. Oftentimes, developers will be working on the same version within a project’s revision history, or they may work on separate versions using forking and cloning operations. Ultimately, the operations listed above are intended to ensure there is a single source of truth for the project’s current version and data.

Forking and Cloning

Creating a new branch from a project involves two possible operations: forking and cloning. These two tasks are essential parts of any version control system because they define how users will work with the existing data in the system. Both operations involve duplicating data that has been committed to the version control system. However, these operations differ in terms of how they handle the relation to the project’s revision history.

• Forking
• Data is duplicated and remains in the version control system
• The duplicated data carries the same revision history as the previous data
• Cloning
• Data is duplicated and is often downloaded to the user’s local machine
• The duplicated data does not remain linked to the original data’s revision history

The next question that often arises when working with version control is: when should you clone and when should you fork. Unfortunately, there is no correct answer to this. Designers and developers can develop their own policies as to when data is forked or cloned, and these could be overseen by an administrator. Some development teams might decide to fork or clone projects on-the-fly in order to address issues as they arise. This is more of an approach to managing data that requires a team to be agile.

Learn more about forking and cloning in hardware design.

Pull Request

The simplest way to explain a pull request is as a notification. Essentially, a pull request is the mechanism a developer would use to let other team members know that their changes are completed and are ready for review. A pull request is issued within the version control system’s GUI, and the system would send a notification to other team members so they are aware of the changes. Pull requests should only be issued when a branch has been modified and the changes committed to version control. This way, other users can access the changes and compare with earlier versions.

Compare and Merge, Resolve Conflicts

Assuming the changes outlined in a pull request were acceptable and all feedback was implemented, the changes can be incorporated into the earlier version of the main branch. Changes in a side branch can often overlap or overwrite data in the main branch, and these changes will need to be compared and accepted before those changes are merged back into the main branch.

With code, it’s much simpler to go line-by-line or function-by-function to merge changes back into the main branch. With hardware, it’s quite different, and users might look at the component level or the feature level, rather than looking at a PCB layout in its individual primitives. The user interface in your version control system can make the compare and merge process much easier.

Compare and merge is much easier when it is based in a graphical user interface.

Hardware and Firmware Developers Need Version Control

Hardware design teams working across disciplines will sometimes have their initial experiences with version control systems when they start working with a firmware developer. Firmware is basically code, just like software, but it will be deployed on a piece of hardware, so the firmware developer must work alongside the hardware systems designer to ensure there is alignment. In many cases, the firmware developer is a front-end engineer or PCB designer, and they may take the lead on managing project data.

CAD tools that implement version control systems enable data management directly by the design team, without the need for a systems administrator. Commits, pull requests, forking, and cloning are all possible within this type of system, but within an intuitive user interface that does not require working through a command prompt. This is also much easier than working through a 3rd party version control system, which might require passing data to an API (particularly in the cloud), or the 3rd party system must have an existing integration with your CAD software.

See why your team can benefit from a PCB design application that integrates with a version control system.

Hardware design teams and embedded developers that need to collaborate on complex projects can use the complete set of design tools in Allegro X PCB Designer and the data management tools from Cadence. Allegro X is the industry’s best PCB design and analysis software, offering a range of product design features with a complete set of management and version control capabilities. Allegro users can access a complete set of schematic capture features, mixed-signal simulations in PSpice, and powerful CAD features, and much more.

If you’re looking to learn more about how Cadence has the solution for you, talk to our team of experts.