4 ms·
We have the same issue, except in both directions -- we use open-source projects as part of our software, and have also open-sourced a component that we develop
by wallstprog 6y ago
We have the same issue, except in both directions -- we use open-source projects as part of our software, and have also open-sourced a component that we developed, so we need to be able to go both ways.
The following seems to be working reasonably well so far:
- Each component has its own internal repo (in our case, we happen to use BitBucket). This repo contains any bits that are either proprietary and/or specific to our environment, like build scripts, integration with internal CI, etc.
- The open-source part of the component is hosted in an external repo on GitHub.
- The internal repo includes the contents of the external repo using git submodules (https://git-scm.com/docs/gitsubmodules https://git-scm.com/docs/gitsubmodules).
We use a convention re: branch names:
- For projects that we don't own, "staging" is where our changes go before being submitted upstream as PR's.
- For projects that we do own, "staging" represents the current development "HEAD" -- our internal "master" branch includes the "staging" branch from the external repo.
- In either case, once a change has been approved for production use, it is committed to a release branch that is used to drive production builds.
Git submodules have a couple of features that make this easier:
- Each branch in the internal repo has its own .gitmodules file, which identifies which branch to fetch from the external repo. The .gitmodules file is an ordinary text file, and is managed just like any other file in the repo.
- Updating the submodule code in the internal repo is done by recording the hash of the specific commit from the external repo. This lets us control precisely which code from the external repo is included in builds (either development or production builds), and also provides an audit trail.
We used subtrees initially, and if there's not much traffic back and forth between the internal and external repos that can work, but it breaks down quickly as the repo becomes more active.
- vaughan 6y agoThe downside of submodules is you lose the ability to easily branch across all packages/repos and then just commit. You could branch the other project but then you have to coordinate this yourself. There is a project called Meta that can help but to me feels like it can quickly get out of control. Do you find this a problem?