Right now, I'm trying to get a handle on working with remote repositories. In theory, because git is fully distributed, you don't need a central repository. However, I want to use remote repositories to (1) ensure my data is backed up (I have access to a Solaris server with a RAID and regular disk backups), and (2) allow easy synchronization of my work between the various machines I use (office PC, laptop, etc.)
The main idea with git is that repositories and working directories should be inseparable; all work should be versioned. Being a distributed VCS, git gives you lots of ways to synchronize changes between repositories. All well and good.
However, weirdness ensues when you consider what git should do when you push (commit) changes from a local repository to a remote repository. If you push into a remote repository that has a working directory checked out from the branch that you are pushing into, git does weird things. I won't even attempt to describe what happens, since I don't understand it. Suffice it to say that it's not a useful behavior.
One solution, as helpfully pointed out by the git cvs migration help file, is to create the remote repository as a "bare" repository, meaning that it does not have an associated working directory. So, the series of steps is something like:
server$ cd /some/directory && git --bare initThe "origin" in git push origin evidently refers to the remote repository from which the local repository was cloned.
client$ git clone username@server:/some/directory
[ add some files ]
client$ git add files...
client$ git commit -m"Added some files..."
client$ git push origin
