Are the remote and centralized repository the same thing in git?

Question

They seem to be synonyms, but I can\'t tell quite yet.

Basing this off the Subversion vs. DVCS debate here.

Answer 1

Often enough -- and often enough more often than not -- a "remote" repo is just another one of yours, in the path right next to your original clone or it's on a tmpfs and relying on another for object content or whatever. Yes, you can push to a working repo, it's essential to some workflows for working on parallel branches in parallel. It's a great way to push hotfix branches.

A git repo takes on any role its administrator wants it to have (and the team cooperates with, but that's a separate issue ...). If you want a single central repo, make a repo and tell everyone that's "central".

I hear some projects have multiple repos for different purposes, a qa repo where the qa team tests branches and does merges and tests their results and either rejects the commits for rework or pushes to a burn-in/stabilization repo before anything hits production.

Linux has a huge batch of repos dedicated to beta features are being banged on and the various administrators pull what looks good -- and these repos are set up by whoever wants to start a project. If you've got a big enough team that can be an awesome way to get collaboration on projects the intended users might take enough interest in to want to help. It's the perfect way to have interested helpers fix the inevitable idiot oversights in alpha code or demonstrate their priorities for new features by implementing them (or at least proof-of-concept's for them).

If having multiple repos for separate lines of work wasn't good, dvcs's wouldn't be taking over the world. Why insist that there be a separate person for each repo? Branches are for merge prep and small-stuff exploration. Clones are for project work and major-surgery sandboxing and noise isolation and just dinking with stuff that might be useful but you're likely enough to want to just rm -rf the damn thing. If you can do it all conveniently in a single repo, that's great. If you can do it more conveniently with several, do that instead.