Git push error remote rejected master - master branch is currently checked out

Question

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 - gt  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

User · Answer

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

User · Answer

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

User · Answer

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 gt  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   gt  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 gt  git config --bool core bare true machine1   proj1 gt  mv  git     proj1 git machine1   proj1 gt  cd    machine1   gt  rm -rf proj1 machine1   gt  git clone proj1 git machine1   gt  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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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    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  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  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    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  Now enter the content directory and update the server s content   git pull  Repeat 1-2  Here content may be another developer that can push to the server too  and local as you may pull from him

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

Using this to push it to the remote upstream branch solved this issue for me   git push  lt remote gt  master origin master   The remote had no access to the upstream repo so this was a good way to get the latest changes into that remote

User · Answer

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

User · Answer

You have 3 options   Pull and push again   git pull  git push  Push into different branch   git push origin master foo   and merge it on remote  either by git or pull-request   git merge foo  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

User · Answer

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

User · Answer

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  lt remote gt   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

User · Answer

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  amp  the like   So  here s an example   On PC  in   workspace  git init echo  line 1   gt  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   gt  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   gt  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   gt  gt  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 - gt  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     - gt  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   gt  gt  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 - gt  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     - gt  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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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  lt br  gt  git clone --bare  xcode-project-directory projectname git lt br  gt  scp -r projectname git sshusername remotehost com repos  lt br  gt    To push changes from your Xcode project after you ve committed in Xcode   cd  xcode-project-directory lt br  gt  git push sshusername remotehost com repos projectname git lt br  gt    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

User · Answer

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

User · Answer

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   always update the repositories by pull  or fetch and merge  or  if you have to  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

User · Answer

My solution  in use    Checkout  master  on remote server Work locally on  dev  branch Push changes to remote dev Merge dev into master on remote   bingo

User · Answer

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

User · Answer

Check your  git config in the destination project     cat  git config   core      repositoryformatversion   0     filemode   true     bare   false     logallrefupdates   true  receive      denyCurrentBranch   updateInstead   If the core  bare is false  you can set it to true     git config core bare true   and then in your local push to remote   git push remote repo      suppose the destination repo is remote repo   it will success  in the remote repo you can check git version      git log -1 commit 0623b1b900ef7331b9184722a5381bbdd2d935ba Author  aircraft  lt  aircraft xxx 126 com gt  Date    Thu May 17 21 54 37 2018  0800   and now you can not use git in your  workspace       git status fatal  This operation must be run in a work tree   you should set bare bare back to false     git config core bare false

User · Answer

I ran into this issue when I had cloned a repo on my NAS and then cloned that repo on to my machines  The set up is something like this  ORIGINAL  github    cloned to network storage in my private home network  my home network   branch checked out  DEVELOPMENT   cloned to other machines  laptops  small data center server in my office  etc   branch checked out  DEVELOPMENT    When I tried to commit to the from the laptop to the NAS server the error which comes up is    remote rejected    development - gt  development  branch is currently checked out   The root cause is that DEVELOPMENT branch is checked out on the NAS server  My solution was on the NAS repository to switch to any other branch  This let me commit my changes

User · Answer

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    Install the Heroku toolbelt  which contains the command line client  if you haven t already  Install the heroku-repo plugin if you haven t already   heroku plugins install https   github com heroku heroku-repo git  Do the reset  which deletes the repository and creates a new  empty one  heroku repo reset  Push to your Heroku remote as you normally would  it will reupload everything

User · Answer

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

[git] Git push error '[remote rejected] master -> master (branch is currently checked out)'

Examples related to git

Examples related to git-push