git checkout master
if you're not working with a bare repository.
Depending on your needs, a bare repository might not be what you want.
I'm going to assume that since creating a bare repository requires git clone somePath --bare
you're probably working with a standard git repository without any of the files checked out.
Here are the use cases:
backup only: bare repository is probably
better, because you will only have
the space taken up by the repository,
compressed, and not -also- the space
from a working copy.
copy with full access to files, doesn't have to be up to date
all the time: simple cloned
repository, use git reset
origin/master
to wipe whatever is in the working copy in favor of the pushed changes.
copy with files is continually up to date: This is the trickiest case, because git doesn't update the working copy on push by default. Did a quick search, and one method mentioned is using a post-update hook: http://jennyandlih.com/pushing-remote-git-working-copy . Note that that probably isn't going to allow editing on that copy and replacement on push unless you delve into the stash-pop thing, which you can figure out on your own.
My recommendation, ( I do this all the time ), update the clone manually when you need to:
Create a simple clone (non-bare). Then git branch staging
and git checkout staging
. You now have a working copy, though you'll have to update it manually yourself by git rebase origin/master
when you want to get changes. You can push changes from staging to master just fine. Just be aware that any "master" branch in that repository is probably going to be screwy with changes that get pushed to it, and effectively shouldn't be used or relied on.