How to best set up a “central” git repository from

Question

I know git is distributed, and frankly I like that property about it.

The situation is that I have been a sole developer of a piece of software that I have been managing by git since its inception, on my local storage. This has always been so - in other words, only a single repository exists currently, where I commit and merge stuff and keep the master branch in "public release" state.

I am now on the verge of giving up exclusive control of the project and will be sharing its source code base with other developer(s), who will be committing changes of their own. And so I need to distribute my copy of the project to others. Naturally, I would like to keep committing my future work and being able to review and merge others work back into my copy as well - a job git supposedly was created to do.

An aspect to the problem is that neither mine nor the other developers computers are public (i.e. will be reachable as servers by ssh or similar service) and I have trouble imagining how feasible it would be for me to pull and merge changes from their copy of the repository into mine, and vice versa. The project includes an intranet machine however, which we can use as a repository host, and at this point I need a piece of advice on how best to set this all up.

Neither of developers (including me) should be assigned as the benevolent dictator of the project, however, for the sake of management, I will be tasked with making sure that some sort of master or other branch is available to checkout public releases from. But I also don't know how many other developers will be joining, i.e. how many distributed copies we will have, and so perhaps a "central"/master copy of the repository will be needed, which I will solely author.

I am afraid I cannot really see the big picture clearly here. How best to do this?

Answer 1

If you already have a candidate server in the intranet, there's nothing wrong with using that. Just set up a bare repo there, push the existing repo there and start using it as a central repo. That's all there is to it - there'd be no dictators, but the central host would be a central "master repo".

I know it sounds like the traditional centralized model, and it is that, but we've been doing that a lot with git and it works really well.

If you want to have your repo as the master though, you could just open up that master repo to others, but have a separate production branch or a repo. Then, you'd only merge from master to production branch/repo the stuff you've approved of.

Edit: Practical instructions on how to do the setup are detailed for example here. There are instructions guiding all the way through. Only thing I would add is that instead of git push origin master, for the first push, you might want to use git push --all origin instead as that would push all branches, tags etc, and not just the master branch.

Answer 2

Just agree to a workflow with the other devs. I use branch-per-feature and wrote up my workflow here: http://dymitruk.com/blog/2012/02/05/branch-per-feature/

Other than that, bitbucket provides free private repos so you don't have to worry about setting up your own server. You can also use github if this is meant to be public - or get a private repo from them although it's not free.