Team PCB projects, best library/workflow practices?

[John_Pateman]

Here is a nice comparison table outlining the major differences - in general PCB design is much more ‘Cathedral’ than ‘Bazaar’.

GIT	FOSSIL
File versioning only	VCS, tickets, wiki, docs, notes, forum, UI, RBAC
Sprawling, incoherent, and inefficient	Self-contained and efficient
Ad-hoc pile-of-files key/value database	The most popular database in the world
Portable to POSIX systems only	Runs just about anywhere
Bazaar-style development	Cathedral-style development
Designed for Linux kernel development	Designed for SQLite development
Many contributors	Select contributors
Focus on individual branches	Focus on the entire tree of changes
One check-out per repository	Many check-outs per repository
Remembers what you should have done	Remembers what you actually did
Commit first	Test first
SHA-2	SHA-3

EDIT

It also allows imports from Git (so you can try it out) and exports back to Git (if you don’t like it!)

[MitjaN]

@Ladasky

(we’re a non-profit university, and there are apparently academic accounts)

We use free offering from GitHub for universities and it was quite easy to set up. From my perspective git is good because KiCad’s libraries are in gir repo on GitHub. So if you are starting with KiCad I’d recommend that you base your libraries on them. And if you keep them under git it is much easier to manage them.

[Russ]

15:58 Yes, I know how to round off.
As eelik pointed out, whilst git might be good for collaborative software development, collaborative CAD development is made more difficult because of reducing 2D and 3D space on the board. As more components are added to a PCB, available 2D and 3D space between components make it more difficult to place any extra trace of component, with difficulty increasing with the feature size. So git might only work for (1) backing up one’s own work, and/or (2) sharing schematics. Neither of these options, though, requires a version control system. Just good communications and agreements among team members about who creates what and where in the 2D space.

Although I don’t use “Windows”, I have seen some websites like this one indicating git may run on MS Windows. https://gitforwindows.org/

[eelik]

@Russ

Although I don’t use “Windows”, I have seen some websites like this one indicating git may run on MS Windows. https://gitforwindows.org/

Why wouldn’t it? I use it all the time. Certainly git couldn’t be the most used VCS otherwise.

For Windows I recommend trying the TortoiseGit frontend.

[pedro]

@Russ

Just good communications and agreements among team members about who creates what and where in the 2D space.

We use git in github for kicad projects. Our “good communication and agreements” is a kind of semaphore: the one who is going to work on a project, schematic, library, layout… “takes” the semaphore and “gives” it once his work is accoplished.

NOT optimal, of course, but possible. Merging is the big issue.

[John_Pateman]

I would add to that list (3) Branching your project to try different layouts / components. For instance, you can branch your project and have different layouts - for example where you are considering two alternative micro controller chips in different packages with alternative routings or perhaps an SMD vs TH layout.
The power of a VC system is being easily able to go back to any point in your commit history - so you don’t need to keep (usually cryptically labelled) part projects. Say you start planning a layout for one micro controller and then you discover that there is a production delay or some other reason to change - you can simply revert to a previous version and branch off an alternative layout.