GIT: las requestes de extracción de la misma twig muestran el historial de confirmaciones

Esta es la configuration en uno de mis repositorys:

  • twig master <- esto siempre está en el server de producción
  • bifurcación de staging (bifurcación pnetworkingeterminada) <- esto está en el server de etapas

Cada cambio que hacemos pasa por los siguientes pasos. Digamos que tengo que hacer un cambio en readme.md .

  1. Creé una nueva twig desde la twig pnetworkingeterminada ( staging ), llamémosla patch-readme
  2. Realizo todos los cambios que necesito en el patch-readme .
  3. Cuando estoy satisfecho con mis cambios, creo un RP para la staging en staging .
  4. Me fusiono (squash y fusionar) el PR y luego borro el patch-readme .
    • (Nota: varios desarrolladores podrían presionar a la twig de staging en este punto, siguiendo los pasos anteriores)
  5. staging twig de staging se despliega luego en el server intermedio.
  6. Si estoy contento con los cambios en el server de transición, creo un nuevo RP desde la staging hasta el master .
  7. Luego reviso los cambios y fusiono (squash y merge) la request de extracción.
  8. En este punto, fusiono al master nuevo en la staging en staging . Estoy haciendo esto porque si el siguiente RP a la staging en staging tiene un cambio en el file readme.md , cuando creo el nuevo RP de la staging de master , readme.md un conflicto en ese file. Para evitar conflictos, me estoy fusionando de nuevo master después de cada PR fusionada.

Hay un problema con este flujo de trabajo, básicamente, cada request de extracción de staging a master está generando compromisos desde hace meses, lo que significa un desastre en el repository (por ejemplo, si hay un compromiso que hace reference a un problema, ese problema tendrá un largo list de references, una por cada nueva RP creada).

Ahora, algo que no entiendo es que a veces (no he descubierto en qué circunstancias) esa historia se limpia. Hoy me pasó porque un desarrollador se olvidó de actualizar desde el master después de fusionar un RP y tuve que solucionar algunos conflictos, después de solucionar los conflictos, el nuevo RP tenía un historial limpio. Intenté replicar este escenario pero no parece hacer lo mismo.

He echado un vistazo a la rebase, así que lo que probé después de fusionar el PR de la staging de master , en lugar de fusionar el master , ejecuté un git rebase master mientras estaba en la twig de staging . Esto no funcionó, el PR próximo al master todavía tenía historia previa.

Algo que funcionó es que en lugar de crear un RP para master , corrí

 git checkout master git rebase staging 

En este caso, no tuve que hacer nada y el siguiente PR la historia estuvo limpia. Pero esto no tiene mucho sentido porque tendremos que descartar los RP. Estamos usando relaciones públicas para la revisión del código.

¿Qué estoy haciendo mal? ¿Cómo puedo tener cada vez un historial limpio en el PR desde la staging hasta el master ?

Solo una nota aquí, nuestros desarrolladores generalmente usan solo Github Desktop y la interfaz web de Github . Y debido a que somos un equipo pequeño, todos pueden crear y fusionar relaciones públicas tanto para la staging como para el master .