Flujo de trabajo del integrador. ¿Es seguro fetch-rebase-push para repositorys remotos?

Estoy administrando un repository git usando el flujo de trabajo del integrador. En otras palabras, retiro los compromisos de mis compañeros de trabajo y los empujo hacia el bendito repository.

Me gustaría mantener el historial de confirmación lineal para la mayoría de los casos, entonces ¿está bien hacer una rebase lugar de una merge cuando integre los cambios? Aquí hay un ejemplo:

 git fetch coworker git checkout coworker/master git rebase master git checkout master git merge HEAD@{1} git push 

Me preocupa lo que sucederá con los repos remotos cuando hagan su próximo git pull . ¿Podrá Git ser capaz de manejar esto, o fallará el repository del coworker durante la pull , ahora que las confirmaciones están en un order diferente en el origin ?

Actualización : Originalmente tuve el ejemplo de rebase de la twig 'coworker' de 'master'. Lo que pretendía era todo lo contrario, poner los compromisos del 'compañero de trabajo' sobre el maestro. Así que actualicé el ejemplo.

Definitivamente no quiere hacer lo que sugiere, volverá a establecer la base de la twig master el master su compañero de trabajo. Dependiendo de en qué se basó el master su compañero de trabajo, puede terminar rebobinando el master central.

Lo que podría querer hacer es lo opuesto, rebase el maestro de su compañero de trabajo antes de fusionarlo en maestro.

 git fetch coworker git checkout coworker/master git rebase master git checkout master git merge HEAD@{1} git push 

Sin embargo, aún no lo recomendaría. Sus compañeros de trabajo tendrán que resolver cómo networkingefinió sus cambios. La mayoría de las veces es probablemente trivial y pueden descartar sus compromisos a favor de los suyos, pero es algo que probablemente necesiten verificar manualmente.

Personalmente, recomendaría una fusión directa de sus compromisos. Si crees que están basados ​​en una versión de maestro demasiado antigua y la fusión será innecesariamente compleja o se basará en un compromiso injustificadamente antiguo, haz que rebase su maestro y vuelva a intentarlo. Entonces, al less, saben lo que se está fusionando y resuelven cualquier conflicto en su código.

Además, me gustaría advertir contra el objective de la historia innecesariamente lineal. La fusión en las twigs de desarrolladores desarrolladas en paralelo le da una representación más verdadera de la historia. Si rebase la confirmación de un desarrollador antes de fusionarse, ya no tendrá un logging de confirmación que sea una representación exacta del estado exacto del código que el desarrollador haya corregido y enviado. Puede que esto no importe muy a menudo, pero puede suceder que dos compromisos interactúen para producir un error, pero no un conflicto de fusión. Si no rebase, obtendrá una 'culpa' más precisa (¡y más justa!).

La gran mayoría de la gran cantidad de documentation y tutoriales sobre git dejan en claro que la rebase debe usarse solo en sucursales privadas, nunca algo que otra persona pueda ver. De acuerdo con su model, le temería a fallas inexplicables o tendría que repetir el trabajo en otras réplicas. ¡Evitar!

Como se menciona en el artículo "¿ Una tregua en la fusión frente a la guerra de base? ", (Énfasis mío)

Quizás el peor problema con el rebasamiento tradicional es que impide la queueboración .
Alguien que saca de un repository antes y después de un rebase experimentará conflictos porque las dos historias se contradicen entre sí. Por lo tanto, la advertencia estándar "no volver a establecer la base en un repository publicado", que se puede volver a networkingactar para "no queueborar en el trabajo que más adelante desee volver a establecer".

Incluso si "funciona" debido a la falta de conflictos, puede ocasionar algunos problemas si tiene que resolver una fusión no trivial durante su rebase:

 M0----M1----M2 \ \ \ B1----B2 M0----M1----M2 \ \ \ B1'---B2' 

El SHA-1 de su twig (previamente publicada) se reescribe, sus colegas tendrán dificultades para fusionar esa twig en su entorno.

Este sería un flujo de trabajo aceptable para casos triviales. Cuando tus compañeros de trabajo hacen un " git pull , es realmente una git fetch seguida de una git merge . Git es realmente bueno en fusionar y podrá resolver casos simples sin problemas.

Sin embargo, si tiene que hacer algún trabajo para resolver conflictos en el paso de git rebase , entonces sus compañeros de trabajo pueden tener que hacer ese trabajo nuevamente cuando lo hagan. Eso sucederá porque su secuencia de commits se ve muy diferente a la suya después de la rebase.

Si te sientes cómodo con un historial no lineal, es probable que Git pueda administrar mejor este flujo de trabajo (ya que está diseñado para manejarlo).

Hice algunas testings simples en este flujo de trabajo. Estoy de acuerdo con la publicación de Charles, pero quería agregar otra información.

Pros

  • El flujo de trabajo no afectará a los usuarios que saquen de su repository público.
  • Le da un mayor control sobre las confirmaciones que se incorporan a su línea principal.
  • Es más fácil seguir el historial de características de la twig principal. Si tiene que realizar una confirmación de fusión (flujo de trabajo estándar) para extraer múltiples cambios, la confirmación de fusión agrupará las modificaciones de todas las nuevas confirmaciones en una única confirmación. Esto rompe el modismo de "uno cometer una function".

Contras

  • En el repository desde el que extrae los cambios, las confirmaciones "originales" seguirán apareciendo. Esto probablemente agregará confusión para el queueborador, a less que sepan lo que está haciendo. Supongo que una forma de evitar esto es hacer que el queueborador descarte su twig dev luego de tirar de ella y volver a establecerla.
  • Si los repos remotos no descartan sus twigs dev después de volver a establecer la base, entonces hace que el historial de la twig maestra sea difícil de seguir a lo largo de la twig remota.
  • Después de la rebase, pierdes el nombre del autor original en la confirmación. (Tal vez hay una forma manual de evitar esto.) Esto hace que sea más difícil rastrear quién cometió cada cambio.