Well this is always a little complicated, but some notes on doing this:
- If you are non-profit, Github actually provides you with a free organizational membership. You just send them an email and then a copy of your IRS tax status and you get upgraded.
- When you create your first repos, you will find that by default you cannot fork private repos. You have to change the settings by going to the organization and looking through settings. I’m guessing this is a security issue because you could fork a private repo and then make the fork public which would be very bad.
- So why fork a private repo so you can create a submodule. The main reason is if you are a consultant or have multiple organziations that you work with. If you have a single master repo for your personal use, you can make each one an external submodule. Makes it very convenient to keep everything in one place and you can reproducibly build your development environment too.
- Use submodules. There are two steps here, create an
externin your master development repo and then there do a
git submodule add firstname.lastname@example.org:yourpersonalrepo/thatrepo
- Now create an upstream branch so you can make changes locally, to your private copy and then push changes as needed to the master. This models the way you commit to really external things internally. So this looks like moving into the
newsubrepodirectory and running
git remote add email@example.com:upstreamorg/thatrepo
Now the workflow is pretty standard:
- Hack away at your personal branch with
git checkout -b rich-newstuffand then you continuously update your private branch and then the master branch.
- When you are ready to push this into the organization, you rebase everything and the do a
git push upstream yourbranch:masterand this will make the changes upstream. Actually, you will normally do a pull request, but you get the idea. You have two layers of isolation. Your dev brancy, your private master and then what is upstream.