Updating a working tree to Git's HEAD

Question

I think I said that all correctly.

I've got a staging server with Git on it, my buddy and I push changes to that Git repo from our local clones of that repo, when we're ready to make something public, we tag it 'n all that, but then I have to do a git reset --hard to update the actual files on the server to HEAD, which seems a bit strange to me.

I think the issue might be a fundamental misunderstand of how git works. Usually I branch my code on my local repo, work on it, then merge it to the master repo, then git push, is this correct?

Sorry, I'm quite a newbie when it comes to git, any resources for working with remote git repos would be greatly appreciated, thanks!

Answer 1

An excellent resource is the Pro Git book by Scott Chacon. It can be found online at http://progit.org/book

Answer 2

I don't fully understand your question, but I can recommend you this workflow that was very useful for our team. In this other post you will find scripts to automatize it, but I find that it is best at the beginning to run the full git commands, to interiorize the process.

Also, this resource about hosted repositories and gitosis is very good. This practical links, plus reading a book about git, was very useful for us to be able to adopt quickly git.

Answer 3

It sounds like you're pushing to a non-bare repo on your server. When you push to a repo, the repo's internal state is changed, but the checked-out files are not updated, which is why you have to do a git reset --hard (or a git checkout) to checkout updated copies of the files. It is recommended to only push to a bare repo for this reason. You can create a bare repo using git --bare init or git clone --bare.

Answer 4

Zack,

I think the problem is that your remote is not a bare repository (i.e., it has a working tree associated with it). You should never push into a non-bare repository, because this updates the index/cache, but not the working tree. The (non-bare) repository working tree only updates correctly when you run "git reset --hard" because this command changes the working tree state to reflect the state of the last commit, i.e., the commit you just pushed.

The remote repository should be created with the "--bare" flag, i.e., you should create the repo by calling:

$ git init --bare

and then you can correcly push your changes into it.

I describe a development workflow using multiple repositories here, while I provide scripts/aliases/tips to in the second part of the article.