As both the existing comment and answer-so-far said, it seems to be more usual to set up an authoritative, "bare" repository to which contributors push. This makes it clear that, e.g., branch
devel on the designated Remote-Repo-Site is "the"
devel branch, and all others are merely pale weak imitations. :-) This is particularly common in corporate environments. It has the advantage that there are clear lines of authority.
That said, though, there's nothing stopping you from building a pure peer-to-peer system in git. Here, each git repository stands perfectly well by itself. Repo RA on host A is just as good as repo RB on host B.
To make this convenient, on host A, in the repo copy there, you can create a "remote" for host B. On host B, in the repo copy there, you create a remote for host A. Then whichever system you are on at the moment, you can simply
git fetch remote (where
remote is the name on that host for the other host you're curious about).
In fact, you can go on to extend this model to having many peers, and perhaps several "more-authoritative" points at which multiple peers might synchronize. That is, you can build a hybrid of authoritative and peering repositories.
This works because all git repos are basically identical in structure. The only thing that makes an authoritative repository "authoritative" is that those who use it, treat it that way. If I have my repo and get stuff from you and believe that it's better than my previous stuff, well, then, you must be the authority here. If I choose not to believe you then I become my own authority.
It's important to note here that the "bare"-ness of a repository is not part of its authority (if any). In fact, the only point of a bare repo is to make it simple to
git push to it. If you push to a repository where someone is working, they may believe they're at commit
devel, but now their
devel points to commit
905c4fd instead.1 A bare repository has no working tree, so by definition, you can't mess with someone's in-progress work in the working tree on that bare repository.
Meanwhile, the main point of having a repository that's simple to
git push to, is to have a mutually agreed rendezvous point, so that if there are a dozen peers developing away on various development branches, they don't have to all know each other, set up remotes for each other, and grant each other access to their own systems.
It is these two properties that make a bare repository ideal for building authoritative structures. The "worker bees" clone the authoritative system, do their work, then (attempt to) push it back to the authoritative system. All relationships are pairwise, and no worker-bee ever has to talk directly to another.
But you don't have to do it this way. For instance, I have my laptop and desktop and set them up as peers of each other. From the laptop I can just
git fetch desktop, and vice versa, as needed. The one drawback I find is that I can forget that I had work in progress on the laptop (or desktop), that I had not committed, and now I'm at the other one, so now I can't get to my work-in-progress without ssh-ing to the other machine first. But that's usually not a big deal.
1Mercurial escapes this by keeping track of where the "next commit" goes in a different way, so you can push to non-bare repositories, even if they have the pushed-to branch checked out. Git could do the same thing but it would require the ability to create a new branch name on the fly, or to put you into "detached HEAD" mode when someone pushes to the branch you're on.