I'd like to get some advices to best handle and version control projects, which exhibit the following structure:
From a parent project (shared among many projects), I need to get a given directory structure and files, i.e.
.
|-- modules/
| |-- file_1_parent.py
|
|-- controllers/
|-- file_2_parent.py
From this parent project, several children dependents are derived, which add files to the directories.
The situation then could look like the following (the name of the projects to which the files/directories belong are in parenthesis)
.
|-- modules/ (parent project)
| |-- file_1_parent.py (parent project)
| |-- file_1_child.py (child project)
|
|-- controllers/ (parent project)
|-- file_2_parent.py (parent project)
|-- file_2_child.py (child project)
To be concrete, in my case the parent project is web2py/django project, from which I want to derive several subprojects.
The question is now,
- How to version control each projects?
- Should I have a repository for the parent and the child projects separately?
- Should I some treat the parent project as some kind of package/library?
I thought about the following approaches:
- Using
git submodule
orgit subtrees
: That doesn't work because I of the very rigid directory and file structure I need from the parent project - Multiple
git remotes
in the local project, i.e. twogit origins
, one to the parent and one to the child project: What speaks against this solution, is that in order to deploy the project somewhere, I cannot just simply rungit clone
but have to manually set the multiplegit remote -v origin
. - Treating the parent project as a library, which I install via a packet manager, and then either versioning the installed files within the children repositories or put them to
.gitignore
: Maybe a not solution, which is not so bad, but I don't know a tool for accomplishing that. Maybe there exists a tool which can install a given version from a github repo via some command likesome_paket_manager install path/to/git/repo==v.0.0.9
- Copy&Paste of the files from the parent project: I'm trying to avoid that manual work.
Just do ordinary merges, the only thing you have to remember is when/if you merge back work on the parent's files done on a child branch to delete the child-project-specific files and changes from the merge result. Git keeps things straight so long as you record what you're actually doing.
git diff --diff-filter=A --name-only @
will show you all files added in-flight, e.g. anything brought in by a no-commit merge, so do a no-commit merge, fix up the results to include only the changes you want, commit that, done. Once you get a handle on what fixups need doing you can automate a lot of it, but it won't always be just delete every new file.