The top questions hardware developers ask us about using git
As we continue developing our upcoming hub, we've been hearing similar questions about best practices for all things related to using git for hardware. Here, we wanted to share our take on the three 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 merged 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 a 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 checkpoints.
2 - What's wrong with my monorepo? 😢
Monorepos are simple to set up and easier to manage -- in theory.
They have, however, many shortcomings as your project grows and becomes more complex:
They are less modular - if you need a specific design, you have to download the entire catalog
Increase the likelihood of files conflicts
Reduce 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? 📂
In the past, some people have had really bad experiences working with large binary files on git (see branches above!). One problem is that git cannot compress binary files the 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 five 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 growing too large and clone time 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 the 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 info@allspice.io.
Valentina is an experienced engineer and former Amazon PM, having managed infrastructure projects and internal productivity software. She holds a B.S. in Mechanical Engineering from Boston University and an M.S. in Engineering (Computer Science) and an MBA from Harvard. Passionate about hardware space and cross-team collaboration, Valentina co-founded AllSpice in 2020.
