Git no pudo confirmar la enmienda después de CherryPick

El escenario es el siguiente

  1. Crear un nuevo commit de cambio y push (hecho OK) no fusionados pero vamos a llamarlo A
  2. Después de un time, git reset –hard origin luego search y volver a basar contra el master 3.cherry elegir el cambio A y actualizar dos files
  3. git add.
  4. git Pull
  5. git commit – enmienda
  6. git push -f origin master

Ahora obtengo el siguiente error:

Total 0 (delta 0), reused 0 (delta 0) remote: Processing changes: done To ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to hint: Updates were rejected because a pushed branch tip is behind its remote hint: counterpart. Check out this branch and integrate the remote changes hint: (eg 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. 

Hice un jalón antes de la confirmación y recibí un post de que está actualizado, ¿alguna idea de lo que echo de less aquí? y ¿cómo debería hacerlo funcionar?

Yo uso intellij

Es el pull y luego commit --amend que estropeó las cosas. Esto es lo que hiciste, visualmente. Después de tirar, el master y el origin/master están en la misma confirmación.

 A - B - C [master] [origin/master] 

Entonces hiciste un commit --amend . Esto toma los cambios entre B y C, más sus nuevas ediciones, y crea un nuevo compromiso D. D's padre es B, por lo que ha creado una twig.

 A - B - C [origin/master] \ D [master] 

origin/master y master ahora han divergido. Cuando intentas push git se rehúsa porque solo se permiten reenvíos rápidos.

Para arreglar este git reset --soft origin/master . --soft retendrá el trabajo en D, pero ahora tu padre es C. Luego puedes hacer un commit normal (no commit commit). Esta es la opción preferida ya que le permite push normalmente y no arruinará el trabajo de nadie más.

  [origin/master] A - B - C - E [master] \ D 

(D será basura recolectada).

Alternativamente, puedes hacer git push --force . Esto le dice a git que D es la nueva sugerencia del master ahora y que tira C. El forzado de un empujón es muy hostil para otros desarrolladores cuyo trabajo basado en C ahora no será válido. Recibirán errores tratando de pull y tendrán que hacer un trabajo para arreglarlo y es un gran desastre.


La regla de oro es que una vez que haya empujado un cambio, no lo vuelva a calcular . git commit --amend count como rebase.

Y no fuerces habitualmente el empuje.