On 29.10.2008, at 22:09, jgeiger wrote:
> > I'm trying to find a best practice for hosting a project that needs > private development, but also needs the code to be publicly > accessible. > > I'm thinking about setting up 2 repositories, 1 public, 1 private, > doing all the work on the private shared repository, and when creating > a "release", copying the code from my local private to my local > public, committing and pushing. > > Essentially I'm trying to hide the daily internal workflow of the > commits and changes while providing a public base that can be > controlled for things like database settings, keys, etc. Technically you can achieve that with a public repo on GitHub, and your local repo. Any changes you make to your local repo are going to stay that way, and then, if you feel like it, you can push to GitHub, thus making it public. That said, if you're working in a team (or simply want a server for your repo, for all the various reasons), your approach should work fine. You set up your private repo for normal pushing/pulling, and you can add your public repo as an additional remote, to which you can then push if you have a release ready. Just out of interest, why do you want to hide the internal workflow, but make the code public? Since you're going to have a public repo anyway (that anyone can fork), a private repo doesn't make too much sense (unless I'm missing something). No one but you can push to your public repo anyway, unless you explicitly specify that other people can have access. g, Markus --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "GitHub" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/github?hl=en -~----------~----~----~----~------~----~------~--~---
