I've got myself and two other people working on a project that's housed in a git-repo.
The layout of the project looks like this:
./
--DataSheets
--Electrical
--FW
--Mechancial
One guy works on Mechanical I work on FW Me and another guy work on Electrical Everyone works on Datasheets
I'm sure everyone has seen this at some point: http://nvie.com/posts/a-successful-git-branching-model/, and so far, that's what I've been trying to use...
I've got one branch for each, and I make sub-branches off of them for each change... Once the whole project comes to a good stopping point, I try to bring everything up to date and merge it into dev...One day, if anything ever leaves the lab, it'll get merged into master, but that hasn't happened yet.
I thought this would be a good way to go, but after 6 months of trying to maintain this, I've got a few issues that I run into constantly that I'd like to address:
I feel like there's a lot of overhead when it comes to keeping each branch up to date relative to the others...For instance, If I change the Electrical folder, that has PCB/schematic stuff in it, it almost by default will affect FW in some way. That means that the when working out of the FW directory, I need to make absolutley sure that the FW directory has been rebased with the electrical directory. This feels kind of foolish, since no changes in the FW branch should affect the Electrical branch and vice-versa, but failure to remember this can lead to working on a new FW with an outdated HW reference document.
I've done some reading about submodules, and those do sound like they could be applicable to this situation. Is this a path worth considering? Again, this whole project is in one repo, because everything is in fact related to each other, but all of the 4 elements listed above are independent in the development workflow, which is what I'm really leaning on git for during this time.
This feels kind of foolish, since no changes in the FW branch should affect the Electrical branch and vice-versa
IMHO this is somehow incorrect. While indeed they may not technically affect each-other, a change in any of them may cause problems to the system as a whole. Which is reflected in your other statement:
If I change the Electrical folder, that has PCB/schematic stuff in it, it almost by default will affect FW in some way
So my recommendation would be to always have everyone working on a particular system change to work in the same project (sub)branch. This way you ensure all components are in sync and you can verify the changes at the system level before merging any of them back into the mainline.
I'd also advise against having the dev branch being a child of the master branch if planning to use master as you releasing/shipping vehicle. See my reasoning at How to get rid of develop branch for simplified Git flow