3

I have a remote and a local git repository.
Local repository is clone from the remote.
When I modify my local repository and commit to the master branch.
Then I run "git push" to remote repository.
But it failed and output the following msg. 

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: 
remote: error: You can set 'receive.denyCurrentBranch' configuration variable t
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing int
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 som
remote: error: other way.
remote: error: 
remote: error: To squelch this message and still keep the default behaviour, se
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.

I "git checkout -b current" another branch in the remote repository.
In my local repository, I run "git push" then it success.
But the local modification only push to the remote master branch.
Then I should run "git merge master" in the remote repository to take the change.

I'm newbie to git.
Am I doing wrong?

Magic
  • 1,182
  • 2
  • 18
  • 28
  • possible duplicate of [git push error '\[remote rejected\] master -> master (branch is currently checked out)'](http://stackoverflow.com/questions/2816369/git-push-error-remote-rejected-master-master-branch-is-currently-checked) – eckes Jul 27 '12 at 05:37
  • Same as http://stackoverflow.com/questions/11395398/git-push-failing-refusing-to-update-checked-out-branch, http://stackoverflow.com/questions/11117823/git-push-error-refusing-to-update-checked-out-branch, http://stackoverflow.com/questions/8985782/git-push-fails-refusing-to-update-checked-out-branch-refs-heads-master – eckes Jul 27 '12 at 05:37

3 Answers3

7

The remote repository is not a bare repository and has master checked out. And, by default, git doesn't allow you to push to the checked out branch of a non-bare repo.

Remote repos to which you push should be set up as bare repo (git init --bare) ideally.

manojlds
  • 290,304
  • 63
  • 469
  • 417
  • Can my existing repos be setup as bare repo(git init --bare)? – Magic Jul 27 '12 at 09:22
  • I don't think so, but if it's a linux-based host and your repo's named 'foo', it would be as simple as something like: `mv foo foo2`, `mkdir foo`, `cd foo`, `git init --bare`, `git remote add origin ./../foo2`, `git pull` – Dean Rather Aug 04 '12 at 11:51
2

manojlds' answer is correct, however it might help to know what the purpose of your remote repo is.

  • If the remote repo is just for backup / collaboration purposes -> you've got the right idea, just replace the remote repo with a 'bare' one and go from there.
  • If the remote repo is the production server, then you're doing things wrong -> you should have a different configuration.

A good confiruation so that you can "push to production" is to have your 'bare' repo for backup / collab purposes, then you have a seperate repo which is setup on the deployment server and is cloned from the bare repo. Then on the bare repo and you can put a 'post-receive hook' which makes the deployment repo do a pull.

I'm sure there are guides on how to do this... I followed one myself once :)

Dean Rather
  • 31,756
  • 15
  • 66
  • 72
1

When i was new to github my mentor gave me this thumb rule to follow:

Make modifications to your code locally. When it is time to commit, do the following:

  1. do git pull (very important to sync the inner reference headers of remote repo to your local repository)
  2. If there are any conflicts in different files Merge them carefully by either choosing your copy or remote copy or a mix of both by opening both the files in Kdiff. Once you have resolved all the conflicts push the merge.
  3. After step 2 do git push to save the local changes you made to the code which you wanted to commit in the first place.

Subversion can be a pain but it is extremely important to maintain the sync. These set of rules have helped me a lot to maintain sub version usingg github. Hope this helped.

eckes
  • 64,417
  • 29
  • 168
  • 201
user1071979
  • 1,701
  • 2
  • 12
  • 25
  • I think that's not helpful for OP since you're talking about general slipslop instead of addressing his question. – eckes Jul 27 '12 at 05:41
  • 1
    Regarding your rule of thumb: I think it's wrong. When it's time to commit, commit. Period. Nothing else. When it's time to play things back into another repo, you'll have to do something like `fetch` and `rebase`, `pull` or similar. Then resolve conflicts. Then `push`. And in step 3, your local **commits** are sent to a remote repo. And SVN could not be a pain, it **is** one. – eckes Jul 27 '12 at 05:44