It all depends on the organization and its expectations. I wouldn’t expect most organizations to document how a C compiler works, or how a linear regulator works – they expect their engineers to either know enough about these topics to compile a C program or build working power supply, or for those engineers to do their own research to learn what they need to learn. I think of Git/version control systems the same way, but I recognize that there are types of engineering organizations where the electrical engineers / PCB designers are not expected to know anything about how software development works.
An organization where people doing EDA work are also expected to be somewhat familiar with software development does not need an internal tutorial on Git – instead, it just needs internal documentation of organization-specific practices (for example, naming conventions, where to store files, what process to use for handling designs that multiple people are collaborating on, etc)
For what it’s worth, I generally never use branches or merging with Git repositories that represent EDA files (although I know others do so successfully). There are still a lot of benefits to Git even if you never use branches and merging, when compared to other solutions one might use to back-up files.
Sorry, I don’t think this is true. No native support in KiCad (or any other tool) is needed to use Git with it effectively. I’m not saying native support built-in wouldn’t be nice as a bonus feature, but it’s not at all required.
In a sense we are still at ‘what features should be native, which should be plugin/extension.’ It kinda kills flexibility when there are multiple options available.
Version control (Git or otherwise) is a special case, though. It can work with any software that produces files, no matter whether or not that software has a plugin system or native support for version control.
That said, KiCad will likely have convenience features for version control in the future, but they are just that: convenience.
Johannespfister answered this at length, but my little contribution is that using a VCS has saved me many times when it comes to undoing mistakes. Also, being able to trace back to what point in time things happened has also been helpful.
I’m not sure if there is one page or document that truly has helped me understand this. I’ve done a pair of presentations trying to explain git, which I send you if you’d like.
The main concepts I’d say to focus on are:
You want to commit (take a snapshot) often. Like more often than you think. git’s power comes from the idea that it’s a bunch of small (and atomic) changes stacked on top of each other.
Make sure you understand branching and merging before moving on to heavier topics (pull requests, rebasing, etc.).
Having said that, once you spend a couple hours poking around with git, I can recommend reading about a couple popular git workflows (gitflow, github flow, etc.). The main “thing” that took git from seeming chaos to a useful tool was reading those workflows, and implementing one of them in your own work (as appropriate).
Also (and this is just my opinion), I’ve found that git can be a slightly overkill tool for simple to moderate complexity boards. I’ve found that my development mode when working on schematics and PCBs is often somewhat chaotic, where it bounces between pages/sections of a schematic often, without finalizing one section first. Ideally, with a git workflow, you’d work on something (i.e. battery and battery management circuit), commit a working snapshot, and then move on to the next portion. Making commits as you finish a circuit block. So often, I’ve found that a choice I make in one block will change the “finalized” circuit in another block. Same goes for the PCB work. Having said this, I still use git as it’s the tool I’ve standardized on, and will just try to make the commits at reasonable snapshot points (board outline complete; immovable components placed; etc.)
I understand the desire to have every commit be at a “reasonable stopping point” but I actually usually encourage people to commit more often, including “work in progress” states that wouldn’t be considered “complete” because having more snapshots saved on the server has never hurt and often helped.
There was once a time when someone (who also preferred to avoid committing until getting a section “done”) had to re-do several days of work because the EDA tool corrupted it and he wasn’t in the habit of committing daily or multiple times per day.
It’s just that I want to acknowledge that when it comes to using git with software development, there is this super-power that comes from the ability to compile+run any snapshot, and to cherry pick what one commits in such a manner that it maintains that. I’ve had many times where I have worked on firmware, where I’ve been able to make a single, atomic commit that will setup and run a peripheral or whatnot. Even when I have a bunch of unfinished code that is running on the same MCU. That super-power just doesn’t really exist in git+EDA (both KiCAD and others-that-shall-not-be-named). Though honestly, correct me if I’m wrong. I’d happily adjust my workflow to have that happen.
My schematics are simpler. Each is on one page only. I am using smaller symbols than standard (but the same pin raster) just with hope that it will allow me to fit on one page in a situation where I would not be able to with larger symbols.
I see advantage of using git in software but for PCB I can only imagine advantage but not feel I would need it. Daily backup is enough for me. I remember may be 2 cases when I decided to check a conception I was not sure so I made a copy and worked some time at that copy and then decided which copy to keep.
We fall into the latter category, and there are a lot of good reasons why that is the case. In fact, this is also the case for many colleagues that I know in other companies. That being said, as we grow, we are adopting git into our PCB process. This has been an uphill battle because we are all primarily analog/power/RF circuit designers with little software development background, and precious little time. Our software development team has been of little help because they are not willing to understand our process goals, and make many assumptions based on software development, not EDA.
However, we are getting there. Furthermore, we do not need the convenience built into KiCad, because it is our process development that is the challenge - the basic tool operation is easy and it works. As we move more engineers to KiCad from Altium, there are other things that we see as much more important, namely padstacks, output file automation, IPC-2581 or ODB++ outputs. These are more important to build in than version control, which doesn’t even need a plugin to support (though I would welcome one if it makes life easier).
at first I want to thank everybody that helped us by sharing his experiences and ideas! I did not expect to receive that many answers! And I also want to add a big thank you to the KiCad developer team - often people (especially here in the forum) complain what is missing in KiCad, but they don’t see the great achieved level of usability and functionality.
After carefully reading all your posts, I also think that there is no way we can do this without teaching people how to use git (via console or some GUI tool). IMHO, I also think that engineers who are unwilling to learn are not getting too far. Still, about 30% of our employees will retire within the next five years (which is a fundamental issue in many companies here in Europe) and while most of them just swapped from mainly working on automotive-combustion-control-projects to working on multiple other technologies - also for the non-automotive markets - including many high-voltage or computing projects - they already really have to learn a lot and git really is not their main concern. BUT, in the meantime I also found out that Sourcetree is on our company-compliant-software-list. I haven’t tried it out in a project, yet, but this looks promising to me.
When using KiCad with Git, I personally also prefer the technique where you have the library as submodule of the actual repository. This also sorts out the issue of dealing with sym-lib-table / fp-lib-table entries and the only disadvantage might be that the 3d-files might be cloned independently for every project. Furthermore, library, schematic and footprint are always in sync with this solution and we therefore don’t have to mess arround with environmental variables or specific settings. I guess, I will have to just setup a repository template (containing the submodule) now and hardware infrastructure team just has to buy bigger hard drives ;-).
So, now we will start with a pilot project. If I find some other good workflows or techniques, I will let you now. Many thanks again to everyone, again!
No, please not. One program should do one job well, and only do one job. Adding git would increase the complexity, makes it harder when a different VCS is used or when the KiCad project is only one part of a git/VCS project, makes KiCad less flexible, bigger and slower.
And you have to learn another way to manage a VCS rather than using the VCS which you are already familiar with.
There is much power to combine simpler programs in to one toolset than building a large eierlegende Wollmilchsau.
However, KiCad should absolutely be build with VCS in mind, meaning not changing line ordering (such as it was in KiCad 5.1), having a smart way to put different things in different files, …
Sorry, but KiCad is not a “unix philosophy” command line tool. It’s going to continue to get more features that users expect from EDA tools, as long as those features align with our development priorities and we have the resources to implement them.
I think your fears are unfounded, though. Consider tools like IDEs that have built-in support for Git or other VCSs. You don’t need to learn another way to manage a VCS to use these tools: It’s completely optional, and learning it allows you to speed up certain workflows.
Thank you for these links. They are very helpful, as it has been a long road for us.
We selected git because of github, which turned out to be a good choice for us both internally and for making select libraries available to our customers. The level of protection and ease of use turns out to be an order of magnitude better than the hot messes otherwise known as Teams and OneDrive (not recommended).
We started small, and have grown, so are now trying to implement VCS. It has been tough because those of us familiar with it came from big companies where it was already taken care of by someone else. Hence, we don’t know a priori many important details necessary for a smoothly working system. What would be really nice for us is to see an example of a well thought out VCS for PCB design. We are making a lot of mistakes doing this which might seem obvious to others.
One open-source project that demonstrates the use of Git with KiCad is the Icebreaker boards:
You can see
They have elected to put each hardware revision in its own folder, so that all revisions are available side-by-side and can be developed simultaneously without using branches. This is also my preference (EDA files are not like code, and since they can’t easily be merged, this kind of workflow allows you to start the “next” revision of a board while still making changes to the “current” revision, for example if you know you want to make future layout changes but you still might need to tweak the drawings or BOM for the current version)
They use project-local sym-lib-table and fp-lib-table files that reference a custom set of libraries
These custom libraries are referenced with a relative path to ${KIPRJMOD}, the “current project directory” variable.
Inside the lib direectory of the repo, the pkl libraries are brought in as a Git submodule
The use of submodules has some pros and cons, and you will find people who say it’s the only way to go and people who say they don’t like doing it that way. If you don’t use submodules, you have some other options:
Just use a relative path to a library directory that is outside the Git repo for the project, and make sure to clone this library repo in the same place on every machine. This is more error-prone to set up, although once you have it set up, it works fine.
Create project-specific libraries and copy or create new symbols/footprints in these. This leads to repetition and prevents centrally-managing changes to symbols and footprints, so I don’t recommend it.
Use a “monorepo”, where you use one large Git repo to store your library and all projects. This solution works pretty well in my experience and is the only one other than submodules that I would recommend.
So KiCAD has a template feature built in, which is great. However, if you run into limitations, one software I’ve found useful is the cookiecutter package for Python. It takes a little bit of time to set up, but can save you several steps.
Feel free to use the template I’ve been using (though admittedly I haven’t updated it to v7 yet).
Agreed that github’s feature set is pretty solid. The only limitation I’ve found (or have seen but haven’t concretely confirmed it) is that one organization can’t add another organization as a collaborator on a repo.
I’ve settled on github and Dropbox for the file-backup and sharing services. I generally keep the directories separate, with git repos living in a C:\dev_SK\{repo} or ~/dev/ and Dropbox just taking care of itself.
