Hi all,
I use kicad mainly for schematic capture and BOM management. Git is my main VCS for everything, so I ended up trying to make Git and Kicad work hand in hand. I summed up my findings here:
Any remark, enhancements, pull-requests are welcome!
JN
Good work.
I use SVN with KiCad in the office and will try to take your efforts to improve the SVN route
I’ve successfully stored a KiCAD project on Github: https://github.com/John-Nagle/ttyloopdriver
This works well if you make all libraries project-specific, so the project contains everything you need. This project has 3D models for everything, so you can get a render in 3D view if you want.
(This is version 1; a board was built but didn’t work electrically; too much MOSFET for the available gate drive power. Version 2 is coming.)
You could keep the libraries in a separate git repo if you include it as a git submodule.
https://git-scm.com/book/en/v2/Git-Tools-Submodules
https://chrisjean.com/git-submodules-adding-using-removing-and-updating/
This approach gives you the benefit that you can keep one central repo with your personal libraries and a single repo for each project. (It also has the added benefit that others could use your libraries within their projects.)
Edit: github information page:
I don’t know for PCB artwork, but for schematic, I usually manage the libraries in another repository, which is not part of the project. To open the project, you don’t even need the other libraries if you commit the -cache.lib library inside your project.
In fact, I would warn against commiting the libraries or even making them part of the project by a submodule, because that means that you are starting to change local copies of libraries and may end up having to merge multiple versions of a lib. In the case you appended new components to the libs in two different projects, you are sure to get a conflict, even for local mono-user projects…
That is exactly why you should have one central place where you put your libraries. (can be a git repo connected via submodule as i suggested or a separate directory on your pc that itself can of course be a repo.)
The chache.lib file should be part of the original project (No one ever suggested anything different). So if you change a symbol or footprint in the library kicad does not quietly update the copies within your project.
You only need to merge if either multiple people work on the same libraries (should only be a problem for schematic libraries. Footprint libraries are one file per footprint.)
Or if you don’t commit (and push) your changes right after you made them. (You would also need to make changes to the library via a different project for that to be a problem. So you need to make two mistakes at the same time.)
I use exactly this setup for many projects, and there never was a problem. (I try to use atomic commits.)
Another way to get into trouble (only if multiple people work on the same library/project) is by forgetting to pull before you start to work.
By the way, merging kicad stuff is not as dangerous as it may seem.
Within the last week i needed to merge in at least 5 changes done by other people in our teams symbol libraries.
Merging a full project might be a bit more dangerous. So i would advice against that.
(If you commit and push often, the danger of that happening is quite small.)
tl;dr: If you use git as intended you should not get in trouble if you manage your libraries within a git repo. Not even if you share it as a submodule in multiple projects. To be on the safe site use atomic commits and push/pull often.
what do you mean by 'atomic commits"?
One commit per change. https://seesparkbox.com/foundry/atomic_commits_with_git
Example, if i lay down traces in a pcb, i make a commit for every “part” that i connect. More detailed if i lay down all 4 traces for the spi. Or if i lay down the traces for the 2 temperature sensors my board has.