private and public git repos for an OSS project of mine

there are similar questions here in stackoverflow, but none is exactly what I'm going to ask, at least none I could find.

I'm starting an OSS project, and I want to share it publicly on github. But I also want to have a private remote repo in a server of mine. The public repo is for the public version of the project, and the private repo is for an internal version, not ready for release. Obviously the public repo will always be a possibly old version of what's in the private, and stuff in the private will not be pushed to public until they're ready.

I searched over the net and I found some guys who came up with a workflow very similar to what I want. This is the link to the blog post where they explain everything: http://www.braintreepayments.com/devblog/our-git-workflow

I like everything about it, except for the totally squashed commits that go into the public repo on github. I also dislike a bit the part where, after merging into public, they have to re-merge everything back into master and release branches, even though, as they positively assert, there are no real changes to make there.

My question is, is it really bad to have a public repo history that's just a series of squashed commits that has lost all the details of the logical changes within it? It seems unnatural to me and I have not seen this a lot, but maybe it's not that bad, or else I can adopt this workflow without the --squash parameter.

Also, what about the phase of re-merging back 开发者_StackOverflow中文版from github_master to the master and release branches? I guess they need it because of the squashed commits. If I decide to not squash, then I think this is not needed, but I'm not sure.

Or else, can anyone suggest a different way to do this? Take into account that I would also possibly want to accept contributions from other people if someone forks my github repo.

If you simply don't want the unreleased changes visible until they're released, and don't mind the intermediate commits becoming visible once they are released, then this is fairly simple. You can just treat your private branch as ... well, an ordinary branch. Just make sure the private branch name doesn't exist on github (but does exist in the private repo), and the default push settings should take care of things.

If you do want to hide history, though, well, that's what that squash-based workflow is all about. In this case, if you do merge external branches, it would be best to avoid squashing their commits.

Instead of going down this route, why don't you just push all of your changes to Github, but in a branch other than 'master' - this way, people will see the "safe" branch by default, but you won't lose the history.

If you really want to keep your dev branch a secret, you could do what I'm describing, but don't push the dev branch - the dev branch would be local to your machine only.

You are fine in your line of thinking. You don't need to squash commits if you don't want to. As per your private branch, you still want to have that pushed somewhere so you have a backup. You can push it to a bare clone on a USB stick or a place like unfuddle.com where you have free private git repo space. You would then have 2 remotes set up: one to Github and another to either a usb stick or unfuddle.

Also, keep in mind that larger files like 3rd party DLLs may blow up the size of your repo, potentially inhibiting you from pushing to unfuddle for free. In this case, use submodules to keep those files in a public github repo and only store your actual source at the higher level repo which you would push to unfuddle.

Hope this helps.