Groking git remote usage

Question

I've been 'playing' with git on my own machine for 6 months now, and really loving it.

However, I'm finding it difficult to really grok how I would use it in a team/enterprisey environment. (I'm wondering whether Eric Sink is right).

I started out trying to install a git server on windows, but that didn't go too well.

So I wondered about just setting up a second repository on my own machine and starting to get a hang on pulling/pushing to that.

Do you know of any good articles for starting 'simple' like that, or do you have any tips on grokking the next level?

Answer 1

Try Git Magic, which was the first thing I read when learning Git, and which was great for helping me understand what I was doing -- chapter 3 is all about dealing with more than one repository.

Answer 2

You may read some articles on Git daily work flow, and I would like to recommend two:

• http://geewax.org/2009/11/21/agile-git-workflow.html, Agile git workflow
• http://nvie.com/git-model, this one is about branching and cooperation

Answer 3

If:

• your main computer is accessible through a shared path (\myMainComputer\MySharedDirectory)
• or you have several repo on the same computer

You simply can:

• git clone --bare /path/to/your/first/repo
• cd /path/to/your/first/repo
• git remote add bare_repo /path/to/bare/rep
• (work, commits)
• git push bare_repo
• (if other have pushed to bare repo as well)
• git pull bare_repo

In other words, the file protocole is supported as a legitimate URL for remote repos.
See git fetch, section URL:

For local repositories, also supported by git natively, the following syntaxes may be used:

/path/to/repo.git/
file:///path/to/repo.git/

Answer 4

This is the workflow that I try to stick to, with scripts to facilitate this workflow given here. The basic idea is to have at least two repositories:

(a) a general "central" remote repository, that serves as the canonical "primary" repo for all developers; code pushed here should always be (more or less) unbroken and functional, passing all tests, etc.

(b) a personal "work-in-progress"/development remote repository, which serves as a remote back-up for local or sub-team development. Code here can be in any state. Taking full advantage of Git's cheap branching, generally the wip topic development line should be in their own branches (as described in the above links), until ready for prime time. When the time comes around, merge into your local master, and then push this to the "primary" repository, and delete the wip branches from both your local as well as your personal remote development repos.

Optionally, you might want a third repo, for public (i.e., non-project team) consumption.

You also may want to look here for a description of a similar yet different workflow. By the way, the Pro Git book given in the previous link is, in my opinion, the single best Git resource currently out there.