I've got a staging开发者_如何学C 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 misunderstanding 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?
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
.
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 correctly 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.
精彩评论