Git Workflows: Rebasing Sucursales publicadas/compartidas

Question

Nuestro equipo de trabajo ha adoptado con entusiasmo un flujo de trabajo de rebase, pero podríamos habernos dejado llevar un poco, que es el punto de esta pregunta: usted es el juez.

Usar pull --rebase es obvio para mí ahora. Sin embargo, también tenemos grandes ramas de características en las que trabajan varias personas. Periódicamente, queremos traer cambios que están sucediendo en el maestro. La sabiduría convencional nos haría fusionarnos, ya que es una rama compartida. Sin embargo, en nuestra obsesión de rebase, hemos decidido volver a establecer esas sucursales. Por supuesto, eso requiere la cooperación de todos. El flujo de trabajo es más o menos así:

1) El rebaser se coordina con todos para asegurarse de que todos estén registrados y enviados a la rama de características, luego les pide que no hagan más trabajo en esa rama hasta que obtengan el Todo claro.

2) El rebaser rebasa la rama de la característica en maestro, elimina la rama a distancia característica (git push origen: función) y, a continuación, empuja la nueva, rama de la característica porcentualizada (entidad de origen git push)

3) La rebaser hace que todos busquen, lo que actualiza su rama de características, luego elimina su rama de características local (git branch -D feature), luego crea una nueva rama local de características que rastrea la rama de características remotas. Todos obtienen el visto bueno.

Este flujo de trabajo funciona, en parte porque somos un grupo pequeño y las interrupciones de trabajo son pequeñas. Sin embargo, me preocupa que estamos aprendiendo malos hábitos de Git (volviendo a basar una rama compartida), o que el flujo de trabajo no se escalará bien.

Por el lado positivo, nuestro historial de repositorios es encantador.

¿Qué le parece, gurús Git? ¿Estamos jugando con fuego o balanceando un flujo de trabajo razonable?

ACTUALIZACIÓN:

Es dos años desde que originalmente hizo la pregunta, y mi ha cambiado nuestro flujo de trabajo desde entonces. Todavía hacemos rutinariamente git pull --rebase, así que eso no ha cambiado. Es de sentido común, y evita todas las mini-fusiones desagradables y confusas. (Nos mantenemos en su mayoría sincronizados, por lo que hay un pequeño costo para git pull --rebase).

Aparte de eso, sin embargo, y la acción heroica ocasional para corregir un error, hemos superado nuestra locura de rebase. La fusión tiene sentido la mayor parte del tiempo. Sin embargo, la fusión desenfrenada es problemática y contribuye a la historia confusa y caótica que me preocupaba hace dos años.

Nuestra solución tiene varios componentes:

rama

• El maestro es "virgen". Las ramas de tema se fusionan en, y una vez que lo hacen, la rama de tema se retiró. En otras palabras, fusionar una rama de tema significa que ese trabajo está listo para producción, y ahora es parte de la rama principal. Mirando nuestro historial de versiones, está muy claro lo que está sucediendo: las ramas de los temas se fusionaron en maestra, y eso es todo.

• Utilizamos ramas de integración desechables cuando es necesario. Por ejemplo, si tenemos ramas de tema A, B y C, y ninguna de ellas está lista para la integración en el maestro, pero tenemos que probarlas juntas, simplemente creamos una rama de control de calidad (generalmente fuera del maestro) y luego fusionamos A, B y C in. En algún punto, la rama QA se borra o reutiliza.El punto es que no tiene la intención de ser permanente de ninguna manera, y no tiene las mismas restricciones que la rama principal (puede combinar sus ramas de tema tantas veces como desee). Si el historial se vuelve demasiado confuso, puede simplemente eliminar la rama QA y comenzar de nuevo (un enfoque que hemos encontrado que es muy natural).

• Al combinar, siempre use git merge --no-ff. Esta es una reversión tremenda de nuestra obsesión por la "historia de compromiso lineal" de hace dos años que merece un comentario. Ahora que nos hemos relajado sobre un historial de compromiso lineal, y hemos visto que las fusiones son buenas y útiles, hemos comenzado a confiar en ramas de tema que son ramas reales fuera de dominio, no solo una serie de confirmaciones que finalmente se convierte uno con maestro git merge --no-ff garantiza que siempre haya una confirmación de fusión, incluso cuando no sea necesario.

• Tenemos una convención bien entendida por los mensajes de confirmación y ramas y, más importante, it-referencias cruzadas nuestro sistema de seguimiento de problemas. Nuestro sistema de seguimiento de problemas utiliza números de números numéricos, y para cualquier característica (o defecto), tenemos un número de problema (1234, por ejemplo). Si está trabajando en ese tema, debería crear una rama _1234 y comenzar cada mensaje de confirmación con "_1234: doing blah blah". Puede parecer un poco obsesivo, pero realmente nos ha funcionado bien y ha reducido/eliminado la confusión.

• Utilice una envoltura git para fomentar la adhesión del flujo de trabajo. Esto es algo en lo que estamos trabajando actualmente, pero nos hemos dado cuenta de que es completamente necesario para evitar errores simples y comprensibles, como desviarnos de lo incorrecto (recientemente tuvimos un desastre completo cuando un desarrollador creó una rama temática de un desechable Secuencia de control de calidad: esa rama de tema se aprobó para activarse, se fusionó en ... y un grupo de modificadores que no fueron aprobados para su activación fueron absorbidos). Nuestro contenedor de git requerirá confirmación cada vez que haga algo inusual (como crear una rama de cualquier cosa que no sea maestra, crear una rama no nombrada _NNNN, hacer una confirmación que no comience con _NNNN, etc.). De vez en cuando, tenemos que hacer estas cosas, por lo que el contenedor no previene, pero evita que las personas hagan algo que no deberían hacer accidentalmente.

Answer 1

Parece que es demasiado complicado y no se escalará bien. Probablemente sea muchísimo más simple simplemente fusionar master en su rama de características periódicamente, y cuando llegue el momento de fusionar de nuevo en el maestro, luego puede hacer la rebase primero (para eliminar la fusión intermedia innecesaria) y fusionar de nuevo en el maestro (presumiblemente con --no-ff para producir una confirmación de fusión). Esto solo requiere que una persona se ocupe de la rebase, y no tienen que hacer ninguna coordinación porque nadie más necesita forzar la actualización de nada (porque, presumiblemente, la rama se eliminará después de fusionarse, en lugar de mantenerse en un estado reescrito). También puede optar por omitir la rebase por completo y simplemente dejar las fusiones intermedias en su lugar, lo que reflejaría de forma más precisa su flujo de trabajo de desarrollo y eliminaría el riesgo de producir confirmaciones que en realidad no se generan.