I'm versioning with git a software project that consists in a big common part plus some files that change basing on the particular target machine:

 project-folder
|-cnc_sources
|  |-...(lot of common files)
|  |-specialized.cnc
|-plc_sources
|  |-...(lot of common files)
|  |-specialized.plclib
|-config
|  |-specialized.param

Since I'm supporting three different types of machines, my current solution is a single repo with three different branches, one for each machine, sharing a big common part except for the few specialized files.

I work cloning locally the repo for each machine/branch (this is very handy to test and deploy the software), but this solution doesn't scale very well because I have to manually keep synchronized the common part of all the branches copying the last version of the files in all the other working folders and committing also there.

I wonder if this manual work is avoidable. I also feel that there's something not right: the common files has different history and changesets among branches, and sometimes I find it confusing.

The vendor IDE needs the files in a certain place in the source tree, so I can't gather the common part in a separate folder (for example to create a subrepository).

My need would be to have N branches that share a common set of files scattered in the source tree (can't gather them), but since I'm a git newbie I have no idea about the best practices for my use case, so I would like to know what an experienced user would do in my shoes.

CodePudding user response：

I think you are not doing it correctly. If I were you, I would have a main branch (or common, perhaps) where you have the shared project files.... either at the root of the project or in a directory called common or something like that. Also config dir if it's shared stuff. This is the branch where you keep on working on the common sources.

Then, from this branch you start the custom development for each machine... so, say.... cnc branch is started from common branch. You add there specialized.cnc and commit. You go back to common, the specialized file is gone. You start plc branch from here. Add specialized.plclib here. Add and commit. Now, if you switch to cnc you get the files for cnc, you go back to plp, you get the files for plc. Life is beautiful... now you can work on the separate branches and cherry-pick... and when you work in the common branch, you can merge into the machine-specific branches.

Workflow

Now, if you are thinking that you just can't work on common because the project needs the specifics from the other branches to be able to build/test, then it becomes a problem of workflow.

Say you are on cnc and change a couple of common files and a change in the cnc-proper file. How do you move the changes around? Well, a simple way would be this:

git add the-specific-file-for-cnc
git commit -m "cnc: blah blah"
# at this point all the changes you have pending are for common files
# then you should be able to checkout common and commit there
git checkout common
git add the-common-files
git commit -m "common: blahblah"

Ok, so you committed in separate branches. How do you get the change that you did in common back into cnc which is where you need them? Simple enough:

git checkout cnc
git merge common -m "cnc: merging changes from common"

And the same thing for plc

git checkout plc
git merge common -m "plc: merging changes from common"

This is by no means the only way to deal with it but at least that should give you an idea of the kinds of tricks that you might pull off.