En su mayor parte, este es el flujo de trabajo habitual empleado con cualquier VCS que hayamos utilizado hasta ahora. Con algunos (CVS, SVN) es más difícil de hacer, con GIT es trivial. Dicho esto, tengo dos comentarios:
Primero, hay dos escuelas de pensamiento cuando se trata de ramas de características:
- Fusionarlos
- Rebase de ellos
(1) es lo que parece sugerir el artículo. El problema con los commits de fusión son los llamados Evil Merges . Específicamente, aquellos que se unen a rutas de desarrollo donde una función ha cambiado la semántica en una de las ramas, pero la fusión automática no repara todas las ocurrencias en el código proveniente de la otra rama. Las regresiones introducidas de esa manera son notoriamente difíciles de depurar. Como usuario de GIT, generalmente puede estar mucho más relajado acerca de las regresiones, porque tiene git bisectque encontrar sus causas automáticamente. Sin embargo, en la situación descrita, git bisectseñalará la confirmación de fusión, que no lo ayuda en absoluto.
(2) evita este problema tratando de mantener un historial lo más lineal posible. Los rebases opuestos afirman que invalida cualquier prueba que haya realizado antes del rebase.
Personalmente, estoy firmemente en el campamento (2), porque valoro la validez de los git bisectresultados más que la pérdida potencial de la cobertura de la prueba, que se compensa fácilmente mediante el uso de un sistema de CI adecuado.
En segundo lugar, he decidido que presionar entre desarrolladores rara vez es una buena idea. Hay problemas de seguridad involucrados al permitir que todos ingresen a su caja para buscar o ejecutar git-deamon localmente y, lo que es más importante, en equipos no extremadamente pequeños, la supervisión puede perderse con bastante rapidez.
Dicho esto, estoy a favor de un repositorio provisional (a veces también llamado scratch ), que permite a los equipos secundarios compartir su trabajo en progreso a través de un servidor central que, sin embargo, es diferente del principal (a menudo externo). frente, si no público). Típicamente, cada sub-equipo mantendría una rama temática para sí mismo, y un sistema de CI realizaría fusiones periódicas de pulpos de todas las ramas temáticas en una gran rama de integración, quejándose de conflictos y errores de compilación.
git bisectfue dado como una razón para mantener la estrategia plana entonces también.git bisectsolo. Ocurre cuando la característica A cambia una función que la característica B también usa. Todas las pruebas pasarán tanto en A como en B antes de la fusión, pero después de que las pruebas de fusión puedan romperse debido a cambios incompatibles entre A y B, perogit bisectno pueden aplicar parcialmente una rama a otra, por lo que su única pista es que la fusión se confirma es cuando se introdujo el error.Actualmente estoy en el proceso de realizar refactorizaciones masivas y a largo plazo (convertir una aplicación de un kit de herramientas GUI a otro) y realizar un flujo de trabajo exitoso centrado en rebase, porque otros miembros del equipo continúan trabajando en nuevas características:
En su mayoría hay dos ramas principales,
masterdonde se desarrollan las nuevas características y latoolkit-conversionrama. La regla más importante es simple: hacer solo cosas en latoolkit-conversionrama que sean relevantes para la conversión. Siempre que hay algo que se puede hacer en elmaster(antiguo kit de herramientas de la GUI), lo hago allí y vuelvo a basar mistoolkit-conversioncambios en el nuevomasterencabezado. Otra regla es mantener latoolkit-conversionrama bastante corta. Por lo tanto, a menudo utilizo reset, cherry-pick y correct-commit y rebase para unir los commits más pequeños a los más grandes (que al final tienen el mismo propósito). Esto también funciona bien cuando he intentado algo que no funcionó bien para "deshacer" el cambio o después de haber refactorizado algún código con código auxiliar temporal.He decidido contra la fusión de los cambios de
masterentoolkit-conversionrama, ya que haría mucho más difícil de rebase confirmaciones anteriores para mantener la rama limpio y fácil de opinión. Además, las fusiones pueden introducir conflictos cuyas resoluciones no son tan claras como cuando se mantiene un historial limpio.Por supuesto, este flujo de trabajo también tiene desventajas. La más importante es que solo funciona bien para una sola persona. Cada vez que empujo la
toolkit-conversionrama a la fuerza después de haberla reubicado en la cabeza demaster, volver a colocarla en otro repositorio se vuelve difícil (la rebase automática en la rama de seguimiento a menudo falla con conflictos).Al final, mi
toolkit-conversionsucursal sigue siendo corta, limpia y fácil de revisar. No podría imaginar haber estado haciendo esto de forma similar con, por ejemplo, SVN.fuente
En la compañía en la que estoy trabajando actualmente, hemos estado aplicando una variación de este mismo modelo de ramificación por un tiempo. También hemos estado usando scrum, por lo que hacemos un flujo de trabajo de rama por historia.
El único problema que hemos tenido hasta ahora es cuando el equipo es lo suficientemente grande y se puede iniciar más de una historia y esas historias dependen unas de otras, se convierte en un desastre mezclar los cambios entre las ramas y volver a dominar.
Además de eso, esto ha demostrado ser confiable :).
fuente
Actualmente estoy ocupado adaptando este flujo de trabajo. Creo que este es un flujo de trabajo bastante bueno, porque utiliza el modelo de ramificación en el que sobresale git.
El único pequeño inconveniente es que se necesita cierta disciplina para mantener este flujo de trabajo y no tratar de tomar atajos.
Los desarrolladores de kohana también usan este flujo de trabajo, y parece que les gusta bastante.
fuente
Utilizamos un flujo de trabajo similar en el trabajo, pero un poco menos complicado. Sin embargo, está muy inspirado en este flujo de trabajo, ya que he leído este artículo muchas veces. Incluso tengo el pdf del modelo de ramificación impreso en colores al lado de mi escritorio :)
Productivo. ¿Cómo define usted la productividad? Bueno, en mi opinión, lo más importante es tener alta calidad, al menos para tratar de lograr una mejor calidad todo el tiempo. Mejorar constantemente el proceso, etc. Si puede producir código de calidad, la productividad se beneficiará de él. Entonces la pregunta es realmente: ¿Mejora esto la calidad del software? Y mi respuesta a eso es definitivamente sí.
Lo que más me gusta de este tipo de modelo de ramificación es que introduce sucursales en diferentes capas de calidad. Cuanto más a la derecha en la imagen, mayor estabilidad y mayor calidad. La rama maestra es sagrada y todos los compromisos deben considerarse como versiones estables del software. Cuanto más a la izquierda vaya, más experimental y más baja será la estabilidad.
Tan pronto como pruebe las nuevas características y las correcciones de errores, puede transferirlas gradualmente de izquierda a derecha y, por lo tanto, mover el código con alta calidad exactamente cuando sepa que el código cumple con los requisitos de calidad que exige del código. Bueno, al menos en teoría, ya que no puede probar todo al 100% y saber con certeza que el código no contiene ningún error, porque siempre tendrá errores. Pero le permite mantener una gran confianza.
Como programador, nada apesta más que trabajar en un sistema en el que nadie confía en el código, porque saben que simplemente apesta y que hay un montón de errores en él.
Es importante pensar en su modelo de ramificación para que se ajuste bien a las necesidades de su organización. El hecho de que este modelo funcione bien para algunas personas no significa necesariamente que sea óptimo o deseable para otra.
Siempre hay compensaciones e incluso en este caso. Una compensación es el número de sucursales versus la complejidad. Al introducir muchos tipos diferentes de ramas, aumenta la complejidad del flujo de trabajo. Por ejemplo, podría ser simplemente incorrecto obligar siempre a las personas a crear una nueva rama de características, cuando intentan corregir un error simple cambiando un par de líneas de código.
Todos sabemos que los errores son más o menos complicados de resolver. Entonces, cuando se descubre un error trivial, es posible que desee reducir la complejidad y la administración para deshacerse de la sobrecarga adicional y simplemente dejar que las personas se comprometan directamente, por ejemplo, con la rama maestra o de desarrollo. Pero a medida que la naturaleza de sus arreglos se vuelve más complicada, vale la pena esa sobrecarga adicional para crear nuevas ramas para ellos. Especialmente si no está seguro del tamaño y la longitud del mismo o si desea mejorar la colaboración entre usted y los otros desarrolladores.
Este es sin duda un buen enfoque y podría encajar en la mayoría de los casos, ya que la mayoría de nosotros tenemos procesos de desarrollo similares, pero podría no ser adecuado para todos. Le recomiendo encarecidamente que piense cómo maneja su código en este momento e intente crear un modelo de ramificación que se ajuste al que ya tiene.
El punto más importante es comenzar con git y el resto seguirá naturalmente. ¡Comience simple y mejore gradualmente! ¡Ser creativo!
Salud
fuente