¿Cómo envío los cambios a un repository de git con historial conflictivo?

Quiero tener un depósito bendecido y varios repositorys de grupos o desarrolladores.

Los desarrolladores clonarán del trabajo del repository bendito en ese repository clonado y confirmarán sus cambios. Cuando sientan que su trabajo está completo, deberán enviar sus cambios a su repository público. Luego, el desarrollador principal deberá extraer los cambios del repository público de desarrolladores: haga lo que quiera con él (cerrar la session, modificar, etc.) y luego enviarlo al depósito bendecido.

flujo de trabajo distribuido

En cualquier entorno donde el código de recuento de revisiones de código pueda ser rechazado. Asum que el desarrollador A y B trabajan en una característica al mismo time. Ambos desarrolladores terminan su trabajo y empujan los parches a su repository público. Los parches del desarrollador A son aceptados mientras los parches del desarrollador B son rechazados. Luego, el desarrollador principal empuja los cambios del desarrollador A al repository bendito. El desarrollador B arregla los parches y rebases su trabajo en la parte superior del repository bendito (los cambios aceptados del desarrollador A, respectivamente). Si el desarrollador B lleva su trabajo ahora a su repository público, recibirá un error de que los repositorys tienen historiales incompatibles.

La única forma en que podía arreglar eso era eliminar el repository público y recrear el repository. ¿Hay una manera más limpia de arreglar eso?

Teniendo en count que el repo público tiene solo para el cliente el gerente de integración, B puede forzar de forma segura su trabajo:

git push --force 

El gerente de integración no ha aceptado ninguna de las confirmaciones de B, por lo que B puede reescribir el historial de sus confirmaciones y volver a presionarlas.
¿Alguien más podría clonar / sacar del repository público de B, y luego un push --force no se consideraría una solución aceptable.


El OP Alex agregó en los comentarios:

Entonces lo entiendo bien? si alguien saca de B el flujo de trabajo se rompe porque el repository bendito no es un subset estrictamente orderado de B?

Respondí:

Si alguien más sacó del repository público de B, entonces ese historial se hace público (lo cual no está en su escenario, ya que solo el gestor de integración saca, y ni siquiera mantiene las confirmaciones de B).
Y no deberías rebasear la historia pública. Vea la sección " el peligro de volver a basar " del libro Pro-Git

Entonces, si tengo una revisión para presionar al bendito repository, ¿mataría todas las cosas de mi repository público para estar lo más cerca posible del bendecido? ¿O cómo sería el plomo luego recoger las revisiones de cereza?

Si tiene otras cosas en su repository público que aún no han sido aceptadas, podría publicar su revisión en una twig dedicada ' hot_fix ' (que B ha sido reajustada primero sobre el repository bendecido, y luego empujada al repository público de B), monitoreado por el gerente de integración solo por eso.

De todos modos, el punto es: ese gestor de integración siempre espera nuevas confirmaciones además de su set existente de confirmaciones, nuevo historial , no un historial conflictivo (debido a la falta de rebase de B).
Cualquier historia en conflicto debe ser rechazada, cualquiera que sea el origen de la twig.

Y tenga cuidado con la recolección de cerezas, puede ocasionar problemas. Ver:

  • " En Git, ¿cómo aplicas un compromiso de corrección de errores a las otras twigs más nuevas? "
  • " haz un git cherry-pick en múltiples twigs "

Puede cambiar arbitrariamente el historial en un repository público utilizando push -f para forzar la actualización del control remoto. Dado que el desarrollador individual es el único que debería cambiar su propio repository público, esto normalmente es seguro.