CODEWITHSUNDEEP
git
Magic
Magic

Reputation: 1196

git push to remote master branch

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?

Upvotes: 3

Views: 4492

Answers (3)

Dean Rather
Dean Rather

Reputation: 32384

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 :)

Upvotes: 2

user1071979
user1071979

Reputation: 1791

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.

Upvotes: 1

manojlds
manojlds

Reputation: 301147

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.

Upvotes: 7

Related Questions