I am contemplating a git repository structure with a mix of open and closed source software. The current situation is somewhat of a hodgepodge. Multiple developers are working on the project, geographically distributed. The authorative repository is on a private GitLab server.
The directory structure would be something like this:
repo
|-- core (open source)
|-- moduleA (open source)
|-- moduleB (open source)
|-- moduleC (closed source)
In reality there are a lot more modules, but anyway.
I have evaluated submodules as well as subtrees, and they do not fit our development process. I found this related question, but the answers there do not satisfy me either: Proper Git workflow for combined OS and Private code?
Separate repos is the current situation, as it was before a migration from svn, and we're not satisfied with that either.
What I see as a workable solution, is one big repo, and have a Jenkins job that runs git subtree split to split out the open source modules into separate repos, and then push those to the outside world, on GitHub. This would be the easiest way to work for the development team, and would only require a one time setup in Jenkins. I found a step-by-step description in Detach (move) subdirectory into separate Git repository.
But now come my actual questions.
When the Open Source code is on GitHub, we will get pull requests from outside contributors. Their patches will be to the root of a repository, while in the authorative private repository in GitLab, and also on the developers' workstations, the changes should apply to a subdirectory.
- How do I integrate a pull request for a root to a subdirectory?
- When the code is integrated, and Jenkins splits off the code between Open Source and private, will GitHub pick up that the pull request is merged and automatically close it? I think I can reduce that question to: what does GitHub use to close a pull request? I think it should be safe, provided that the answer to question 1 provides something that is reversible.
EDIT: I'm thinking about a slightly different flow:
git subtree splitto split out the open source modules into separate repos.git subtreeto recombine the open source modules into a new repository.- Push that new repository to GitHub.
This has the following advantages:
- Directory structure of the internal GitLab repo and the external GitHub repo is identical (except of course for the closed source stuff)
- Only one repo needs to be published to the outside world.
- I will be able to merge pull requests with
git cherry-pick.
Disadvantages:
- It's a bit of a convoluted setup.
- Pull requests will still not be closed automatically, probably.
