¿Por qué "git push helloworld + master: master" en lugar de solo "git push helloworld"?

Question

Traté de empujar mi (primera vez!) Repositorio git como este principio:

$ git push helloworld 

Pero tengo la espalda:

To git-smichaels@free5.projectlocker.com:helloworld.git 
! [rejected]  HEAD -> master (non-fast forward) error: 
failed to push some refs to 'git-smichaels@free5.projectlocker.com:helloworld 
git' 

así que encontré another StackOverflow question sobre "compromete modificadas" y optó por una sugerencia desde allí sin saber realmente si me ayudaría:

KaiserSosa@SMICHAELS /c/test/helloworld (master) 
$ git push helloworld +master:master 

¡Funcionó!

Pero no sé por qué se fija mi problema :(

Podría alguien explicar por qué esto funciona, pero "git push helloworld" no?

Answer 1

Parece que ha vuelto a escribir su historial (SHA-1 asociado con sus cometer) en su rama principal

Eso quiere decir, que ya no se puede insertar en un modo de avance rápido

las fuerzas master + el empuje a tener lugar:..
Por teniendo el lead + opcional, puede decirle a git que actualice el ref <dst> incluso cuando la actualización no sea un avance rápido.

Nota: esto podría ser malo si alguien más ya ha clonado su repositorio, ya que no podrán simplemente extraer su rama principal sin tener algún conflicto.
Vea también este SO answer for more.

---

Nota: como se ha mencionado by Junio C. Hamano:

Existen dos mecanismos de seguridad independientes:

• la seguridad extremo emisor puede ser anulado por "git push --force" y/o mediante el uso de una refspec con el prefijo '+');

• la seguridad del extremo receptor puede ser anulada por la variable de configuración receive.denynonfastworwards del repositorio en el que está insertando.

Este último defecto es "insegura", pero si la seguridad está activada en el repositorio, lo que obliga desde el lado emisor no desactivarlo. IOW, ambos extremos deben aceptar permitir el comportamiento inseguro.

---

Como se mencionó en el Git FAQ, un posible curso de acción es:

La razón más probable para esto es que se necesita para tirar de la primera distancia. Puede ver lo que cambia el lado remoto obteniendo primero y luego verificando el registro.Por ejemplo,

$ git fetch origin 
$ git log master..origin/master 

una lista de todos los cambios en el lado remoto tiene su lado que no lo hace.
Si desea una representación gráfica, use gitk --left-right master...origin/master.
Las flechas a la izquierda son cambios que desea presionar, las flechas a la derecha son cambios en el lado remoto.

otra solución (que es lo que hizo):

$ git push origin +branchname 

Esto obligará a la actualización. Si no tiene permiso, entonces a veces esto funcionará:

$ git push origin :branchname 
$ git push origin +branchname 

es decir, eliminar la rama remota primero (esto es a menudo permitido), a continuación, volver a empujar el "nuevo" (o tal vez rebobinado) rama.

Tenga en cuenta que si rebobina ramas, otras pueden tener problemas al tirar.
Existe la posibilidad de que se fusionen en la rama que obtuvieron con la nueva que ha publicado, conservando de manera efectiva los cambios que intenta deshacerse.
Sin embargo, solo serán sus copias las que tengan las malas revisiones. Por esta razón, rebobinar ramas se considera levemente antisocial. Sin embargo, a menudo es apropiado.