Reescribir automáticamente el historial completo de git para deshacerse de las fusiones simples

Question

Nuestro equipo utiliza un flujo de trabajo git puramente basado en fusión, y estamos discutiendo la posibilidad de pedir a todos los miembros del equipo que lleven todo al servidor una tarde y lo hagan una tarde de rebase del servidor repo.

Creo que lo que me gustaría hacer automáticamente es que siempre que todas las confirmaciones se realicen solo en el mismo conjunto de ramas Y el número de confirmaciones paralelas esté por debajo de un umbral determinado, me gustaría volver a establecer la base de la serie y eliminar la (s) confirmación (es) de fusión. Pero estoy abierto a sugerencias?

¿Alguien sabe cómo hacer esto?

Answer 1

En mi opinión, debe evitar la tentación de volver a escribir la historia solo para que se vea bien. Realmente no tiene sentido. La historia, tal como es, es una representación más precisa de la realidad y las herramientas de informes de git están diseñadas para ser útiles incluso con muchas fusiones pequeñas.

Si no le interesa ver muchas fusiones, puede suprimirlas de muchas tareas de informes, p.

git log --no-merges 

Lo que están proponiendo (una noche de cambio de base, presumiblemente, haciendo que todos los desarrolladores tienen que reset) parece como la creación de trabajo por el trabajo mismo.

Answer 2

No estoy seguro de qué tan simple podría ser esto. Si haces un rebase -i, intentará ignorar todas las fusiones, lo que se logrará para las fusiones sin conflicto, pero se detendrá y esperará en caso de que haya un conflicto.

Si lo invoca como rebase -i -p, por otro lado, conservará las fusiones, que es lo que desea cuando el usuario realizó una fusión real, pero omite por completo el punto de otro modo.

Quizás alguna secuencia de los dos comandos, preservar las fusiones solo cuando lo desee, podría hacer el trabajo en este caso.

Debo estar de acuerdo con Charles, sin embargo, que tener la historia reflejada en la realidad es mucho más valioso que hacerlo "parecer bonito". El hecho es que un compromiso se realizó sin conocimiento del otro y, en el caso del código fuente, esto puede indicar por qué algo pudo haber salido mal.

Nuestro equipo utiliza un flujo de trabajo git puramente a base de fusionar

¿Qué hay de malo en tirar siempre con --rebase (por ejemplo git pull -r)? Si desea una topología plana, la forma más sencilla es no fusionarse cuando pueda volver a establecer la base.

Además, dices que solo quieres aplanar si "la fusión está limpia". Solo estoy especulando aquí, pero no creo que git registre conflictos después del hecho que no sea una nota en el mensaje de confirmación predeterminado, que puede que aún no esté allí.