He configurado un repositorio "principal" remoto no descubierto y lo he clonado en mi computadora. Hice algunos cambios locales, actualicé mi repositorio local y devolví los cambios a mi repositorio remoto. Las cosas estaban bien hasta ese punto.

Ahora, tuve que cambiar algo en el repositorio remoto. Luego cambié algo en mi repositorio local. Me di cuenta de que no era necesario el cambio al repositorio remoto. Así que intenté git pushdesde mi repositorio local a mi repositorio remoto, pero recibí un error como:

Para evitar que pierda el historial, se rechazaron las actualizaciones que no son de avance rápido. Combine los cambios remotos antes de presionar nuevamente. Consulte la sección 'Nota sobre avance rápido' git push --helppara obtener más detalles.

Pensé que probablemente un

git push --force

obligaría a mi copia local a empujar los cambios a la remota y la haría igual. Obliga a la actualización , pero cuando vuelvo al repositorio remoto y realizo una confirmación, noto que los archivos contienen cambios desactualizados (los que el repositorio remoto principal tenía anteriormente).

Como mencioné en los comentarios a una de las respuestas :

[Intenté forzarlo, pero cuando vuelvo al servidor maestro para guardar los cambios, me quedo obsoleto. Por lo tanto, cuando confirmo los repositorios no son lo mismo. Y cuando trato de usar git push nuevamente, aparece el mismo error.

¿Cómo puedo solucionar este problema?

Solo haz:

git push origin <your_branch_name> --force

o si tienes un repositorio específico:

git push https://git.... --force

Esto eliminará sus confirmaciones anteriores y empujará la actual.

Puede que no sea apropiado, pero si alguien se topa con esta página, pensó que podría querer una solución simple ...

Bandera corta

También tenga en cuenta que -fes la abreviatura de --force, entonces

git push origin <your_branch_name> -f

También funcionará.

Y si push --forceno funciona puedes hacerlo push --delete. Mire la ^2ª línea en esta instancia:

git reset --hard HEAD~3  # reset current branch to 3 commits ago
git push origin master --delete  # do a very very bad bad thing
git push origin master  # regular push

Pero cuidado...

¡Nunca vuelvas a una historia pública de git!

En otras palabras:

• Nunca forceempujes un repositorio público.
• No hagas esto ni nada que pueda romper el de alguien pull.
• Nunca lo hagas reseto la rewritehistoria en un repositorio que alguien ya podría haber hecho.

Por supuesto, hay excepciones excepcionalmente raras incluso a esta regla, pero en la mayoría de los casos no es necesario hacerlo y generará problemas para todos los demás.

Haz una reversión en su lugar.

Y siempre tenga cuidado con lo que empuja a un repositorio público . Revertir:

git revert -n HEAD~3..HEAD  # prepare a new commit reverting last 3 commits
git commit -m "sorry - revert last 3 commits because I was not careful"
git push origin master  # regular push

En efecto, ambos HEADs de origen (del reversión y desde el reinicio del mal ) contendrán los mismos archivos.

editar para agregar información actualizada y más argumentos sobre push --force

Considere empujar la fuerza con arrendamiento en lugar de empujar, pero aún así prefiere revertir

Otro problema que push --forcepuede traer es cuando alguien empuja algo antes que tú, pero después de que ya hayas ido. Si presiona forzar su versión reforzada ahora lo hará reemplazará el trabajo de otros .

git push --force-with-leaseintroducido en el git 1.8.5 ( gracias al comentario de @VonC sobre la pregunta) intenta abordar este problema específico. Básicamente, traerá un error y no empujará si el control remoto fue modificado desde su última búsqueda.

Esto es bueno si está realmente seguro de que push --forcese necesita, pero aún así quiere evitar más problemas. Me atrevería a decir que debería ser el push --forcecomportamiento predeterminado . Pero aún está lejos de ser una excusa para forzar a push. Las personas que buscaron antes de tu rebase todavía tendrán muchos problemas, que podrían evitarse fácilmente si hubieras revertido en su lugar.

Y como estamos hablando de git --pushinstancias ...

¿Por qué alguien querría forzar el empuje?

@linquize trajo un buen ejemplo de fuerza de empuje en los comentarios: datos confidenciales . Ha filtrado información erróneamente que no debe ser enviada. Si eres lo suficientemente rápido, puedes "arreglarlo"* forzando un empujón en la parte superior.

*Los datos seguirán estando en el control remoto a menos que también haga una recolección de basura o la limpie de alguna manera . También existe el potencial obvio de que otros usuarios ya lo hayan contagiado , pero se entiende la idea.

En primer lugar, no haría ningún cambio directamente en el repositorio "principal". Si realmente quieres tener un repositorio "principal", entonces solo debes presionarlo, nunca cambiarlo directamente.

Con respecto al error que está recibiendo, ¿ha intentado git pulldesde su repositorio local y luego git pushal repositorio principal? Lo que está haciendo actualmente (si lo entendí bien) es forzar el empuje y luego perder sus cambios en el repositorio "principal". Debe fusionar los cambios localmente primero.

Si estoy en mi rama local A, y quiero forzar el empuje de la rama local B a la rama de origen CI, puedo usar la siguiente sintaxis:

git push --force origin B:C

use este siguiente comando:

git push -f origin master

Realmente recomendaría:

• empujar solo al repositorio principal

• asegúrese de que el repositorio principal sea un repositorio simple , para nunca tener ningún problema con el árbol de trabajo del repositorio principal que no esté sincronizado con su .gitbase. Consulte " ¿Cómo enviar un repositorio git local a otra computadora? "

• Si tiene que hacer modificaciones en el repositorio principal (desnudo), clónelo (en el servidor principal), realice su modificación y vuelva a presionarlo

En otras palabras, mantenga un repositorio desnudo accesible tanto desde el servidor principal como desde la computadora local, para tener un único repositorio ascendente desde / hacia el cual extraer / extraer.

Esta fue nuestra solución para reemplazar master en un repositorio corporativo de gitHub mientras se mantenía el historial.

push -fdominar en repositorios corporativos a menudo está deshabilitado para mantener el historial de la sucursal. Esta solución funcionó para nosotros.

git fetch desiredOrigin
git checkout -b master desiredOrigin/master // get origin master

git checkout currentBranch  // move to target branch
git merge -s ours master  // merge using ours over master
// vim will open for the commit message
git checkout master  // move to master
git merge currentBranch  // merge resolved changes into master

empuja tu rama hacia desiredOriginy crea un PR

Tenía la misma pregunta, pero finalmente lo descubrí. Lo más probable es que necesite ejecutar los siguientes dos comandos git (reemplazando el hash con el número de revisión git commit):

git checkout <hash>
git push -f HEAD:master