Git push error ' master -> master (branch is currently checked out)'

Yesterday, I posted a question on how to clone a Git repository from one of my machines to another, How can I ‘git clone’ from another machine?.

I am now able to successfully clone a Git repository from my source (192.168.1.2) to my destination (192.168.1.1).

But when I did an edit to a file, a git commit -a -m "test" and a git push, I get this error on my destination (192.168.1.1):

git push                                                
hap@192.168.1.2's password: 
Counting objects: 21, done.
Compressing objects: 100% (11/11), done.
Writing objects: 100% (11/11), 1010 bytes, done.
Total 11 (delta 9), reused 0 (delta 0)
error: refusing to update checked out branch: refs/heads/master
error: By default, updating the current branch in a non-bare repository
error: is denied, because it will make the index and work tree inconsistent
error: with what you pushed, and will require 'git reset --hard' to match
error: the work tree to HEAD.
error: 
error: You can set 'receive.denyCurrentBranch' configuration variable to
error: 'ignore' or 'warn' in the remote repository to allow pushing into
error: its current branch; however, this is not recommended unless you
error: arranged to update its work tree to match what you pushed in some
error: other way.
error: 
error: To squelch this message and still keep the default behaviour, set
error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To git+ssh://hap@192.168.1.2/media/LINUXDATA/working
! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to 'git+ssh://hap@192.168.1.2/media/LINUXDATA/working'

I’m using two different versions of Git (1.7 on the remote and 1.5 on the local machine). Is that a possible reason?

  • How do I push a local Git branch to master branch in the remote?
  • How do I make unpushable commits pushable?
  • Git pull from someone else's fork
  • Recovering file history after a forced push
  • How do git remotes work?
  • Why does git push sometimes need a localref argument?
  • Bare repo: Not all refs have been pushed
  • Update forked Github repo with all branches
  • 28 Solutions collect form web for “Git push error ' master -> master (branch is currently checked out)'”

    You can simply convert your remote repository to bare repository (there is no working copy in the bare repository – the folder contains only the actual repository data).

    Execute the following command in your remote repository folder:

    git config --bool core.bare true
    

    Then delete all the files except .git in that folder. And then you will be able to perform git push to the remote repository without any errors.

    I just had the same error while I began learning Git. Some of the other answers are clearly not for someone new to Git!

    (I am going to use non technical terms to get the idea across.) Anyway, what is happening is that you have two repositories, one is the original you first made, and the other the work one you just made.

    Right now you are in your work repository and are using the “master” branch. But you also happen to be “logged in” in your original repository to the same “master” branch. Now since you’re “logged in” in the original, Git fears you might mess up because you might be working on the original and screw things up. So you need to return to the original repository and do a “git checkout someotherbranch”, and now you can push with no problems.

    I hope this helps.

    The error message describes what has happened. More modern versions of Git refuse to update a branch via a push if that branch is checked out.

    The easiest way to work between two non-bare repositories is either to

    1. always update the repositories by pull (or fetch and merge) or, if you have to,

    2. by pushing to a separate branch (an import branch) and then merging that branch into the master branch on the remote machine.

    The reason for this restriction is that the push operation operates only on the remote Git repository, it doesn’t have access to the index and working tree. So, if allowed, a push on the checked-out branch would change the HEAD to be inconsistent with the index and working tree on the remote repository.

    This would make it very easy to accidentally commit a change that undoes all of the pushed changes and also makes it very difficult to distinguish between any local changes that have not been committed and differences between the new HEAD, the index and the working tree that have been caused by push moving HEAD.

    Summary

    You cannot push to the one checked out branch of a repository because it would mess with the user of that repository in a way that will most probably end with loss of data and history. But you can push to any other branch of the same repository.

    As bare repositories never have any branch checked out, you can always push to any branch of a bare repository.

    There are multiple solutions, depending on your needs.

    Solution 1: Use a Bare Repostiory

    As suggested, if on one machine, you don’t need the working directory, you can move to a bare repository. To avoid messing with the repository, you can just clone it:

    machine1$ cd ..
    machine1$ mv repo repo.old
    machine1$ git clone --bare repo.old repo
    

    Now you can push all you want to the same address as before.

    Solution 2: Push to a Non-Checked-Out Branch

    But if you need to check out the code on your remote <remote>, then you can use a special branch to push. Let’s say that in your local repository you have called your remote origin and you’re on branch master. Then you could do

    machine2$ git push origin master:master+machine2
    

    Then you need to merge it when you’re in the origin remote repo:

    machine1$ git merge master+machine2
    

    Autopsy of the Problem

    When a branch is checked out, committing will add a new commit with the current branch’s head as its parent and move the branch’s head to be that new commit.

    So

    A ← B
        ↑
    [HEAD,branch1]
    

    becomes

    A ← B ← C
            ↑
        [HEAD,branch1]
    

    But if someone could push to that branch inbetween, the user would get itself in what git calls detached head mode:

    A ← B ← X
        ↑   ↑
    [HEAD] [branch1]
    

    Now the user is not in branch1 anymore, without having explicitly asked to check out another branch. Worse, the user is now outside any branch, and any new commit will just be dangling:

          [HEAD]
            ↓
            C
          ↙
    A ← B ← X
            ↑
           [branch1]
    

    Hypothetically, if at this point, the user checks out another branch, then this dangling commit becomes fair game for Git’s garbage collector.

    You can get around this “limitation” by editing the .git/config on the destination server. Add the following to allow a git repository to be pushed to even if it is “checked out”:

    [receive]
    denyCurrentBranch = warn
    

    or

    [receive]
    denyCurrentBranch = false
    

    The first will allow the push while warning of the possibility to mess up the branch, whereas the second will just quietly allow it.

    This can be used to “deploy” code to a server which is not meant for editing. This is not the best approach, but a quick one for deploying code.

    I like the idea of still having a usable repository on the remote box, but instead of a dummy branch, I like to use:

    git checkout --detach
    

    This seems to be a very new feature of Git – I’m using git version 1.7.7.4.

    I had the same issue. For me, I use Git push to move code to my servers. I never change the code on the server side, so this is safe.

    In the repository, you are pushing to type:

    git config receive.denyCurrentBranch ignore
    

    This will allow you to change the repository while it’s a working copy.

    After you run a Git push, go to the remote machine and type this:

    git checkout -f
    

    This will make the changes you pushed be reflected in the working copy of the remote machine.

    Please note, this isn’t always safe if you make changes on in the working copy that you’re pushing to.

    You can recreate your server repository and push from your local branch master to the server master.

    On your remote server:

    mkdir myrepo.git
    cd myrepo.git
    git init --bare
    

    OK, from your local branch:

    git push origin master:master
    

    With a few setup steps you can easily deploy changes to your website using a one-liner like

    git push production
    

    Which is nice and simple, and you don’t have to log into the remote server and do a pull or anything. Note that this will work best if you don’t use your production checkout as a working branch! (The OP was working within a slightly different context, and I think @Robert Gould’s solution addressed it well. This solution is more appropriate for deployment to a remote server.)

    First you need to set up a bare repository somewhere on your server, outside of your webroot.

    mkdir mywebsite.git
    cd mywebsite.git
    git init --bare
    

    Then create file hooks/post-receive:

    #!/bin/sh
    GIT_WORK_TREE=/path/to/webroot/of/mywebsite git checkout -f
    

    And make the file executable:

    chmod +x hooks/post-receive
    

    On your local machine,

    git remote add production git@myserver.com:mywebsite.git
    git push production +master:refs/heads/master
    

    All set! Now in the future you can use git push production to deploy your changes!

    Credit for this solution goes to http://sebduggan.com/blog/deploy-your-website-changes-using-git/. Look there for a more detailed explanation of what’s going on.

    git config --local receive.denyCurrentBranch updateInstead

    https://github.com/git/git/blob/v2.3.0/Documentation/config.txt#L2155

    Use that on the server repository, and it also updates the working tree if no untracked overwrite would happen.

    It was added in Git 2.3 as mentioned by VonC in the comments.

    I’ve compiled Git 2.3 and gave it a try. Sample usage:

    git init server
    cd server
    touch a
    git add .
    git commit -m 0
    git config --local receive.denyCurrentBranch updateInstead
    
    cd ..
    git clone server local
    cd local
    touch b
    git add .
    git commit -m 1
    git push origin master:master
    
    cd ../server
    ls
    

    Output:

    a
    b
    

    Yay, b got pushed!

    What you probably did to cause this:

    This kind of thing happens when you go to bang out a little program. You’re about to change something which was already working, so you cast your level-3 spell of perpetual undoability:

    machine1:~/proj1> git init
    

    and you start adding/committing. But then, the project starts getting more involved and you want to work on it from another computer (like your home PC or laptop), so you do something like

    machine2:~> git clone ssh://machine1/~/proj1
    

    and it clones and everything looks good, and so you work on your code from machine2.

    Then… you try to push your commits from machine2, and you get the warning message in the title.

    The reason for this message is because the git repo you pulled from was kinda intended to be used just for that folder on machine1. You can clone from it just fine, but pushing can cause problems. The “proper” way to be managing the code in two different locations is with a “bare” repo, like has been suggested. A bare repo isn’t designed to have any work being done in it, it is meant to coordinate the commits from multiple sources. This is why the top-rated answer suggests deleting all files/folders other than the .git folder after you git config --bool core.bare true.

    Clarifying the top-rated answer: Many of the comments to that answer say something like “I didn’t delete the non-.git files from the machine1 and I was still able to commit from machine2”. That’s right. However, those other files are completely “divorced” from the git repo, now. Go try git status in there and you should see something like “fatal: This operation must be run in a work tree”. So, the suggestion to delete the files isn’t so that the commit from machine2 will work; it’s so that you don’t get confused and think that git is still tracking those files. But, deleting the files is a problem if you still want to work on the files on machine1, isn’t it?

    So, what should you really do?

    Depends upon how much you plan to still work on machine1 and machine2…

    If you’re done developing from machine1 and have moved all of your development to machine2… just do what the top-rated answer suggests: git config --bool core.bare true and then, optionally, delete all files/folders other than .git from that folder, since they’re untracked and likely to cause confusion.

    If your work on machine2 was just a one-time thing, and you don’t need to continue development there… then don’t bother with making a bare repo; just ftp/rsync/scp/etc. your files from machine*2* on top of the files on machine*1*, commit/push from machine*1*, and then delete the files off of machine*2*. Others have suggested creating a branch, but I think that’s a little messy if you just want to merge some development you did on a one-time basis from another machine.

    If you need to continue development on both machine1 and machine2… then you need to set things up properly. You need to convert your repo to a bare, then you need to make a clone of that on machine1 for you to work in. Probably the quickest way to do this is to do

    machine1:~/proj1> git config --bool core.bare true
    machine1:~/proj1> mv .git/ ../proj1.git
    machine1:~/proj1> cd ..
    machine1:~> rm -rf proj1
    machine1:~> git clone proj1.git
    machine1:~> cd proj1
    

    Very important: because you’ve moved the location of the repo from proj1 to proj1.git, you need to update this in the .git/config file on machine2. After that, you can commit your changes from machine2. Lastly, I try to keep my bare repos in a central location, away from my work trees (i.e. don’t put ‘proj1.git’ in the same parent folder as ‘proj1’). I advise you to do likewise, but I wanted to keep the steps above as simple as possible.

    You should only be pushing to a bare repository. A bare repository is a repository that has no checked out branches. If you were to cd to a bare repository directory, you’d only see the contents of a .git directory.

    In fact, set the remote to a non-checked out branch is sufficient. After you checked out your remote in a different branch, you can push.

    You have 3 options

    1. Pull and push again:

      git pull; git push
      
    2. Push into different branch:

      git push origin master:foo
      

      and merge it on remote (either by git or pull-request)

      git merge foo
      
    3. Force it (not recommended unless you deliberately changed commits via rebase):

      git push origin master -f
      

      If still refused, disable denyCurrentBranch on remote repository:

      git config receive.denyCurrentBranch ignore
      

    I had the same problem using Git to synchronise repositories on my Android phone and laptop. The solution for me was to do a pull instead of a push, as @CharlesBailey suggested.

    git push origin master on the Android repository fails for me with the same error messages that @hap497 got because of a push to a nonbare checkout of a repository + working-copy.

    git pull droid master on the laptop repository and working-copy works for me. Of course, you need to have previously run something like git remote add droid /media/KINGSTON4GB/notes_repo/.

    Older versions of Git used to allow pushes to the currently checked out branch of a non-bare repository.

    It turns out this was a terribly confusing thing to allow. So they added the warning message you see, which is also terribly confusing.

    If the first repository is just acting as a server then convert it to a bare repository as the other answers recommend and be done with it.

    If however you need to have a shared branch between two repos that are both in use you can achieve it with the following setup

    Repo1 – will act as the server and also be used for development

    Repo2 – will be for development only

    Setup Repo1 as follows

    Create a branch to share work on.

    git branch shared_branch
    

    To be safe, you should also create a $(REPO).git/hooks/update that rejects any changes to anything other than shared_branch, because you don’t want people mucking with your private branches.

    repo1/.git/hooks  (GIT_DIR!)$ cat update
    #!/bin/sh
    refname="$1"
    oldrev="$2"
    newrev="$3"
    
    if [ "${refname}" != "refs/heads/shared_branch" ]
    then
       echo "You can only push changes to shared_branch, you cannot push to ${refname}"
       exit 1
    fi
    

    Now create a local branch in repo1 where you will do your actual work.

    git checkout -b my_work --track shared_branch
    Branch my_work set up to track local branch shared_branch.
    Switched to a new branch 'my_work'
    

    (may need to git config --global push.default upstream in order for git push to work)

    Now you can create repo2 with

    git clone path/to/repo1 repo2 
    git checkout shared_branch 
    

    At this point you have both repo1 and repo2 setup to work on local branches that push and pull from shared_branch in repo1, without needing to worry about that error message or having the working directory get out of sync in repo1. Whatever normal workflow you use should work.

    Here is one test you can do to see how the bare server stuff work:

    Imagine you have a workstation and a server with live site hosted on it, and you want to update this site from time to time (this also applies to a situation where two developers are sending their work back and forth through a bare middleman).

    Initialization

    Create some directory on your local computer and cd into it, then execute these commands:

    # initialization
    git init --bare server/.git
    git clone server content
    git clone server local
    
    1. First you create a bare server directory (notice the .git at the end). This directory will serve as a container for your repository files only.
    2. Then clone your server repository to a newly created content directory. This is your live/production directory which will be served by your server software.
    3. The first two directories resides on your server, the third one is a local directory on your workstation.

    Workflow

    Now here is the basic workflow:

    1. Enter the local directory, create some files and commit them. Finally push them to the server:

      # create crazy stuff
      git commit -av
      git push origin master
      
    2. Now enter the content directory and update the server’s content:

      git pull
      
    3. Repeat 1-2. Here content may be another developer that can push to the server too, and local as you may pull from him.

    OK, in case you want a normal remote repository, then create an extra branch and check it out. Push it into one branch (which is not checked out) and merge it with one which is currently active later after pushing from locally.

    For example, on a remote server:

    git branch dev
    git checkout dev
    

    On the local setup:

    git push 
    

    On remote server:

    git merge dev
    

    I had to re-run git --init in an existing bare repository, and this had created a .git directory inside the bare repository tree – I realized that after typing git status there. I deleted that and everything was fine again 🙂

    (All these answers are great, but in my case it was something completely different (as far as I can see), as described.)

    I’m sure most people viewing this question will stop at the first two huge answers, but I’d still like to offer my solution.

    I had an Eclipse + EGit web project setup when encountering the described error. What helped me was simply using the GitHub app, which seemed to magically resolve the issue. While EGit would always refuse the push, the GitHub desktop app would just shrug its shoulders and push my changes. Maybe it handles the multi-login-situation more gracefully.

    An article I found that might be useful to others is Git in 5 minutes.

    I had an Xcode project under Git version control that I wanted to push up to a Virtual Distributed Ethernet (VDE) I have in a DC. The VDE runs Centos 5.

    None of the articles I read about Git talked about bare repositories. It all sounded so simple until I tried what I thought should be easy coming from an SVN background.

    The suggestions here to make the remote repository bare worked. Even better for my requirements was to clone the Xcode project to projectname.git, copy that to the remote server; then pushes magically worked. The next step will be getting Xcode to push without errors about commits, but for now I’m okay doing it from Terminal.

    So:

    cd /tmp (or another other directory on your system)<br/>
    git clone --bare /xcode-project-directory projectname.git<br/>
    scp -r projectname.git sshusername@remotehost.com:repos/<br/>
    

    To push changes from your Xcode project after you’ve committed in Xcode:

    cd /xcode-project-directory<br/>
    git push sshusername@remotehost.com:repos/projectname.git<br/>
    

    I’m certain there is a smoother more sophisticated way of doing the above, but at a minimum this works. Just so everything is clear, here are some clarifications:
    /xcode-project-directory is the directory your xcode project is stored in. It’s probably /Users/Your_Name/Documents/Project_Name.
    projectname is literally the name of the project, but it can be anything you care to call it. Git doesn’t care, you will.

    To use scp you need to have a user account on the remote server that’s allowed SSH access. Anyone running their own server will have this. If you’re using shared hosting or the like, you might be out of luck.

    remotehost.com is the name of your remote host. You could as easily use its IP address. Just for further clarity I’m using Gitosis on the remote host with SSH keys, so I’m not prompted for passwords when I push. The article Hosting Git Repositories, the Easy (and Secure) Way tells you how to set all that up.

    The best way to do this is:

    mkdir ..../remote
    cd ..../remote
    git clone --bare .../currentrepo/
    

    This will clone the repository, but it won’t make any working copies in .../remote. If you look at the remote, you’ll see one directory created, called currentrepo.git, which is probably what you want.

    Then from your local Git repository:

    git remote add remoterepo ..../remote/currentrepo.git
    

    After you make changes, you can:

    git push remoterepo master
    

    I just ran into this problem with a deployment git repository on Heroku.

    I don’t know why Heroku has a non-bare repository on their side, but as a workaround I was able to reset the remote repository, and reupload.

    You shouldn’t use Heroku’s copy of your repository as your only git repository for collaboration, but just in case, I’ll say clearly: Do not do this unless you are sure you have a full copy of your repository stored securely somewhere other than Heroku. Doing a reset will delete the repository contents.

    To reset:

    1. Install the Heroku toolbelt (which contains the command line client) if you haven’t already.
    2. Install the heroku-repo plugin if you haven’t already.

      heroku plugins:install https://github.com/heroku/heroku-repo.git
      
    3. Do the reset, which deletes the repository and creates a new, empty one

      heroku repo:reset
      
    4. Push to your Heroku remote as you normally would; it will reupload everything.

    You will need to change the config file on the remote server once you have created empty(bare) repository, say

    root@development:/home/git/repository/my-project# cat config 
    

    there you will see

    [core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    

    You will make this bare to false to true and I removed logallrefupdates = true (not sure of its use!)

    to

    [core]
    repositoryformatversion = 0
    filemode = true
    bare = true
    

    You may test following

    $ git remote show origin
    * remote origin
    Fetch URL: my-portal@development:/home/XYZ/repository/XYZ
    Push  URL: my-portal@development:/home/XYZ/repository/XYZ
    HEAD branch: (unknown)
    

    This HEAD branch: (unknown) will be shown if you are unable to PUSH. So if the HEAD branch is unknow, you should change bare to true and after push successful you can reuse the

    git remote show origin
    

    and you will see

     HEAD branch: master
    

    For me working solution is:

    ON REMOTE:

    git checkout -b some_tmp_name
    

    ON LOCAL:

    git push
    

    ON REMOTE:

    git checkout master
    git branch -d some_tmp_name
    

    But this is not the real solution it’s just workaround.

    With Git, two regular (non-bare) repositories can’t push/pull files back and forth directly. There must be an intermediary bare repository. Apparently, it’s sort of like a married couple who have a kid, and the couple is getting divorced. The parents won’t talk to each other, but they will communicate through the kid.

    So, you have one repository, you clone this repository to a bare repository, and then you clone that to a third. The first and the third can exchange information via the second repository, the bare one. I guess this makes sense, as you wouldn’t want someone able to check stuff into your repository without your consent, as that could cause merge conflicts & the like.

    So, here’s an example:

    On PC, in ~/workspace

    git init
    echo "line 1" > afile.txt
    git add .
    git commit -m ‘initial import’
    git clone --bare . ../remote-repository.git
    git remote add origin ../remote-repository.git
    git push --set-upstream origin master
    

    On laptop, in ~/workspace (do not do git init, etc.)

    git clone //LJZ-DELLPC/remote-repository.git/ .
    

    // Then make various commits, and push them:

    echo "line 2" > afile.txt
    git add afile.txt
    git commit -m 'added line 2'
    git push    
    

    Then back on PC, in ~/workspace

    git pull
    

    // Then make various commits, and push them:

    git push
    

    On laptop
    git pull

    and so forth..

    Here’s an absolute concrete example all on one machine, copied straight from the command window, so that we’ll know that no steps were left out, that it really did work, etc:

    lylez@LJZ-DELLPC ~
    $ cd gitdir
    /home/lylez/gitdir
    
    lylez@LJZ-DELLPC ~/gitdir
    $ ls
    
    lylez@LJZ-DELLPC ~/gitdir
    $ mkdir repo1
    
    lylez@LJZ-DELLPC ~/gitdir
    $ cd repo1
    /home/lylez/gitdir/repo1
    
    lylez@LJZ-DELLPC ~/gitdir/repo1
    $ git init
    Initialized empty Git repository in /home/lylez/gitdir/repo1/.git/
    
    lylez@LJZ-DELLPC ~/gitdir/repo1
    $ echo "line 1" > afile.txt
    
    lylez@LJZ-DELLPC ~/gitdir/repo1
    $ git add afile.txt
    
    lylez@LJZ-DELLPC ~/gitdir/repo1
    $ git commit -m 'initial import'
    [master (root-commit) f407e12] initial import
     1 file changed, 1 insertion(+)
     create mode 100644 afile.txt
    
    lylez@LJZ-DELLPC ~/gitdir/repo1
    $ git clone --bar . ../repo1-bare-clone
    Cloning into bare repository '../repo1-bare-clone'...
    done.
    
    lylez@LJZ-DELLPC ~/gitdir/repo1
    $ git remote add origin ../repo1-bare-clone
    
    lylez@LJZ-DELLPC ~/gitdir/repo1
    $ git push --set-upstream origin master
    Branch master set up to track remote branch master from origin.
    Everything up-to-date
    
    lylez@LJZ-DELLPC ~/gitdir/repo1
    $ cd ..
    
    lylez@LJZ-DELLPC ~/gitdir
    $ ls
    repo1  repo1-bare-clone
    
    lylez@LJZ-DELLPC ~/gitdir
    $ mkdir repo1-remote
    
    lylez@LJZ-DELLPC ~/gitdir
    $ cd repo1-remote
    /home/lylez/gitdir/repo1-remote
    
    lylez@LJZ-DELLPC ~/gitdir/repo1-remote
    $ git clone ../repo1-bare-clone .
    Cloning into '.'...
    done.
    
    lylez@LJZ-DELLPC ~/gitdir/repo1-remote
    $ ls
    afile.txt
    
    lylez@LJZ-DELLPC ~/gitdir/repo1-remote
    $ cat afile.txt
    line 1
    
    lylez@LJZ-DELLPC ~/gitdir/repo1-remote
    $ echo "line 2" >> afile.txt
    
    lylez@LJZ-DELLPC ~/gitdir/repo1-remote
    $ git add afile.txt
    
    lylez@LJZ-DELLPC ~/gitdir/repo1-remote
    $ git commit -m 'added line 2'
    [master 5ad31e0] added line 2
     1 file changed, 1 insertion(+)
    
    lylez@LJZ-DELLPC ~/gitdir/repo1-remote
    $ git push
    Counting objects: 3, done.
    Writing objects: 100% (3/3), 260 bytes | 0 bytes/s, done.
    Total 3 (delta 0), reused 0 (delta 0)
    To /home/lylez/gitdir/repo1-remote/../repo1-bare-clone
       f407e12..5ad31e0  master -> master
    
    lylez@LJZ-DELLPC ~/gitdir/repo1-remote
    $ cd ../repo1
    
    lylez@LJZ-DELLPC ~/gitdir/repo1
    $ ls
    afile.txt
    
    lylez@LJZ-DELLPC ~/gitdir/repo1
    $ cat afile.txt
    line 1
    
    lylez@LJZ-DELLPC ~/gitdir/repo1
    $ git pull
    remote: Counting objects: 3, done.
    remote: Total 3 (delta 0), reused 0 (delta 0)
    Unpacking objects: 100% (3/3), done.
    From ../repo1-bare-clone
       f407e12..5ad31e0  master     -> origin/master
    Updating f407e12..5ad31e0
    Fast-forward
     afile.txt | 1 +
     1 file changed, 1 insertion(+)
    
    lylez@LJZ-DELLPC ~/gitdir/repo1
    $ cat afile.txt
    line 1
    line 2
    
    lylez@LJZ-DELLPC ~/gitdir/repo1
    $ echo "line 3" >> afile.txt
    
    lylez@LJZ-DELLPC ~/gitdir/repo1
    $ git add afile.txt
    
    lylez@LJZ-DELLPC ~/gitdir/repo1
    $ git commit -m 'added line 3'
    [master 3fa569e] added line 3
     1 file changed, 1 insertion(+)
    
    lylez@LJZ-DELLPC ~/gitdir/repo1
    $ git push
    Counting objects: 3, done.
    Writing objects: 100% (3/3), 265 bytes | 0 bytes/s, done.
    Total 3 (delta 0), reused 0 (delta 0)
    To ../repo1-bare-clone
       5ad31e0..3fa569e  master -> master
    
    lylez@LJZ-DELLPC ~/gitdir/repo1
    $ cd ../repo1-remote/
    
    lylez@LJZ-DELLPC ~/gitdir/repo1-remote
    $ ls
    afile.txt
    
    lylez@LJZ-DELLPC ~/gitdir/repo1-remote
    $ cat afile.txt
    line 1
    line 2
    
    lylez@LJZ-DELLPC ~/gitdir/repo1-remote
    $ git pull
    remote: Counting objects: 3, done.
    remote: Total 3 (delta 0), reused 0 (delta 0)
    Unpacking objects: 100% (3/3), done.
    From /home/lylez/gitdir/repo1-remote/../repo1-bare-clone
       5ad31e0..3fa569e  master     -> origin/master
    Updating 5ad31e0..3fa569e
    Fast-forward
     afile.txt | 1 +
     1 file changed, 1 insertion(+)
    
    lylez@LJZ-DELLPC ~/gitdir/repo1-remote
    $ cat afile.txt
    line 1
    line 2
    line 3
    
    lylez@LJZ-DELLPC ~/gitdir/repo1-remote
    $ git --version
    git version 2.1.1
    
    lylez@LJZ-DELLPC ~/gitdir/repo1-remote
    

    Just in case someone finds it useful. For me it was a git server permissions issue. I checked out the project from the beggining and push a simple file and then I got the “Push rejected: Push to origin/master was rejected”

    My solution (in use)

    1. Checkout “master” on remote server
    2. Work locally on “dev” branch
    3. Push changes to remote dev
    4. Merge dev into master on remote

    bingo

    Git Baby is a git and github fan, let's start git clone.