When open-sourcing only part of a codebase (say, on GitHub), it seems like a common approach is to have two repositories:
- A private repo (with branches where all code development happens)
- A public repo (with a main branch where all the finalized code is merged/pushed).
This format, however, assumes that all the private code will eventually make it to the main branch of the public repository (since git merge carries all of the changes made to a branch). If I have files that should always remain private (e.g., dev scripts that are only useful to me), how can I keep them private when merging changes to the public repo?
After reading a few SO answers & checking other forums, I found three (non-standard) ways this can be achieved:
Perform a selective merge. My concern with this approach is that I believe it breaks the git commit history. For instance, if I run a standard merge command later (or rebase changes from an external collaborator on the public repo), conflicts will be flagged on the files that were selectively merged over (since selective merging isn't a real merge).
Simply tell git to stop tracking the files that I don't want to merge. The obvious drawback is that new changes to these files won't be backed up to GitHub anymore.
Only create files in the private repo that, eventually, are intended to be merged with the main branch of the public repo. All other dev scripts should be kept in a third, separate repo (which, for convenience, can be turned into a submodule of the private dev repo).
Are there other options I should consider? I'm personally leaning towards option #3. Thanks
