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

No.

Remote repository can be your friend computer where you grab code from while central repository is where everyone push their code to.

Central repository is used for backups, builds, permissions and so on.
You can have 1 or many remote repos (for example if your team does not use central repository and you simply connect one to other directly (ip)

Answer 2

Maybe.

Remote repositories are a fundamental feature of git (though you can use git without a remote). "Central" repositories are a matter of project organization.

A remote git repository is any repository other than your local one; you can push, pull, and fetch to it from your local repo.

If you have a number of developers working on a project, each one will have his or her own local repository, and you might have a single "central" repository to which each developer can push and pull. This can give you the advantages of a non-distributed DCVS while still letting each developer make local changes. The "central" repository is then a remote repository for each of the developers. (It should be a "bare" repo, since pushing to a non-bare repo is limited.)

With a central repository, you can have a single definitive location that defines the current state of the project. Other organizations are possible; for example, developers can share changes by sending each other pull requests.

Answer 3

A central repository scheme mandates that everyone get their updates from one source, whereas a DVCS doesn't have that restriction.

The terms are easily conflated, because most workflows mandate that there is a single remote repository for every collaborator to base their work off of.

However, a remote repository is nothing more than another machine which you can place your Git history on. In practice, you can have a large amount of remotes, and be able to interact with them at will.

Answer 4

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.