Cómo mantener un historial de git limpio

como parte de mi trabajo utilizo para hacer deployments entre nuestros entornos dev / test / prod

Usamos para administrar nuestro código con el conocido flujo de bifurcación, por lo que tenemos la siguiente twig:

dev -> donde todas las twigs se fusionan como una única confirmación cuando se implementa una característica

testing -> donde usamos para probar nuestro código usando la plataforma

master -> esta twig se usa solo para crear tags que luego se usarán en nuestro server de producción

Recientemente quise encontrar una manera de mantener el historial del código tan limpio como sea posible, pero estoy luchando sobre cómo hacerlo fácilmente.

Creé un repository y reproduje un flujo para que puedas entender por qué estoy luchando

entonces, después de la confirmación inicial, creé las 2 twigs dev y test y cambié a dev para hacer las siguientes commits e hice 3 commits:

9e76b6d – koop4: característica anawesome añadida que hace la vida más fácil

44976b1 – koop4: característica anawesome añadida que hace la vida más rápida

64ea9d3 – koop4: característica anawesome añadida que hace la vida más shiny

Hice una request de extracción para poner esas características en testing y squash-fusionarlas con un compromiso singe. También me gusta pegar como comentario los resultados del command git

git log --pretty=format:"%h - %an: %s" test..dev 

Esto nos lleva a esto historial de prueba

A veces sucede que más características pasan por este ciclo hasta que todo esté listo para la producción. ¡Evitemos la networkingundancia y avancemos con otra request de extracción !

Nota: en prod usamos para usar como post de confirmación el nombre de la label

¡Lo hicimos! ¡Ahora tenemos una historia súper limpia en todo nuestro entorno! ¡Estupendo!

historia maestra

Entonces, ¿qué es el poblem? Repetiremos el ciclo agregando nuevos commits en dev:

ca215e8 – koop4: esto te hará cagar los pantalones

9e76b6d – koop4: agregamos una característica aterradora que nos hace enloquecer

deja crear la request de extracción y … Espera … ¿qué? ¿Por qué dice que sigo perdiendo estos commits?

enter image description here

Ok ok, entiendo el concepto, pero a este punto creo que te diste count de mi lucha. Para mantener mi historial limpio, tengo que elegir por mí mismo los compromisos que necesito: enter image description here

e incluso repite el process para nuestra request de extracción maestra.

Al final, con un poco de fontanería, puedo get una gran historia para todos los entornos, pero cuando las cosas empiezan a crecer, me cuesta entender qué compromiso tengo que poner en el comentario de compromiso para mantenerlo limpio.

¿Hay alguien con la sugerencia de mantener una historia limpia sin tener que luchar tanto?

La mitad del problema es que estás usando la interfaz GUI web de GitHub. 🙂 (estoy bromeando sobre que esto es la mitad del problema, 1 pero de hecho, está ocultando un detalle importante).

La otra mitad del problema es que estás usando una llamada "fusión de squash", que no es una combinación . Vea esta respuesta para más detalles.

Cuando usas squash "merge", el efecto es que debes abandonar los commit que ahora están aplastados. Esos compromisos antiguos (puede haber muchos, como en el caso de los tres en su ejemplo) han sido suplantados por un único compromiso nuevo . (Puede y debe get ese compromiso en el origin/test su propio Git, ya que lo hizo a través de la interfaz GUI de GitHub en lugar del método más sensato para hacerlo en su propio repository, en su propia twig de test , y luego presionar nuevo compromiso directamente.)

Cómo hacer esto con la GUI de GitHub

Una manera fácil de abandonar esos commits es abandonar completamente su propia twig de test , por ejemplo, simplemente eliminarla. Tu Git no sabrá que esto es algo seguro de hacer, por lo que tendrías que forzarlo a eliminarlo. También debería estar en otra twig, ya que no puede eliminar su twig actual. Luego puede crear una nueva sucursal usando la misma test nombre, pero apuntando a su origin/test actualizada como ascendente. Ahora tiene en su test local la confirmación de reemploop único (y todas las confirmaciones anteriores) en lugar de las tres confirmaciones (y todas las confirmaciones anteriores).

Ese método particular requiere al less dos, y generalmente tres commands de Git, aunque: git checkout dev (para salir de la test ), git branch -D test (para eliminar la test peligrosa y forzada), y git checkout -b test (para volver crear test ). Puedes usar solo un command peligroso de Git en su lugar: git reset --hard origin/test (nuevamente, después de ejecutar git fetch para get el origin/test actualizado).

Cómo hacer esto sin usar la GUI de GitHub, de forma segura

Todo lo anterior es molesto e innecesario . Simplemente evite la GUI. Cuando tenga la twig de test funcionando de la forma que desee, haga su propia rebase interactiva y aplane las tres confirmaciones en una sola.

 $ git rebase -i 

Edite los tres commands de pick para que el primero sea pick y los dos últimos sean squash , escriba el file y salga del editor. Luego, en la nueva session del editor, edite el post de confirmación en la versión "agradable" (confirmación única). Tenga en count que no es necesario mantener las ID de hash sin formatting de las tres confirmaciones originales, que nunca serán útiles en el futuro, ni siquiera ninguno de los posts de text de esas confirmaciones: puede build un nuevo post de confirmación mejorado.

Ahora tendrá, en su propia twig de test (y en ningún otro lugar), la confirmación aplastada. Ahora puede git push origin test de empuje para enviarlo al repository de GitHub.

También tendrá que hacer algo para matar su request de extracción pendiente como cerrada por la confirmación de sustitución empujada. Como no uso tanto GitHub, no estoy seguro de qué es eso. Puede ser tan simple como include "cierra #XX" en el post de confirmación o, por supuesto, puede hacerlo manualmente a través de su GUI web.


1 ¿Esto lo convierte en 1/4 del problema?