¿Cuáles son las ventajas de usar Branching como desarrollador en solitario?

Las ventajas son casi las mismas que para los grupos de desarrolladores. Al utilizar una rama maestra siempre lista para la versión, y ramas de funciones para desarrollar nuevas funciones, siempre puede liberar la tarjeta maestra. ¿Encuentre un error importante mientras trabaja en una característica? Cambie de rama, arregle, suelte, cambie de nuevo y continúe desarrollando.

O tal vez este es un proyecto de pasatiempo y simplemente te gusta poder trabajar un poco en esta función y un poco de eso, ya que el estado de ánimo te afecta. Básicamente, estás emulando a un equipo de varias personas por tiempo.

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

Desarrollo de larga ejecución

Bifurcar para un equipo de una sola persona sería útil para una función de desarrollo de larga ejecución que, de lo contrario, no encaja en su ciclo de lanzamiento.

Puede tomar una sucursal para su cambio de varios meses y aún así ser capaz de realizar cualquier corrección o cambio diario de su sucursal principal a intervalos regulares.

Esto tiene la ventaja sobre los 'switches' en una sola sucursal, ya que su sucursal principal está siempre en un estado de implementación y se le garantiza que nada en la función de ejecución prolongada ha tenido un impacto en otro código probado previamente.

Características experimentales

Una rama también puede ser útil para las funciones que quizás desee crear un prototipo, pero que nunca puede incluir en su código implementado. Completar estos en una rama que finalmente pueda ser descartada significa que nunca contaminarás innecesariamente tu base de código principal.

Lo uso para el mantenimiento crítico de sitios web. Soy el único desarrollador, pero tengo un maestro, desarrollo y distribución de sucursales.

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

1. Hacer rama maestra viable. Hacer la confirmación inicial.

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

3. rama del problema de pago. Codifique su problema, cuando esté listo, desplácelo para desarrollarlo, vea si surge algún problema, fusione conflictos, etc ... corríjalos.

Cuando se hayan fusionado suficientes problemas para desarrollar para un lanzamiento y se haya probado el desarrollo de estabilidad, arrastre el desarrollo hacia el maestro.

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

De esa manera, obtienes una colección completa de pruebas en desarrollo, donde puedes probar la estabilidad, problemas, etc. sin tener que arriesgarte a lastimar al Maestro y tener que deshacer los compromisos si fueran dañinos.

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

En la vida real, por lo general tengo una rama problemática y la desarrollo y luego la maestra. A veces es tedioso, pero una vez cada dos meses, al menos, tengo que dejar de trabajar en un abrir y cerrar de ojos porque alguien tuvo una idea de que tengo que hacer RightNow ™ y de esa manera puedo volver rápidamente a un estado base, hacer la cosa y luego después continuaré donde estaba. Especialmente con proyectos grandes que toman varias semanas, es un regalo que puedo cambiar de sucursal rápidamente.

Considere este escenario: siempre trabaja en una sucursal principal y tiene AwesomeCodeThing ™ en los trabajos que dejan a su sucursal Master en cirugía de corazón abierto y aparece un YugeBug ™ que necesita reparaciones urgentes. De lo contrario, miles de usuarios se quejarán con usted. BigProblems ™
La única forma de resolver rápidamente su problema en tal escenario,

1. revisa tus confirmaciones anteriores,
2. ver cuándo fue su última confirmación estable (cursar es opcional)
3. revertir a ese compromiso
4. corregir, empujar arreglar a producción
5. resuelva todos los conflictos y problemas que ahora intenta volver al estado de AwesomeCodeThing ™
6. renunciar, llorar y comenzar a trabajar de nuevo (opcional)

Si usas ramas:

1. Maestro de pago
2. crear rama UrgentFix ™ y arreglar cosas
3. coloca UrgentFix ™ en el master
4. empujar a producción
5. fusionar maestro en desarrollar
6. Merge se convierte en AwesomeCodeThing ™
7. toma una cerveza y continúa trabajando.

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

Digamos que decides que una característica es más importante ahora. Tal vez necesite urgentemente corregir 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 podría querer demostrar el progreso de cada función por separado. Tal vez usted acaba de leer acerca de un exploit de día cero desagradable y quiere entrar en él antes de que dicho cliente lo lea.

Si está utilizando sucursales para cada función / revisión, normalmente será más fácil, más limpio y más rápido aislar e implementar estas modificaciones en lugar de usar una sola sucursal para todo. Esto es cierto tanto si eres un único desarrollador como parte de un equipo.

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

Como lo mencionaron otros carteles, las ventajas son sustancialmente similares a las de los equipos de trabajo: la capacidad de desarrollar y probar funciones de forma independiente, mantener una rama maestra separada para los despliegues de producción / revisiones, experimentar.

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

Sin embargo, si tengo alguna duda acerca de los cambios que estoy realizando, me bifurcaré y solo PR / fusionaré una vez que la rama se comporte como se espera y, en general, esté completamente probada. De esa manera, si descubro un problema para el cual retroceder es el mejor curso de acción, es un solo compromiso en lugar de una serie completa (nunca puedo recordar la sintaxis para revertir una serie de confirmaciones pero una sola es fácil). / p>