git – omisión de confirmaciones específicas cuando se fusiona

Llevo un año usando Git y creo que es fantástico, pero acabo de comenzar una segunda versión del proyecto y comencé una nueva twig para él. Estoy luchando un poco con la mejor manera de manejar las cosas en el futuro.

Tengo dos twigs llamadas say master10 (para v1) y master20 (para v2). He estado haciendo correcciones de errores en v1 en branch master10, y desarrollando nuevas cosas de master20. Cada vez que hago una corrección de errores la fusiono en v2 revisando master20 y haciendo git merge master10 . Hasta aquí todo bien.

Ahora, sin embargo, hice un cambio en v1 que no quiero en v2, pero quiero continuar fusionando otras correcciones de errores. ¿Cómo le digo a Git que omita esa confirmación en particular (o un range de confirmaciones), pero que en el futuro sigo queriendo combinar otras correcciones de errores?

Pensé que git rebase podría ser lo que necesito, pero leí el documento y mi cabeza casi explotó.

Creo que lo que quiero es algo así como un command "git sync" que le dice a git que dos twigs están ahora sincronizadas y en el futuro solo fusionan las confirmaciones desde este punto de synchronization.

Cualquier ayuda apreciada.

Si desea fusionar la mayoría pero no todas las confirmaciones en la twig "maint" a "master", por ejemplo, puede hacerlo. Requiere algo de trabajo —- como se mencionó anteriormente, el caso de uso habitual es fusionar todo de una twig — pero a veces sucede que usted hizo un cambio a una versión de lanzamiento que no debería ser integrada de nuevo (tal vez ese código sido reemplazado en el maestro ya), entonces, ¿cómo lo representas? Aquí va…

Entonces, supongamos que maint ha aplicado 5 cambios, y uno de ellos (maint ~ 3) no debe fusionarse de nuevo en master, aunque todos los demás deberían estarlo. Usted hace esto en tres etapas: en realidad fusionar todo antes de eso, decirle a git que marque maint ~ 3 como fusionado incluso cuando no lo esté, y luego fusionar el rest. La magia es:

 bash <master>$ git merge maint~4 bash <master>$ git merge -s ours maint~3 bash <master>$ git merge maint 

El primer command combina todo antes de que tu manuscrito problemático se comprometa con el maestro. El post de logging de fusión pnetworkingeterminado explicará que está fusionando "twig 'maint' (parte inicial)".

El segundo command combina el molesto command ~ 3 commit, pero la opción "-s ours" le dice a git que use una "estrategia de combinación" especial que, de hecho, funciona simplemente manteniendo el tree en el que se está fusionando e ignorando el compromiso (s) ) te estás fusionando completamente. Pero todavía hace una nueva fusión se compromete con HEAD y maint ~ 3 como los padres, por lo que el gráfico de revisión ahora dice que maint ~ 3 se fusionó. Entonces, de hecho, probablemente también quieras usar la opción -m para 'git merge', para explicar que esa confirmación de maint ~ 3 está siendo ignorada.

El command final simplemente combina el rest de maint (maint ~ 2..maint) en master para que todos estén sincronizados de nuevo.

En mi humilde opinión, lo más lógico es fusionar todo, y luego usar git revert (commit_you_dont_want) para eliminarlo .

Ejemplo:

 git merge master git revert 12345678 

Si tiene varias confirmaciones de "omisión", o desea editar el post de reversión:

 git merge master git revert -n 123456 git revert -n abcdef git commit -m "... Except commits 123456 and abcdef" 

Entonces su historia puede verse así:

 | ... Except 123456 and abcdef |\ Merge branch 'master' into 'your_branch' 

Si tiene conflictos que involucran SOLAMENTE estos commits "to-ignore", puede usar:

 git merge master -X ours 

Entonces tu versión persistirá sobre la otra. Incluso sin posts de error, aún puede "revertir" esos commits no deseados, ya que pueden tener otros cambios que no entraron en conflicto, y aún así no los quiere.

Si tiene conflictos que involucran NO SOLAMENTE los commits "to-ignore", debe resolverlos manualmente, y probablemente tendrá que resolverlos nuevamente durante la reversión.

Los compromisos incluyen ascendencia. No puede fusionar una confirmación sin fusionar compromisos previos.

Puedes elegirlos, por supuesto. Ese es un flujo fino cuando tienes una twig que está en modo de mantenimiento.

Una especie de publicidad de mi proyecto que básicamente envuelve el process descrito por @araqnid.

Es una especie de ayudante que presenta el siguiente flujo de GIT:

  • hay una notificación diaria / semanal sobre las fusiones pendientes de las twigs de mantenimiento en la twig dev / master
  • El mantenedor de twig verifica el estado y decide si se requieren todas las confirmaciones y bloquea algunas o les pide a los desarrolladores que se bloqueen. En la twig de mantenimiento final se fusiona en el upsteam.

Una cita de la página del proyecto:

Dependiendo del flujo de trabajo, es posible tener twigs de mantenimiento o específicas del cliente junto con la twig principal. Estas twigs también se llaman twigs LTS.

A menudo, las correcciones urgentes van a las twigs donde se informó el error y luego la confirmación se fusiona nuevamente en la twig principal.

La práctica general es tener todas las twigs perfectamente sincronizadas con el maestro, es decir, desea ver un delta claro entre una twig y un maestro en particular para comprender si el maestro contiene todas las características y las correcciones de errores.

Sin embargo, a veces no desea compromisos específicos porque son específicos del cliente y no deben ser visibles por otros usuarios. O su twig principal divergió tanto que requiere un enfoque completamente diferente para solucionar el problema, o mejor aún, el problema ya no está presente allí.

También en el caso de la selección de cereza desde el maestro a la twig de mantenimiento, la confirmación resultante se bloqueará en el maestro.

Cree una tercera twig para los cambios que desee en master10 pero no en master20. Siempre considere master10 como su "maestro", la twig más estable de todas. La twig con la que todas las otras twigs quieren estar sincronizadas en todo momento.