Computing > Programming

Real-world git use

(1/4) > >>

Bassman59:
I was going to post in this big thread, but perhaps a separate thread is better.

As I said in that thread, we are an SVN house (and I have an SVN repo for personal projects). It works well for us, and it's worth noting that there are no situations where the engineers do not have direct access to the repo.

I primarily do FPGAs. I've built up a collection of synthesizable modules and another collection of simulation models. I'm big on re-use. I also do the occasional microcontroller design. The other engineers here do FPGAs and MCUs too. (Board designs are in Altium and not under version control.)

We have one company-wide SVN repository served by a local machine in the closet. Each design gets a part number in our ERP system, so each design is kept in the repo under that part number. The designs have the usual trunk/branches/tags tree. Modules and models are also in the repo, with "modules" and "models" as clever categories, each with its own trunk/branches/tags tree. My designs tend to have a standard tree format: source, testbench, fitter, docs. If I want to use my uart module in a design, I include it using the svn:externals property on the source directory. If I want to use a particular ADC bus-functional model in my test bench, I include it using the svn:externals property on the testbench directory. Design releases and prereleases get tagged after ensuring all externals are pegged.

Common modules for microcontroller designs are put in the repo the same way. For example, there's an lwip project in the repo, and that gets included with svn:external in the source tree as you would expect.

Put another way, our work consists of FPGA designs and microcontroller designs which are small and mostly self-contained except for the shared modules. We are not doing ongoing development of a large software product like, say, Kicad, with developers spread across the world. The products I work on are separate from what the others work on (things talk together at the system level, well above the board level) so it's rare that I will change another engineer's design. The usual thing is to say to the responsible engineer, "hey, XYZ does ABC and it needs to do D, too, so can you add that?" and a short time later, I get an email saying "done."

SVN remains under active development so I don't see it going away any time soon. But you never know. So, help me to understand the git workflow. With git:

Is the common use to have one company-wide (or department, or whatever) repository, or is it common to have one repository per project?

If the one-repo-per-project idiom is used, where are the repositories stored? How is the concept of shared modules and models implemented? Is every module (like a UART) its own repository?

I get that git allows the user to clone a repo and do work on the clone, committing changes to it and then only when the user thinks the work is done, pushing the final change back to the repo. I suppose that private branches in a Subversion repository do the same thing, except that with SVN with every commit you're hitting the main repo over the network rather than the clone on the local machine. In this way, it seems like other engineers can't see the "work in progress" with git because that work isn't back in the main repo.

Thanks. I expect this to be an interesting discussion.


brucehoult:
You'd probably want a different repo for each component, and a repo for each project, with submodules for the components it uses.

Like this example:

https://github.com/riscv/riscv-gnu-toolchain

Here we have a repo for building a complete toolchain for RISC-V. The various components such as bunutils, gcc, gdb, glibc, newlib, qemu are large projects in their own right.

The main purpose of this git repo is to coordinate versions of the other components that are known to work together.

MrMatthias:
There is a great, somewhat dated talk by Linus that addresses your points: https://youtu.be/4XpnKHJAok8

sokoloff:
I’ve seen it done both ways, but the many-repo (repo per project/module) model seems much more common.

We also tend to push to upstream repos frequently. (You can push to a remote repo on a branch if you want others to see/participate in your work without it being on the default branch.)

AntiProtonBoy:
I also vote for the submodule approach, but keep in mind it can become burdensome if dependencies become large. Keep submodule hierarchies simple and flat.

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version