¿Cómo se compromete una copy sin producir SHA1 diferentes?

Por mucho que haya tratado de evitarlo, tengo que mantener tres twigs master -equivalentes con cambios menores en cada una. He estado leyendo sobre git y lo uso durante un par de años, por lo que estoy familiarizado con la siguiente sabiduría convencional:

  1. No te merge less que sea significativo. Use rebase en rebase lugar.
  2. Si solo necesitas retirar una confirmación, cherry-pick es tu amigo.
  3. Siempre pull --rebase en el control remoto antes de empujar.
  4. Mantenga las características en línea con rebase .

Lo que no le dicen es que la sabiduría convencional crea un set de compromisos que son casi idénticos, excepto por pequeños detalles que cambian sus SHA1. ¿Por qué importa esto? Se derrota el propósito de comparar las twigs con el git log --left-right --graph --cherry-pick --oneline branch1..branch2 y git show-branch , que es especialmente molesto. Se siente como un abuso de ramificaciones baratas. Hace que sea casi imposible ver qué parches faltan en cada twig.

Entonces, ¿cómo mantener múltiples twigs en línea con SHA1s idénticos para que estas herramientas puedan ser utilizadas? ¿Son los parches la mejor manera de hacer esto?

No puede mantener confirmaciones con SHA idénticos en varios lugares porque el SHA identifica el "lugar" de una confirmación (su location en el historial).

Una confirmación de Git contiene ciertos datos, entre ellos una instantánea del estado del reintegro actual, la hora y la date actuales, el nombre y el correo electrónico del confirmador y el SHA de la (s) confirmación (es) principal (es) .

Eso significa que cuando pones un commit en otro lugar ( rebase , cherry-pick , patch + apply) o cambias su hora ( commit --amend ), el SHA será diferente.

Esta es una característica importante de Git (la historia de Git es un tree llamado Merkle ).

Como habrás notado, puedes mantener (equivalentes) compromisos equivalentes usando los diversos commands de reescritura de historial que mencioné anteriormente.


Dependiendo de su situación, es posible que pueda usar las confirmaciones que están en el master sin tener que copyrlas. Si los cambios que hacen que sus twigs " master -equivalentes" sean diferentes son puramente aditivas (es decir, ocurren en compromisos que siempre se pueden agregar a la última confirmación en el maestro), entonces siempre puede volver a establecer las otras twigs en el master y ser feliz, porque entonces simplemente contienen todos los commits del master exactamente como son.

Si sus cambios son, por otro lado, de un tipo que debe insertse antes en la historia (es decir, los nuevos commits de master deben agregarse después de sus cambios diferenciadores), entonces no podrá mantener un historial "agradable" como ese.

No puedo pensar espontáneamente en un ejemplo de la segunda situación, pero es teóricamente posible (ya sea requerido por el contenido o requerido por factores externos como las especificaciones del proyecto).

No creo que sea sabiduría convencional no fusionarse a less que sea significativo. Si desea conservar el historial con los hashes SHA1 idénticos, fusione y evite el "cherry-picking".