Conflictos de maestro de Git Rebase

Tengo algunos conflictos en una twig cuando vuelvo a basar el maestro en ella.

El escenario es:

Branch off master, realice algunos cambios, confirme dichos cambios. Checkout maestro, realice algunos cambios, confirme dichos cambios, pago y envío branch-1. Intentar rebase maestro – conflicto …

Ahora tengo otros desarrolladores trabajando de manera similar.

El maestro se mantiene sincronizado en todos los repositorys, incluido el server web, no quiero que se cambie el historial del maestro.

Si resuelvo los conflictos de rebase que entran en conflicto con un punto en el pasado, si selecciono el maestro y lo fusiono con la twig (¿se cambiará el historial de los maestros?) O ¿se aplicarán esas resoluciones de conflicto a la cima de todo el trabajo que estoy fusionando?

Si rebase, independientemente de a qué twig rebase, está cambiando el historial de su repository. La idea es que cuando los otros desarrolladores saquen master (de decir origen) después de que haya presionado, sus repos también estarán actualizados.

Para ser claros: fusionar conflictos mientras el rebase no cambiará la historia del maestro. Rebase como un método de fusión lo hará.

Si no desea cambiar el historial de maestro, no puede volver a establecer la base como método de fusión. El comportamiento de fusión pnetworkingeterminado de git debería funcionar bien para ti, conflictos o no.

git checkout master git merge branch-1 

Imagina que tienes la situación actual:

 - A - B - C - D \ ^ - X - Y master ^ branch1 

Ejecutando git checkout branch1; git rebase master git checkout branch1; git rebase master moverá los commits de branch1 para que se apliquen en la parte superior de la twig master :

  master v - A - B - C - D \ - X - Y ^ branch1 

Esto no cambia el maestro , pero cambia branch1 de dos maneras:

  1. Al cambiar el padre de commit X de A a D cambiarás el ID de commit X , de hecho, en lo que respecta a Git, ahora se trata de un nuevo compromiso (y dado que X tiene un nuevo ID, Y tiene un nuevo padre, por lo que Y obtiene una nueva ID, y así sucesivamente si hay más confirmaciones en la sucursal).
  2. Cualquier resolución de conflicto que necesite hacer cambiará el contenido de las confirmaciones.

Si ya ha presionado branch1 a un repository remoto, entonces es una muy mala idea volver a establecer la base; cambiar el historial que ya se ha compartido solo generará problemas.

Asumiendo que no ha empujado a branch1 , puede fusionarlo en master (con git checkout master; git merge branch1 ), lo que dará como resultado que el maestro sea ​​reenviado rápidamente para confirmar Y Esto le proporciona una historia lineal orderada sin tener que cambiar el maestro :

 - A - B - C - D - X - Y ^ branch1 AND master 

Si ya ha presionado branch1 , debe evitar rebase y usar una combinación en su lugar (usando git checkout master; git merge branch1 ), que no cambiará el historial de ninguno de ellos, pero creará un nuevo commit (marcado M en este diagtwig ) en la twig principal:

 - A - B - C - D - M \ / ^ - X - Y - - master ^ branch1