2

We have a two developer team and want use git.

But I don't know which way to use git is better:

  1. Model with bare-repo. Here there are two local repos + one bare (main) repo throught with 2 developers are sync their commits.

  2. Model without bare-repo. Here is two local repos, one of which is set as a remote to other.

I wonder what model is better to use and why? And especially what kind of difficulties can be while I would like to use second model.

sunnyrjuneja
  • 6,033
  • 2
  • 32
  • 51
Yekver
  • 4,985
  • 7
  • 32
  • 49

2 Answers2

2

You generally don't push into people's repositories in which they work, that would be troublesome. Bare repositories are for pushing into, while non-bare repos tend to have a developer in front of them and he's responsible for managing it and pulling into it from places.

So: A model without central repository would contain two non-bare repos (each having the other as remote; consider the remote list as a repository's "address book").

During work, you would periodically pull changes from each other, but that would make some problems:

  • some additional communication is needed (when to pull, which branches to pull)?
  • you'd need to make sure that both repos are available (so that developer A wouldn't need to wait for developer B to turn on his PC whenever he needs to pull something)

A bare, central repository helps with that:

  • It's supposed to be always available
  • You decide which branches are in a "push-ready" state, what to share, what to keep to yourself
  • It serves as a synchronization point: there's always the current version so in case of divergence it's always clear who's supposed to merge.
Kos
  • 70,399
  • 25
  • 169
  • 233
-1

For two developers, it´s better the first option. In the second option, both developers have their own working copy with modifications and this can cause problems or confusion when pushing. Review this Push to a non-bare Git repository

Community
  • 1
  • 1
Chuidiang
  • 1,055
  • 6
  • 13
  • 2
    If they're going for the second option, then shouldn't be using push at all, only pull. Then at any point they'll need to decide which repo they want to be canonical. – Andy Nov 02 '12 at 17:46
  • Right, the second is just about pull requests and communication. That’s how it works on code collaboration sites, for example GitHub (except that every participant has an own bare repo for his own fork). – poke Nov 02 '12 at 17:50