4 Answers
4

You want your central repository to be bare. Say the machine it lives on is named static:

$ ssh static git init --bare /git/myproject.git

This bare repository is a central rendezvous point: it's for pushing to and pulling from, not development.

Do your development on clones of the central repository:

$ cd ~/src
$ git clone static:/git/myproject.git

Even if you're on static, work in a clone:

$ git clone /git/myproject.git

Although you're the only one working on this repository, get in the habit of doing your work on what the git documentation calls topic branches. An immediate benefit of this is that it keeps a clean master, that is you can always pull from your central master branch into your current local repository's master with no merging.

That may not seem like a big deal, but it gives you the freedom to leave the project as represented on that branch in a partially cooked state, or if your cool idea turns out to be a flop, you can easily throw away that branch without breaking anything else in your project that's already working on other branches. Infinite free mulligans!

Maybe you go home that night and added a new feature. The next morning, you

$ git checkout master
$ git pull

to update your local master to reflect what's in the central repository.

But now say you've fixed the foo bug and are ready to include it in your master branch. First you want to integrate it with the changes from last night:

$ git checkout fix-bug-in-foo
$ git rebase master

The rebase command makes your repository look as though you fixed the foo bug on top of last night's new feature. (This is sort of like svn update, but more flexible and powerful.)

Awesome answer, nails down all of the issues at hand.
–
DanDec 10 '09 at 21:25

My git install is not accepting --bare as an option to git init (old version??), but I worked around it by cloning --bare my existing repo, and then manually editing the config files a bit.
–
Alex FeinmanDec 11 '09 at 13:58

If you're running git 1.6.4.x, it's git init --bare with no other arguments. It will use either the current working directory or GIT_DIR environment setting if set. I believe you need git 1.6.5.x for it to take a directory argument.
–
Darren HallDec 11 '09 at 15:32

3

That's the best git workflow explanation I've seen so far for the work that I'm doing.
–
Greg GrahamDec 12 '09 at 4:23

If you have a central server with a central git repository, that repository should be a bare repository. Bare repositories don't have working copies of the files in them. Consequently, if you are working on that central machine, you don't work with the central repository directly, but with a local clone.

This answer is similar to gbacon's answer, but takes an approach that you already have a local repo setup, and want to create a remote master that is treated as a central repo. It's just adding details from a different approach.

I use git to store my dot-config files. I push and pull from what I consider a 'central repo'. It's quite convenient to reset all my dot files through multiple computers.

You'll likely have to set your git config --add branch.master.remote origin so git pull doesn't complain that you're not being specific enough. The other alternative is to set your master branch to --track the remote origin. Useful if you have multiple branches.

I was just researching this same problem today. This blog post has a lot of discussion on the issue, but the majority opinion is to do what Manni said. Look at a comment on the post by David French for some other possibilities, including what to do if you do end up mistakenly pushing to a repository that has uncommitted work in the index or working tree. "git reset –soft HEAD^" will back out the pushed change without disturbing your work.