Error de inserción de Git 'maestro -> maestro (twig actualmente está desprotegido)'

Ayer, publiqué una pregunta sobre cómo clonar un repository Git de una de mis máquinas a otra, ¿cómo puedo 'git clone' desde otra máquina? .

Ahora puedo clonar con éxito un repository de Git desde mi fuente (192.168.1.2) a mi destino (192.168.1.1).

Pero cuando hice una edición de un file, un git commit -a -m "test" y un git push , recibo este error en mi destino (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' 

Estoy usando dos versiones diferentes de Git (1.7 en el control remoto y 1.5 en la máquina local). ¿Es esa una posible razón?

Solutions Collecting From Web of "Error de inserción de Git 'maestro -> maestro (twig actualmente está desprotegido)'"

Simplemente puede convertir su repository remoto en un repository simple (no hay una copy de trabajo en el repository simple, la carpeta contiene solo los datos reales del repository).

Ejecute el siguiente command en su carpeta de repository remoto:

 git config --bool core.bare true 

Luego borre todos los files excepto .git en esa carpeta. Y luego podrá realizar git push en el repository remoto sin ningún error.

Acabo de tener el mismo error mientras comencé a aprender a Git . ¡Algunas de las otras respuestas claramente no son para alguien nuevo en Git!

(Voy a usar términos no técnicos para transmitir la idea). De todos modos, lo que está sucediendo es que tienes dos repositorys, uno es el original que creaste por primera vez y el otro es el trabajo que acabas de crear.

En este momento está en su repository de trabajo y está utilizando la twig "principal". Pero también está "conectado" en su repository original a la misma twig "principal". Ahora que estás "conectado" en el original, Git teme que lo arruines porque podrías estar trabajando en el original y arruinando las cosas. Por lo tanto, debe volver al repository original y hacer un "git checkout someotherbranch", y ahora puede presionar sin problemas.

Espero que esto ayude.

El post de error describe lo que sucedió. Las versiones más modernas de Git se niegan a actualizar una twig mediante un push si esa twig está desprotegida.

La forma más fácil de trabajar entre dos repositorys no desnudos es o bien para

  1. siempre actualice los repositorys mediante extracción (o búsqueda y combinación) o, si es necesario,

  2. presionando a una twig separada (una twig de import) y luego fusionando esa twig a la twig principal en la máquina remota.

El motivo de esta restricción es que la operación de inserción solo funciona en el repository de Git remoto, no tiene acceso al índice y al tree de trabajo. Por lo tanto, si se permite, un impulso en la twig de check-out cambiaría el HEAD para que no sea coherente con el índice y el tree de trabajo en el repository remoto.

Esto haría que sea muy fácil cometer accidentalmente un cambio que deshaga todos los cambios realizados y también hace que sea muy difícil distinguir entre cualquier cambio local que no se haya cometido y las diferencias entre el nuevo HEAD , el índice y el tree de trabajo que tienen ha sido causado por un movimiento que mueve la HEAD .

Resumen

No se puede presionar en la única twig desprotegida de un repository porque podría interferir con el usuario de ese repository de una manera que probablemente terminará con pérdida de datos e historial . Pero puede presionar a cualquier otra twig del mismo repository.

Como los repositorys simples nunca tienen una twig desprotegida, siempre puede enviarla a cualquier twig de un repository vacío.

Existen múltiples soluciones, según sus necesidades.

Solución 1: Use un Repostiory simple

Como se sugiere, si en una máquina no necesita el directory de trabajo, puede pasar a un repository simple. Para evitar jugar con el repository, simplemente puede clonarlo:

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

Ahora puedes enviar todo lo que quieras a la misma dirección que antes.

Solución 2: Empujar a una sucursal sin control

Pero si necesita verificar el código en su control remoto <remote> , entonces puede usar una twig especial para enviar. Digamos que en su repository local ha llamado a su origin remoto y está en la twig principal. Entonces podrías hacer

 machine2$ git push origin master:master+machine2 

Luego debe fusionarlo cuando se encuentre en el repository remoto de origin :

 machine1$ git merge master+machine2 

Autopsia del problema

Cuando se desprotege una sucursal, la confirmación agregará una nueva confirmación con la cabeza de la sucursal actual como su padre y moverá la cabeza de la sucursal para que sea la nueva confirmación.

Asi que

 A ← B ↑ [HEAD,branch1] 

se convierte

 A ← B ← C ↑ [HEAD,branch1] 

Pero si alguien pudiera presionar a esa twig en medio, el usuario se metería en lo que git llama el modo de cabeza separada :

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

Ahora el usuario ya no está en la twig1, sin haber solicitado explícitamente verificar otra twig. Peor aún, el usuario ahora se encuentra fuera de cualquier sucursal y cualquier compromiso nuevo estará colgando :

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

Hipotéticamente, si en este punto, el usuario visita otra sucursal, este compromiso se convierte en un juego justo para el recolector de basura de Git.

Puede evitar esta "limitación" editando .git/config en el server de destino. Agregue lo siguiente para permitir que un repository de git sea enviado incluso si está "desprotegido":

 [receive] denyCurrentBranch = warn 

o

 [receive] denyCurrentBranch = false 

El primero permitirá el empuje mientras advierte de la posibilidad de estropear la twig, mientras que el segundo lo permitirá silenciosamente.

Esto se puede usar para "implementar" código en un server que no está destinado a la edición. Este no es el mejor enfoque, sino uno rápido para implementar código.

Me gusta la idea de tener un repository utilizable en el cuadro remoto, pero en lugar de una twig ficticia, me gusta usar:

 git checkout --detach 

Esta parece ser una característica muy nueva de Git : estoy usando la versión 1.7.7.4 de git.

Tuve el mismo problema. Para mí, uso Git push para mover el código a mis serveres. Nunca cambio el código del lado del server, así que esto es seguro.

En el repository, estás presionando para escribir:

 git config receive.denyCurrentBranch ignore 

Esto le permitirá cambiar el repository mientras es una copy de trabajo.

Después de ejecutar un Git push, ve a la máquina remota y escribe esto:

 git checkout -f 

Esto hará que los cambios que empujó se reflejen en la copy de trabajo de la máquina remota.

Tenga en count que esto no siempre es seguro si realiza cambios en la copy de trabajo a la que está presionando.

Puede recrear su depósito de server y enviar desde su maestro de sucursal local al server principal.

En tu server remoto:

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

OK, desde su sucursal local:

 git push origin master:master 

git config --local receive.denyCurrentBranch updateInstead

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

Úselo en el repository del server, y también actualiza el tree de trabajo si no ocurre una sobrescritura sin seguimiento.

Fue agregado en Git 2.3 como lo menciona VonC en los comentarios.

He comstackdo Git 2.3 y lo he probado. Uso de muestra:

 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 

Salida:

 a b 

¡Yay, me empujaron!

Con unos pocos pasos de configuration, puede implementar fácilmente cambios en su website utilizando un layout de una sola línea.

 git push production 

Lo cual es agradable y simple, y no es necesario que inicies session en el server remoto y lo hagas, ni nada. Tenga en count que esto funcionará mejor si no utiliza su process de producción como una twig de trabajo. (El OP funcionaba en un context ligeramente diferente, y creo que la solución de @Robert Gould lo abordó bien. Esta solución es más apropiada para la implementación en un server remoto).

Primero necesita configurar un repository vacío en algún lugar de su server, fuera de su webroot.

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

A continuación, cree hooks/post-receive file hooks/post-receive :

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

Y haz que el file sea ejecutable:

 chmod +x hooks/post-receive 

En tu máquina local,

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

¡Todo listo! ¡Ahora en el futuro puede usar la git push production para implementar sus cambios!

El crédito para esta solución se encuentra en http://sebduggan.com/blog/deploy-your-website-changes-using-git/ . Busque allí una explicación más detallada de lo que está sucediendo.

Lo que probablemente hiciste para causar esto:

Este tipo de cosas sucede cuando vas a golpear un pequeño progtwig. Estás a punto de cambiar algo que ya funcionaba, por lo que lanzas tu hechizo de perpetua falta de nivel 3:

 machine1:~/proj1> git init 

y comienzas a agregar / comprometer. Pero luego , el proyecto comienza a involucrarse más y desea trabajar en él desde otra computadora (como la PC o computadora portátil de su casa), por lo que puede hacer algo como

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

y clona y todo se ve bien, y entonces trabajas en tu código de machine2.

Entonces … intentas enviar tus confirmaciones desde machine2, y obtienes el post de advertencia en el título.

La razón de este post es porque el repository de git del que extrajo estaba destinado a ser utilizado solo para esa carpeta en machine1. Puedes clonar bien, pero presionar puede causar problemas. La forma "adecuada" de administrar el código en dos ubicaciones diferentes es mediante un repository "vacío", como se ha sugerido. Un repository simple no está diseñado para realizar ningún trabajo, sino para coordinar las confirmaciones de múltiples fonts. Esta es la razón por la que la respuesta mejor calificada sugiere eliminar todos los files / carpetas que no sean la carpeta .git después de que git config --bool core.bare true .

Aclaración de la respuesta mejor calificada: Muchos de los comentarios a esa respuesta dicen algo así como "No eliminé los files que no son .git de la máquina1 y aún así pude comprometerme desde la máquina2". Está bien. Sin embargo, esos otros files están completamente "divorciados" del repository git, ahora. Ve a probar el git status ahí y verás algo así como "fatal: esta operación debe ejecutarse en un tree de trabajo". Por lo tanto, la sugerencia de eliminar los files no es para que funcione la confirmación de machine2; es para que no te confundas y pienses que git sigue rastreando esos files. Pero, borrar los files es un problema si aún quieres trabajar en los files en machine1, ¿no es así?

Entonces, ¿qué deberías hacer realmente?

Depende de cuánto planee seguir trabajando en machine1 y machine2 …

Si ha terminado de desarrollar desde machine1 y ha movido todo su desarrollo a machine2 … solo haga lo que la respuesta mejor calificada sugiere: git config --bool core.bare true y luego, opcionalmente, elimine todos los files / carpetas otros que .git de esa carpeta, ya que no están rastreados y es probable que causen confusión.

Si su trabajo en machine2 fue solo una cosa de una sola vez, y no necesita continuar el desarrollo allí … entonces no se moleste en hacer un repository simple; solo ftp / rsync / scp / etc. sus files de la máquina * 2 * en la parte superior de los files en la máquina * 1 *, confirme / presione desde la máquina * 1 *, y luego elimine los files de la máquina * 2 *. Otros han sugerido la creación de una sucursal, pero creo que es un poco complicado si solo quieres fusionar algún desarrollo que hiciste una sola vez desde otra máquina.

Si necesita continuar el desarrollo tanto en machine1 como en machine2 … entonces debe configurar las cosas correctamente. Necesita convertir su repository en descubierto, luego debe hacer una copy de eso en la máquina1 para que trabaje . Probablemente, la forma más rápida de hacerlo es hacer

 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 

Muy importante: debido a que ha movido la location del repository de proj1 a proj1.git, necesita actualizar esto en el file .git / config en machine2 . Después de eso, puede confirmar sus cambios desde machine2. Por último, trato de mantener mis repos sin formatting en una location central, lejos de mis treees de trabajo (es decir, no coloque 'proj1.git' en la misma carpeta principal que 'proj1'). Te aconsejo que hagas lo mismo, pero quería que los pasos anteriores fueran lo más simples posible.

Solo deberías empujar hacia un repository simple. Un repository desnudo es un repository que no tiene ramificaciones desprotegidas. Si fuera a cd a un directory de repository desnudo, solo vería el contenido de un directory .git.

De hecho, configurar el control remoto en una twig sin control es suficiente. Después de que haya comprobado su control remoto en una twig diferente, puede presionar.

Tienes 3 opciones

  1. Tire y empuje de nuevo:

     git pull; git push 
  2. Empujar hacia una twig diferente:

     git push origin master:foo 

    y combinarlo en remoto (ya sea por git o pull-request )

     git merge foo 
  3. Force it (no recomendado a less que haya cambiado deliberadamente commits a través de rebase ):

     git push origin master -f 

    Si todavía se rechazó, deshabilite denyCurrentBranch en el repository remoto:

     git config receive.denyCurrentBranch ignore 

Tuve el mismo problema al usar Git para sincronizar repositorys en mi teléfono y computadora portátil Android. La solución para mí fue hacer un pull en lugar de un push, como sugirió @CharlesBailey.

git push origin master en el repository de Android falla para mí con los mismos posts de error que @ hap497 obtuvo debido a un empujón a un pago no pago de un repository + copy de trabajo.

git pull droid master en el repository de laptops y work-copy funciona para mí. Por supuesto, debe haber ejecutado previamente algo como git remote add droid /media/KINGSTON4GB/notes_repo/ .

Las versiones anteriores de Git solían permitir las transferencias a la twig actualmente desprotegida de un repository no vacío.

Resulta que esto fue algo terriblemente confuso de permitir. Entonces agregaron el post de advertencia que ves, que también es terriblemente confuso.

Si el primer repository solo está actuando como server, conviértalo en un repository simple ya que las otras respuestas lo recomiendan y listo.

Sin embargo, si necesita tener una twig compartida entre dos repos que estén en uso, puede lograrlo con la siguiente configuration

Repo1: actuará como server y también se usará para el desarrollo

Repo2 – será solo para desarrollo

Configure Repo1 de la siguiente manera

Crea una twig para compartir el trabajo.

 git branch shanetworking_branch 

Para estar seguro, también debe crear un $ (REPO) .git / hooks / update que rechace cualquier cambio en cualquier otra cosa que no sea shanetworking_branch, porque no quiere que las personas se filtren con sus twigs privadas.

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

Ahora crea una sucursal local en repo1 donde harás tu trabajo real.

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

(puede necesitar git config --global push.default upstream para que git push funcione)

Ahora puedes crear repo2 con

 git clone path/to/repo1 repo2 git checkout shanetworking_branch 

En este punto, tiene la configuration de repo1 y repo2 para trabajar en las sucursales locales que empujan y shanetworking_branch de shanetworking_branch en repo1, sin necesidad de preocuparse por ese post de error o tener el directory de trabajo fuera de synchronization en repo1. Cualquier flujo de trabajo normal que uses debería funcionar.

Aquí hay una testing que puede hacer para ver cómo funcionan las cosas del server:

Imagine que tiene una estación de trabajo y un server con sitio en vivo alojado en él, y desea actualizar este sitio de vez en cuando (esto también se aplica a una situación en la que dos desarrolladores envían su trabajo de un intermediario a otro).

Inicialización

Crea un directory en tu computadora local y cd en él, luego ejecuta estos commands:

 # initialization git init --bare server/.git git clone server content git clone server local 
  1. Primero crea un directory de server desnudo (observe el .git al final). Este directory servirá como un contenedor para sus files de repository solamente.
  2. Luego, clone el repository de su server en un directory de content recién creado. Este es su directory de producción / en vivo que será servido por su software de server.
  3. Los primeros dos directorys residen en su server, el tercero es un directory local en su estación de trabajo.

Flujo de trabajo

Ahora aquí está el flujo de trabajo básico:

  1. Ingrese al directory local , cree algunos files y complételos. Por último, empújelos al server:

     # create crazy stuff git commit -av git push origin master 
  2. Ahora ingrese el directory de content y actualice el contenido del server:

     git pull 
  3. Repita 1-2. Aquí el content puede ser otro desarrollador que también pueda enviar contenido al server, y local ya que puede get de él.

OK, en caso de que quiera un repository remoto normal, cree una ramificación adicional y compruébelo. Introdúzcalo en una twig (que no está desprotegida) y combínelo con uno que esté activo más adelante luego de presionarlo localmente.

Por ejemplo, en un server remoto:

 git branch dev git checkout dev 

En la configuration local:

 git push 

En el server remoto:

 git merge dev 

Tuve que volver a ejecutar git --init en un repository desnudo existente, y esto había creado un directory .git dentro del tree de repository desnudo – me di count de que después de escribir el git status allí. Lo eliminé y todo estuvo bien de nuevo 🙂

(Todas estas respuestas son geniales, pero en mi caso fue algo completamente diferente (hasta donde puedo ver), como se describe).

Estoy seguro de que la mayoría de las personas que verán esta pregunta se detendrán en las primeras dos grandes respuestas, pero aún me gustaría ofrecer mi solución.

Tenía una configuration de proyecto web de Eclipse + EGit al encontrar el error descrito. Lo que me ayudó fue simplemente usar la aplicación GitHub, que parecía resolver mágicamente el problema. Mientras que EGit siempre rechazaría el impulso, la aplicación de escritorio de GitHub simplemente encogerse de hombros e impulsar mis cambios. Tal vez maneja la situación de inicio de session múltiple con más gracia.

Un artículo que encontré que podría ser útil para otros es Git en 5 minutos .

Tenía un proyecto de Xcode bajo el control de la versión de Git que quería impulsar a un Ethernet distribuido virtual (VDE) que tengo en un DC. El VDE ejecuta Centos 5.

Ninguno de los artículos que leí sobre Git hablaba de depósitos desnudos. Todo sonaba tan simple hasta que intenté lo que pensé que debería ser fácil viniendo de un background SVN .

Las sugerencias aquí para hacer que el repository remoto funcionara. Aún mejor para mis requerimientos era clonar el proyecto Xcode a projectname.git , copyr eso al server remoto; luego empuja mágicamente trabajado. El siguiente paso será hacer que Xcode presione sin cometer errores, pero por ahora estoy bien desde Terminal.

Asi que:

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

Para impulsar los cambios de su proyecto Xcode después de haberse comprometido en Xcode:

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

Estoy seguro de que hay una forma más suave y sofisticada de hacer lo anterior, pero como mínimo esto funciona. Para que todo quede claro, aquí hay algunas aclaraciones: /xcode-project-directory es el directory en el que está almacenado su proyecto xcode. Probablemente sea /Users/Your_Name/Documents/Project_Name . projectname es literalmente el nombre del proyecto, pero puede ser cualquier cosa que quieras llamarlo. A Git no le importa, lo harás.

Para usar scp, debe tener una count de usuario en el server remoto que tenga acceso SSH . Cualquiera que ejecute su propio server tendrá esto. Si está usando un alojamiento compartido o similar, puede que no tenga suerte.

remotehost.com es el nombre de su host remoto. Podrías usar fácilmente su dirección IP. Solo para mayor claridad estoy usando Gitosis en el host remoto con keys SSH, por lo que no me piden passwords cuando presiono. El artículo Hosting Git Repositories, Easy (y Secure) Way te dice cómo configurar todo.

La mejor manera de hacer esto es:

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

Esto clonará el repository, pero no hará ninguna copy de trabajo en .../remote . Si miras el control remoto, verás un directory creado, llamado currentrepo.git , que es probablemente lo que deseas.

Luego, desde su repository local de Git:

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

Después de hacer cambios, puede:

 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 stonetworking 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!)

a

 [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