When to Use Forking vs. Cloning in Version Control

In terms of workflow management, PCB design projects can be more cumbersome than software projects because many of today’s products have a firmware and/or software component. The hardware design data and the software data need to be archived, tracked, and managed by multiple people who are often working asynchronously. Project management applications, data warehouses, ERP/PLM systems, and version control systems are important tools for managing the entire design, release, manufacturing, and lifecycle processes.

Design teams use version control systems, like Git or Tortoise, for change management and workflow management, both for their hardware design data and for their embedded software. Version control systems are useful for tracking changes to design data, but they need to come with a management strategy that determines when certain features should be used. Two important features that designers will use most often as part of a version control system are forking and cloning. We’ll look at when these features should be used in product design and how they fit into a project management strategy.

Forking vs. Cloning in Version Control

Cloning and forking are best known by GitHub/Git users as two data management processes. When design data is stored in a version control system, the repository containing the data can be accessed, modified, and tracked using forking and cloning processes. The high-level differences between these processes are shown below.

Forking

In open-source projects, forking is normally performed when a designer or developer wants to contribute to the codebase or the design database. The data is replicated from the most recent version of the code base, and the replicated data is under full control of the developer performing the fork. The developer can then modify the design/codebase, and then those changes can be submitted for review and inclusion in the main repository. In Git, this is known as a pull request, and it may require consolidating changes to the original codebase to ensure any conflicting changes from the most recent commit are consolidated.

In an enterprise environment, a fork is normally seen as a server-side duplicate of a design database that is only controlled by the person performing the fork. The forked version will have the same version history as the original database; reverting changes of a fork is equivalent to forking an earlier version of the database.

There are multiple reasons to fork a project rather than to clone it.

• Simplify interactions between a team and external engineers or project stakeholders
• Focus team efforts on an experimental design change without disrupting a working design
• Designers can work on their own portion of a project while limiting access from outsiders, which reduces noise and potential merge conflicts

If you plan to experiment with a design, such as if you are performing simulations, then it makes sense to fork the design and merge it back to the original repository later. The

Cloning

In Git, cloning creates a local copy of a repository, similar to downloading a repository from a version control server to your local computer. Other version control systems may use a different terminology, but the general idea is to create an unlinked, non-synchronizing copy of a repository. This unlinked project does not synchronize with version control unless you tell it to do so, in which case it will then exist server-side as a separately named repository. Note that two repositories (an original and a clone) could have totally identical data and could differ only in name, access privileges, and visibility.

Some reasons to clone a project include:

• Creating a totally new design based on an old design, e.g., such as a new layout from a reference design schematic
• Local editing is required rather than doing everything server-side
• Users have write access to the original repository and do not need change reviews

Once the cloned design is modified, it can be committed back to the version control system, but the project will exist as its own repository with a totally separate revision history. Once the repository is cloned, the cloned repository can also be forked as part of the development process. It can then be merged back to the cloned repository, which is then merged back to the main repository.

Hardware design teams working with approaches outlined here need design tools that can integrate with a version control system as part of an engineering data management strategy. Allegro PCB Designer, the industry’s best PCB design and analysis software from Cadence can give you these management capabilities and much more. Allegro users can access a complete set of schematic capture features, mixed-signal simulations in PSpice, and powerful CAD features, and much more.

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