tag - ¿Usar git/mercurial en proyectos con refactorización continua?

git tags best practices (6)

Te di un voto por el buen humor en el crack de dinn / dinosaurios.

Es posible usar Git de una manera muy similar al usar subversión para que no se pierda nada y cuando, con el tiempo, usted y su equipo encuentren algunos usos para bifurcar, ramificar o cualquier otra característica ingeniosa de Git, podrían ser implementado de una manera medida y responsable.

Estoy tratando de entender si realmente tengo alguna razón para usar git / mercurial.

Los proyectos que trabajo son proyectos de Java y C #, por lo general con 5-20 personas trabajando hacia un objetivo común (el "lanzamiento"). La mayoría de los desarrolladores son desarrolladores profesionales que refaccionan el código todo el tiempo . Entonces, cuando el núcleo típico de Linux tiene una gran cantidad de cambios relativamente independientes en archivos separados, tenemos un flujo constante de cambios de refactorización, que a menudo afectan a muchos archivos y muchos códigos. A nadie le da miedo cambiar el código aquí.

Ahora con la subversión resolvemos esto permaneciendo extremadamente cerca de SVN HEAD. Algunos de nosotros incluso hemos automatizado svn up que se activan en la transmisión jabber del servidor de compilación. La mayoría de nosotros también aprendimos (o aprendemos muy rápido) cómo planificar nuestro trabajo para permanecer cerca de SVN HEAD. Si está haciendo una refactorización importante, doblamos gradualmente el árbol fuente en una nueva dirección en lugar de alejarnos demasiado. A veces solo planifica la operación de refactorización y comienza en las áreas menos disputadas. Después de algunos años de trabajar de esta manera, se convierte en una segunda naturaleza. La mayoría de nosotros simplemente nunca abandonamos la "zona de confort" de estar a menos de 2 horas de la cabeza de svn. La construcción automatizada y svn head es el proyecto "pulse" y nos gusta.

Por supuesto, se ramifican cada versión, pero la cantidad de backmerges de la rama de publicación de nuevo al tronco se reduce lo suficiente como para ser insignificante (tenemos una cobertura de prueba decente). Quedarse ausente durante días / semanas con sucursales privadas de la fuente suena como algo que queremos desestimular activamente, y simplemente no ocurre con mucha frecuencia.

Tanto el git como el mercurial suenan bien, git un poco más, ya que soy más un tipo McGyver que un tipo James Bond. Pero cuando se trata de construir un caso para realmente cambiar, parece que Linus y yo vivimos en dos planetas diferentes. La mayoría de las veces queremos que nuestros equipos se concentren en HEAD.

¿Cómo puede GIT mejorar el control de mi versión? ¿Cómo me permitiría GIT mejorar mi proceso? ¿Soy un dinosaurio de subversión?

La forma en que su equipo usa Subversion significa que hay un gran esfuerzo de fusión. Casi todas las veces que un miembro del equipo se actualiza a la línea principal más reciente, están fusionando su copia de trabajo con la última línea principal, incluso si no se comprometen sus propios cambios en esta etapa. La sobrecarga combinada tiende a ser un producto de tasa de compromiso y número de miembros del equipo, y dado que la tasa de compromiso es una función del número de miembros del equipo, la sobrecarga de administración del código fuente es O (N ^ 2).

En el modelo de Mercurial / Git, este esfuerzo de fusión se compartirá entre el equipo. Si rutinariamente extrae conjuntos de cambios de todos, a menudo encontrará que otros ya han hecho casi todo el trabajo de fusión que podría haber tenido que hacer. Y, en los casos en que una fusión ha roto algo, a menudo las personas ya lo han solucionado. La conciliación de un par de ramas solo tiene que hacerse una vez, y dado que la tasa de generación de nuevas ramas es proporcional al número de miembros del equipo, la sobrecarga de administración del código fuente es O (N).

Esperaría que 20 desarrolladores que trabajan cerca de la cabeza en una sucursal probablemente involucren una buena cantidad de trabajo de fusión (lidiar con conflictos y lidiar con regresiones debido al desarrollo independiente), así que me sorprendería si probaran Mercurial / Git y no encontró una ganancia de productividad útil. ¿Crees que podrías gestionar 100 desarrolladores con tu progreso actual? Estimaría la cantidad de desarrolladores de kernel de Linux en 4000, y sin embargo, hacen un montón de cosas y la carga general de administración del código fuente debe ser aceptable.

Siempre que su sistema de gestión de código fuente rastree el parentesco común, las fusiones suelen ser automáticas. Cada fusión tiene la posibilidad de ser un conflicto de texto o romper la construcción y las pruebas debido a la interacción entre los cambios; cuantas menos fusiones tengas que hacer, menos tiempo tendrás para enfrentarte con cualquier tipo de problema.

En consecuencia, una gran victoria es que los usuarios de Mercurial / Git ya no temen a las sucursales. Antes de BitKeeper (la herramienta que realmente introdujo esta forma de trabajar, hasta donde yo sé), las ramas de larga duración eran bombas de tiempo funcionando, de vez en cuando explotando y tardando una semana en recuperarse. Ahora, podemos ramificar sin vacilación, con la confianza de que podremos fusionarnos más tarde. En un equipo saludable, otros pueden ver sus ramas en progreso y fusionarlas con las suyas y luego comprometer sus esfuerzos si creen que vale la pena. En un modelo centralizado, si cada desarrollador tiene 3 o 4 ramas activas, y estoy corrigiendo al decir que es O (N ^ 2), entonces usted acaba de aumentar su sobrecarga de administración del código fuente por un factor de 3ish ^ 2, es decir un orden de magnitud, que probablemente sea suficiente para dañar realmente la salud, la riqueza y la felicidad en general. Esta es la razón subyacente por la cual los miembros del equipo (y los gerentes) suelen temer a las sucursales en sistemas centralizados y trabajan para minimizarlos.

En términos de mentalidad, a veces hay un beneficio en poder crear una rama suave, realizar todos los cambios en la rama suave, probar el resultado de los cambios en la rama suave, y luego cuando la rama suave está "completa" ", reintegrarlo con la rama principal localmente, volver a probarlo y luego propagarlo.

Esto en algunos casos es mejor que la cabeza apresurada, porque no tiene la interrupción constante de la existencia de otros códigos de depuración que ensucian su código para agregar errores no manejables.

También significa que puede comprometerse más a menudo, brindando un historial más completo, ya que los commits no aparecen de manera instantánea en todas partes creando problemas.

Además, al reconciliar la rama suave con la línea principal compartida, puede ver un conjunto de cambios completo y agradable, que le muestra todos sus cambios colectivos y todos sus cambios colectivos, lo que abre la puerta a buenas oportunidades de revisión de códigos.

Además, desde una perspectiva de prueba, si tiene más ramas blandas, puede ejecutar las pruebas en las ramas blandas antes de fusionarlas nuevamente en la rama principal, y tener un estándar por el cual, una rama no se fusiona de nuevo en la rama principal rama hasta que tenga

Pasó las pruebas por sí mismo
Pasó las pruebas después de que los cambios en las ramas principales se hayan reconciliado en la rama suave

Por lo tanto, le ofrece una garantía adicional de calidad del código, ya que su rama de colaboración principal es extremadamente limpia, ya que no se permite que aparezca el código anómalo.

(Lo cual también limita el dominio de resolución de problemas, ya que solo tienes que probar tus propios cambios en su mayor parte, y cuando estás "hecho", solo entonces tienes que preocuparte por lo que todos los demás han hecho, y lo que han hecho también debe pasar las pruebas, lo que significa que cuando algo falla, solo tienes que mirar lo que hiciste para resolver el problema)

Pero ¿actualizaría de forma continua desde la cabeza del repositorio central a mi rama suave? Esta es realmente la esencia de mi problema

La belleza del sistema de sucursales es que puede obtener "lo que otros hayan considerado estable" en su copia local, según sea necesario.

La "Actualización continua" se vuelve innecesaria porque no tiene los mismos problemas que se manifiestan.

a b center | | / Key: / - | / = Flow /----<---| < > = Flow Directions | /--<--/ * = Commit * | | T = Test | * | M = Merging with "Current" state of common branch * | | C = Tests Complete and Current state is "sane" | * | T | | | T | | C | | |/-<--/ * M | | T | * C | | /--->-/ * /---<-/ T | | C * | |/-----<-/ M | | T * | | T | * C | | |/-<--/ * M | T T | C /-->--/ |/---<---/ M | T | C | /---->---/ |

Además, debido a cómo funciona el sistema, más adelante, esto también podría ocurrir:

a b center | | | T | | C * | |/</ | M | | | * | T | C | |/----<--/ M | T | C | /-->-----/ |

Todo el concepto de ser una "cabeza" en tal escenario desaparece. Hay docenas de cabezas, la que ves es propensa a la perspectiva.

También podría agregar, que estas ramas lógicas, aunque se muestran como separadas aquí, pueden representar de manera bastante factible ya sea ubicaciones de pago separadas, o meras ramas suaves diferentes en una máquina singular. a & b podría ser un único desarrollador.

En esencia, "actualizar continuamente mi rama principal de mainbranch", es conceptualmente insignificante. Porque, de hecho, habrá cambios que aún no están representados en la rama principal, y ¿cuándo sabrá que han sido empujados o no? SVN te da esta falsa ilusión de un estado de código "singular", cuando en realidad, el instante en que un usuario abre un archivo en su editor de texto, de hecho han creado una vida muy corta, un cambio, que está ocurriendo, que nadie conoce, y para que esta ilusión se sostenga de la manera en que crees que funciona, en efecto, el usuario debe comprometerse después de cada personaje, lo que no es práctico. Entonces, en realidad, la gente se acostumbra al hecho de que diferentes ubicaciones se "desconectan" entre sí, y aprenden formas de resolverlo para que ya no sea un problema.

Además, la "actualización constante de mi árbol con todos los demás cambios" tiene un problema central, en eso, tienes demasiadas distracciones, te bombardean constantemente con todo lo que hacen los demás, y si están haciendo una serie de 1 Line se compromete a probar algo que no pueden probar en su propia máquina, luego tiene una pesadilla con el archivo en constante cambio, y los usuarios que ven los cambios aparentemente aleatorios no pueden entenderlos.

Al permitir tiradas más largas entre confirmaciones, y luego ver el resultado neto en lotes y ver solo el resultado neto de los cambios de sus pares al mismo tiempo, puede ver inmediatamente qué código se ha cambiado desde que lo pagó y una visión general cohesiva de lo que significa para su código, para que pueda escribir su propio código y terminarlo de nuevo.

Si tienes alguna duda

Comience con algo simple y no haga una transición fría, algunos de los conceptos en DSCM pueden ser un poco desalentadores (he visto la falla trágica de muchos para entender el concepto de ramas suaves apiladas verticalmente), mover un pequeño no- parte esencial de la base de código para Git / Mercurial y juegue con ella por un tiempo, experimente con los beneficios y lo que puede hacer. No hay mejor prueba que experimentarlo usted mismo, y todas mis encantadoras explicaciones probablemente no comuniquen lo que necesita comprender y solo se pueden aprender intentándolo y fallar algunas veces (porque el fracaso es una parte clave del aprendizaje).

Por un lado, si nada más, puede usar GIT fuera de línea, para que las personas puedan seguir trabajando bajo control de código fuente, incluso mientras viajan o en su hogar. Si se puede aplicar cualquiera de los casos, definitivamente podría beneficiarse de GIT.

lo que describiste en SVN, se puede hacer usando git / mercurial

Creo que mercurial es genial. Especialmente con TortoiseHg .

Una de las cosas que me resulta más útil es la posibilidad de compartir un desarrollo de funciones con solo un equipo central.

Supongamos que todo el equipo es de 20 personas, pero solo desea probar y desarrollar una función con un equipo de 3-4 personas antes de comprometerse con el repositorio principal. Luego, con Mercurial, puedes sincronizar el código entre el codificador 3-4 hasta que estés satisfecho antes de comprometerte con el repositorio principal.

O incluso puedes ser tu propio equipo, ej. cuando desee probar su código en múltiples plataformas antes de comprometerse con el repositorio principal.