The top questions hardware developers ask us about using git

As we continue developing our upcoming hub (PW is HWdevops), we've been hearing similar questions about best practices for all things related to using git for hardware. Here we want to share our take on the 3 most frequently asked questions we get.

1 - Can I use branches? 🎋

Branches are helpful in organizing your work and keeping finished versions separate from the work in progress. That being said, there's no process to merge ECAD files, so you want to make sure you adapt the software principle to fit your hardware workflow. You wouldn't want to end up with branches of branches of branches that need to be merge and require more work to manually consolidate than the benefits they bring.

Until full merging and conflict resolution is supported, we recommend a dual branch structure - a main branch and develop branch.

All your day to day work happens in the develop branch. You (should) push every change in a new commit. Once your revision is ready, it goes to the main branch via a pull request or design review. Ready means you're about to order a prototype, send it to a manufacturer, store it in PLM or any other critical milestone your company uses as development check points.

2 - What's wrong with my monorepo? 😢

Monorepos are simple to setup and easier to manage - in theory. They have, however, many shortcomings as your project grows and becomes more complex:

  • It is less modular - if you need a specific design, you have to download the entire catalog

  • Increases the likelihood of files conflicts

  • Reduces your ability to do access control - this is always done by repository

  • The entire history for all your projects are now merged together

  • Documentation becomes harder

In our opinion, repositories per project linked via submodules are best.

3 - What's the best way to work with large binary files? 📂

Some people had really bad experiences working with large binary files on git in the past (see branches above!). One problem is that git cannot compress binary files they same way it can text-based code. As git clones will, by default, check out every version of every file when you clone, the size of repositories consisting of binary files can become cumbersome. The tech has come a long way over the past 5 years though, and git has introduced some features to help with managing these workflows:

  • Git Large File Storage (LFS) can automatically decouple storage for files in your repository from the revision history. Instead of storing each binary file directly in the repository for every revision, git LFS will store the file externally and only commit a small pointer to the file. It has the smarts to fetch this file on the fly whenever it's requested by you. It also adds the ability to lock files.

  • If you find your repository is growing too large and clone time is becoming a problem, blobless clones allow you to clone only the files you want. There are a few options, but shallow clones allow you to only download the latest version (or latest few versions if you decide) of the files in your repository.

Do you have a different question about using a git workflow for developing hardware? Let us know below so we can tackle them in a future post, or send us an email at