Déjame responder tus puntos directa y claramente:
Nuestro problema es con las ramas laterales a largo plazo, del tipo en el que hay algunas personas que trabajan en una rama lateral que se divide del maestro, que desarrollamos durante unos meses, y cuando alcanzamos un hito sincronizamos los dos.
Por lo general, no desea dejar sus ramas sin sincronización durante meses.
Su rama de características se ha ramificado de algo dependiendo de su flujo de trabajo; vamos a llamarlo masterpor simplicidad. Ahora, cada vez que te comprometes a dominar, puedes y debes git checkout long_running_feature ; git rebase master. Esto significa que sus ramas están, por diseño, siempre sincronizadas.
git rebaseTambién es lo correcto hacer aquí. No es un truco o algo extraño o peligroso, sino completamente natural. Pierde un poco de información, que es el "cumpleaños" de la rama de características, pero eso es todo. Si alguien considera que eso es importante, podría proporcionarlo guardándolo en otro lugar (en su sistema de tickets o, si la necesidad es grande, en un git tag...).
Ahora, en mi humilde opinión, la forma natural de manejar esto es aplastar la rama lateral en una sola confirmación.
No, absolutamente no quieres eso, quieres un commit de fusión. Una confirmación de fusión también es una "confirmación única". De alguna manera, no inserta todos los commits de rama individuales "en" maestro. Es un compromiso único con dos padres: el masterjefe y el jefe de la sucursal en el momento de la fusión.
Asegúrese de especificar la --no-ffopción, por supuesto; fusionarse sin --no-ff, en su caso, debería estar estrictamente prohibido. Lamentablemente, --no-ffno es el predeterminado; pero creo que hay una opción que puede configurar que lo haga así. Vea git help mergelo que --no-ffhace (en resumen: activa el comportamiento que describí en el párrafo anterior), es crucial.
No estamos volcando retroactivamente meses de desarrollo paralelo en la historia del maestro.
Absolutamente no: nunca está volcando algo "en la historia" de alguna sucursal, especialmente no con un compromiso de fusión.
Y si alguien necesita una mejor resolución para la historia de la rama lateral, bueno, por supuesto, todo sigue ahí, simplemente no está en el maestro, está en la rama lateral.
Con un commit de fusión, todavía está allí. No en el maestro, sino en la rama lateral, claramente visible como uno de los padres del compromiso de fusión, y guardado por la eternidad, como debería ser.
¿Ves lo que he hecho? Todas las cosas que describe para su confirmación de squash están ahí con la --no-ffconfirmación de fusión .
Aquí está el problema: trabajo exclusivamente con la línea de comando, pero el resto de mi equipo usa GUIS.
(Comentario lateral: también trabajo casi exclusivamente con la línea de comandos (bueno, eso es mentira, generalmente uso emacs magit, pero esa es otra historia: si no estoy en un lugar conveniente con mi configuración individual de emacs, prefiero el comando línea también). Pero, por favor, hágase un favor y probar al menos git guiuna vez. es por lo tanto más eficiente para recoger trozos de líneas, etc., para añadir / deshacer añade.)
Y he descubierto que el GUIS no tiene una opción razonable para mostrar el historial de otras ramas.
Eso es porque lo que estás tratando de hacer está totalmente en contra del espíritu de git. gitse construye desde el núcleo en un "gráfico acíclico dirigido", lo que significa que hay mucha información en la relación padre-hijo de los commits. Y, para las fusiones, eso significa verdaderos compromisos de fusión con dos padres y un hijo. Las GUI de sus colegas estarán bien tan pronto como use las no-ffconfirmaciones de fusión.
Entonces, si llega a una confirmación de squash, diciendo "este desarrollo aplastado de la rama XYZ", es un gran dolor ir a ver qué hay en XYZ.
Sí, pero eso no es un problema de la GUI, sino de la confirmación de squash. El uso de una calabaza significa que deja la cabeza de la rama característica colgando y creando una nueva confirmación master. Esto rompe la estructura en dos niveles, creando un gran desastre.
Por lo tanto, quieren que se fusionen estas grandes y largas ramas de desarrollo lateral, siempre con un compromiso de fusión.
Y tienen toda la razón. Pero no se "fusionaron en ", que se acaba de fusionarse. Una fusión es algo realmente equilibrado, no tiene un lado preferido que se fusione "en" el otro ( git checkout A ; git merge Bes exactamente el mismo que, git checkout B ; git merge Aexcepto por pequeñas diferencias visuales, como las ramas que se intercambian, git logetc.).
No quieren ningún historial al que no se pueda acceder inmediatamente desde la rama maestra.
Lo cual es completamente correcto. En un momento en que no hay características no fusionadas, tendrías una sola rama mastercon un rico historial que encapsula todas las líneas de confirmación de características que alguna vez hubo, volviendo a la git initconfirmación desde el principio de los tiempos (ten en cuenta que evité específicamente usar el término " ramas "en la última parte de ese párrafo porque el historial en ese momento ya no es" ramas ", aunque el gráfico de compromiso sería bastante ramificado).
Odio esa idea;
Entonces te dolerá un poco, ya que estás trabajando en contra de la herramienta que estás utilizando. El gitenfoque es muy elegante y poderoso, especialmente en el área de ramificación / fusión; si lo hace bien (como se aludió anteriormente, especialmente con --no-ff) es a pasos agigantados superiour a otros enfoques (por ejemplo, el desorden de subversión de tener estructuras de directorio paralelas para ramas).
significa una maraña interminable e inevitable de la historia paralela del desarrollo.
Sin fin, paralelo, sí.
Innavigable, maraña - no.
Pero no veo qué alternativa tenemos.
¿Por qué no trabajar gittodos los días como lo hacen el inventor de sus colegas y el resto del mundo?
¿Tenemos alguna opción aquí además de fusionar constantemente ramas laterales en master con merge-commits? O, ¿hay alguna razón por la que constantemente usar merge-commits no sea tan malo como me temo?
No hay otras opciones; No es tan malo.
