Git如何通过远程仓库/本地仓库推送和拉动？

Question

I come from SVN and I am not understanding how the whole Git thing works. I've created a remote repo, cloned the repo in my local machine - if I make changes to files in my local machine and try to push those files to the exact remote repo I cloned from I get an error like this.

remote: error: refusing to update checked out branch: refs/heads/master

I browsed through some SO questions regarding the same issue and the most popular solution was creating a bare repository and then committing to it. So what happens when I clone from that new repo - would this happen again? Should I keep creating new bare repos for each commit from my local? I'm confused and it will be great if someone can point me in the right direction. I think I am doing this completely wrong.

Exact steps I am following: 1) Created a directory in remote server - init as git repo 2) Copied all contents I needed into the server 3) Added the content into git and committed them there 4) Cloned the git repo from remote to my local machine 5) Made a change to a file in my local, added the change to my local and committed it. 6) When I try to push changes made in my local to remote using: git push origin I get the error message. I'm providing the whole error message below.

remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error: Auto packing the repository for optimum performance.

remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
 ! [remote rejected] master -> master (branch is currently checked out)

Answer 1

The bare repos are the only ones that you should generally push into, because a non-bare repo means there are copies of the files checked out that would need to be updated. If you have two repos that you control, and you want them both to have checked-out copies of the data, then use git pull from both locations to pull from the opposite one. On one side you can do a clone, but on the other you'll have to use git remote add in order to create a remote to pull from.

A bare repo will let you push into it, because you know you're not messing up a checked-out copy's in-the-middle-of-doing-something notion.

If you haven't read the man pages for 'gittutorial', I would start there as they're wonderful places to start learning.

As for a good working model, I often have one (server) machine with a bare repo in it, and often a clone of that repo on multiple other machines including the server itself. So if I'm working on the repo on the server, I don't work from the bare repo (obviously), I clone it and work somewhere else and push into it. That lets each clone push into the "master" bare repo and pull from it. It makes synchronization a bit easier, especially when some copies are not always online.

Note: there is no "wrong way" or "best way". Each person has their own preferred way of dealing with repositories. And that's one of the better parts of a distributed repository system (git or otherwise): it lets each user do what works best for themselves.

Answer 2

Shared / remote repositories use a bare format, meaning they have no working copy. Subversion is the same - the central repository does not have a working copy. Working copies are created via checkouts in subversion, and via clones in git.

The problem will not continue to occur if you change the remote repository to bare format.

The workflow is not significantly different than subversion, just an extra step (or two, depending on the commands you use)

Make changes
git add (to add the changes to the staging area)
git commit (to save the changes to the local repo)
git push (to push the changes to the remote repo)

When you want to pull changes from others from the remote repo, you do a "git pull" which functions similar to "svn update."