Using git right (for private repo website code)?

Question

This may be a question about convention, best practices and/or personal preferences:

So I'm a git noob, and my website code is not worth sharing, so I'm not using github or the like.

Knowing that git doesn't need a central repository I thought: great, my workstation and the server are the two nodes, and I'll just push changes from my workstation to the server.

When I started, the code was only on the server, so I:

1. On server: git init
2. On workstation: git clone me@myserver:path/to/repo
3. Merrily made changes and committed locally
4. On workstation: git push me@myserver:path/to/repo

I got strange results. The files I had added locally appeared on the server, but changes to existing files weren't reflected.

I then read a warning against pushing to a remote branch that is checked out. So the new setup is:

1. Ran git clone --bare to make a bare repository
2. Put the bare repository on my server (~/repos/mysite.git - not a public folder)
3. Code local and: git push me@myserver:repos/mysite.git
4. On server: git pull ~/repos/mysite.git to get the latest

Is this correct? Is it logical? Is it what you would do?

Answer 1

Your new setup is the correct way to set up a server repository.

Refer to the Getting Git on a Server chapter on the Pro Git book for more information.

Answer 2

No matter what you choose to do, you might want to automate it a bit using git hooks. Hooks are a set of scripts which git will execute on certain events. The relevant one here is the post-update hook (in the server's repository). In a normal repo, hooks are in .git/hooks, so in a bare repo they're in hooks. That directory probably currently contains a lot of example hook scripts (named *.sample in recent versions). You'll need to make one called post-update, containing whatever actions you want taken after the server is pushed to (e.g. cd to the other repo and execute the pull).

As for the specifics of your solution... you're doing the right thing by not pushing into a checked-out branch. The only possible issue with what you're doing is that the server ends up with an extra copy of the repository only used to check out the files. If you decide you don't like this waste of disk space, I'm pretty sure this would do what you want:

git --work-tree=/path/to/checkout-dir --bare reset --hard

This tells git to reset to the proper state, using the given path as the working directory, but keeping in mind that the repository is actually bare. I haven't personally done this kind of thing before, but it seems to work on my little test!

A note: if you decide you want to do push into a checked-out branch anyway (only if the repo on the server will never be used for anything but pushing to and checking out a copy of the files)... if you are totally sure about this, you can set receive.denyCurrentBranch to false in the server's gitconfig, execute git reset --hard on the server, forcing its working directory into the state it should be in.