¿Cuáles son las ventajas de usar la ramificación como desarrollador en solitario?

En primer lugar, soy consciente de que se han hecho muchas preguntas sobre VCS como desarrollador en solitario, pero a menudo son demasiado amplias. Esto se refiere solo a la ramificación, y aún así se ha marcado como un duplicado ... el supuesto duplicado está, nuevamente, marcado como otro duplicado de otra pregunta que es demasiado amplia y no se refiere específicamente a la ramificación. Así es como mi pregunta es única.

¿Cuáles son las ventajas, si las hay, de utilizar la ramificación como desarrollador en solitario? A menudo lo he visto recomendado incluso en un contexto de desarrollo solo, pero por lo que puedo ver, más allá de usar un tronco 'maestro' para el desarrollo y ramificar para trabajar, código listo para el lanzamiento, no veo cómo Podría aprovechar el poder de la ramificación (por ejemplo, para compartimentar nuevas características) sin complicar demasiado el proceso de desarrollo completo.

Las ventajas son principalmente las mismas que para grupos de desarrolladores. Al usar una rama maestra siempre lista para el lanzamiento y ramas de características para desarrollar nuevas características, siempre puede liberar la maestra. ¿Encuentra un error importante mientras trabaja en una función? Cambie de rama, arregle, libere, cambie de nuevo y continúe desarrollando

O tal vez este es un proyecto de pasatiempo y simplemente le gusta poder trabajar un poco en esta función y un poco de eso, según lo desee. Básicamente, estás emulando a un equipo de varias personas dividiendo el tiempo.

La ramificación implícita que los DVCS hacen en los clones significa que las ramas formales en el repositorio autorizado tienen menos que ver con la coordinación de las personas y más con la coordinación de las direcciones de desarrollo, e incluso una sola persona puede hacer varias de ellas.

Desarrollo a largo plazo

La ramificación para un equipo de una sola persona sería útil para una función de desarrollo de larga duración que, de lo contrario, no se ajusta a su ciclo de lanzamiento.

Puede tomar una rama para su cambio de expansión de varios meses y aún así poder impulsar las correcciones de errores o cambios diarios de su rama principal a intervalos regulares.

Esto tiene la ventaja sobre los 'conmutadores' en una sola rama, ya que su rama principal siempre está en un estado desplegable y tiene la garantía de que nada en la función de ejecución prolongada ha tenido un impacto en otro código previamente probado.

Características experimentales

Una bifurcación también puede ser útil para las características que puede desear prototipar, pero que tal vez nunca lleguen a su código implementado. Completar esto en una rama que finalmente puedo tirar significa que nunca contaminará su base de código principal innecesariamente.

Lo uso para el mantenimiento crítico del sitio web. Soy el único desarrollador pero tengo un master, desarrollar y emitir sucursales.

Mi proceso de trabajo para la configuración del sitio se ve así:

1. Hacer la rama maestra viable. Hacer commit inicial.

2. Pagar desarrollar sucursal. No haga nada, desarrolle funciones como un búfer de prueba para fusionarse con el maestro.

3. Sucursal del problema de pago. Codifique su problema, cuando esté listo, póngalo en desarrollo, vea si surge algún problema, combine conflictos, etc.

Cuando se fusionan suficientes problemas en el desarrollo para una versión y se ha probado la estabilidad del desarrollo, coloque el desarrollo en maestro.

   Master
     |
   Develop  - E
   / |  \  \
 A   B   C  D

De esta forma, obtienes una colección completa de pruebas en desarrollo, donde puedes probar la estabilidad, los problemas, etc. sin tener que arriesgarte a dañar a Master y tener que revertir los commits si son perjudiciales.

Además, al usar ramas individuales para comprometerse, puede "dejar" el trabajo que ya hizo, comenzar de nuevo en otra cosa para solucionar un problema más urgente y desplegarlo antes.

En la vida real, por lo general, tengo una rama de problema, y ​​la desarrollo y luego la convierto en maestra. A veces es tedioso, pero una vez cada dos meses al menos tengo que dejar el trabajo de inmediato porque alguien tenía la idea de que tenía que hacer RightNow ™ y de esa manera puedo volver rápidamente a un estado base, hacer que la cosa y luego continuar donde estaba. Especialmente con proyectos grandes que toman varias semanas, es una bendición que pueda cambiar rápidamente de sucursal.

Considere este escenario: Siempre se trabaja en una rama principal y que tiene AwesomeCodeThing ™ en las obras que sale de su rama principal en la cirugía a corazón abierto y una YugeBug ™ aparece que necesita fijación urgente de lo contrario miles de usuarios se quejan a usted acerca de BigProblems ™
El única forma de resolver rápidamente su problema en tal escenario,

1. verifica tus confirmaciones anteriores,
2. ver cuándo fue su última confirmación estable (la maldición es opcional)
3. volver a ese compromiso
4. hacer arreglos, enviar arreglos a producción
5. resuelva todos los conflictos y problemas que tiene ahora tratando de volver al estado AwesomeCodeThing ™
6. renunciar, llorar y comenzar a trabajar nuevamente (opcional)

Si usa ramas:

1. Maestro de caja
2. crear rama UrgentFix ™ y arreglar cosas
3. empuje UrgentFix ™ al maestro
4. empujar a la producción
5. Fusionar maestro en desarrollo
6. La fusión se convierte en AwesomeCodeThing ™
7. tomar una cerveza y seguir trabajando.

Las ramas facilitan el trabajo en múltiples funciones a la vez, lo que puede ser bastante útil cuando las prioridades cambian durante el curso de un proyecto.

Digamos que decides que una característica es más importante ahora. Quizás necesite urgentemente parchear un error crítico en un sistema en vivo. Podría estar trabajando con un cliente en múltiples funciones durante un largo período de tiempo y es posible que desee demostrar el progreso de cada función por separado. Tal vez acabas de leer sobre un desagradable exploit de día cero y quieres entrar antes de que dicho cliente lea sobre él.

Si usa ramas para cada función / revisión, generalmente será más fácil, limpio y rápido aislar e implementar estas modificaciones en lugar de usar una sola rama para todo. Esto es cierto tanto si es un desarrollador exclusivo o parte de un equipo.

En cuanto a un proceso real, encuentro que git flow funciona bien. La hoja de trucos git flow de Daniel Kummer es un gran recurso, vale la pena verlo incluso si no está usando git.

Como se mencionó en otros carteles, las ventajas son sustancialmente similares a trabajar en equipo: la capacidad de desarrollar y probar características de forma independiente, mantener una rama maestra separada para las revisiones / implementaciones de producción, experimentar.

Para mí personalmente, generalmente tiendo a trabajar en master si conozco muy bien el área en la que estoy trabajando, solo agrega gastos generales a la sucursal porque los fusionaré de todos modos.

Sin embargo, si tengo alguna duda sobre los cambios que estoy realizando, me ramificaré y solo PR / fusionaré una vez que la ramificación se comporte como se esperaba y generalmente se pruebe por completo. De esa manera, si descubro un problema para el cual retroceder es el mejor curso de acción, es una confirmación única en lugar de una serie completa (nunca puedo recordar la sintaxis para deshacer una serie de confirmaciones, pero una sola es fácil).