Es raro, muy raro, que un desarrollador trabaje solo en un proyecto, yo he trabajado como freelance durante un rato y de esta manera tampoco suelo trabajar 100% en solitario.
Aquí la importancia de usar Git, que como la mayoría de herramientas, bien aprovechado puede ser de mucha utilidad y mal usado no sirve de mucho.
Trabaje con Subversion mucho tiempo y no es que sea malo, solo que si solemos ser un poco más perezosos a la hora de enviar nuestros cambios de código, puede ocasionar ciertos conflictos con equipos grandes de programadores. En lo personal me adapte de mejor manera a Git por el hecho de poder gestionar un flujo de trabajo o Gitflow.
Básicamente es una estandarización de ramificaciones estrictas y diseñadas para proyectos de software. Permite paralelizar el desarrollo, la entrega continua de código o bloques de código, mejoras y reparaciones con ramas o git branches. Dicta lo siguiente:
Ramas principales
Siempre deben existir dos branches principales:
master/main. El branch siempre es productivo, hecho para contener todo el código de un proyecto estable. Como regla nunca se debería de subir nada directamente aquí, solo mediante algún PULL REQUEST o MERGE REQUEST. Claro mientras la vida del software sea un estado productivo, en desarrollo se puede tener un poco más de flexibilidad.
develop. Un branch no productivo donde se encuentran los últimos cambios ya liberados y probados por los desarrolladores. En este punto se pueden hacer despliegues a un entorno de desarrollo o pruebas, donde un equipo de QA o los mismos programadores hacen revisiones.
Como comentario, algún día me preguntaron lo siguiente:
“En github solo se puede tener un branch principal, digamos master, ¿Cómo se hace principal la rama develop?”
La respuesta es, develop es un branch simbólico, un branch cualquiera con una gestión diferente.
Ramas secundarias o de apoyo
Sabiendo que solo existen dos ramas principales en la gestión de nuestro repositorio, las ramas de apoyo cuentan con un fin muy específico y tienen un ciclo de vida, que cuando cumplen su objetivo deben ser eliminadas, tenemos las siguientes:
feature. Una rama para gestión de mejoras y nuevas funcionalidades, suelen partir de develop. Un punto importante es que los desarrolladores son los encargados de gestionar y dar por liberado estos branches, al ser liberados y probados internamente se incorporan al branch develop en donde pasan a ser testeados antes de ser productivos. Por ejemplo:
Se desea una nueva funcionalidad de facturación en un software de ventas. Se parte de lo más actualizado de la rama develop y se crea un branch con la convención feature, llámese: feature/inventories.
release. Esta rama es como un entorno pre productivo, de hecho se puede utilizar de esta manera y solo indica la versión estable que se lanzará a producción. Es como un historial por si se caga algo regresamos al anterior en vez de resetear la rama master. La convención se podría manejar con release/****.
hotfix. Un branch que lo comparo como el salvavidas o los bomberos para atacar el fuego. La idea es que si hay que resolver algo muy urgente en un ambiente productivo se crea un branch hotfix/**** para resolver el problema.
El diagrama de lo explicado anteriormente sería algo como esto:
Ya en la práctica, esto es muy flexible, puedes generar un flujo de trabajo partiendo de este, depende claro de tu proyecto, que es el que le da forma al flujo de trabajo, no es que tiene que ser así al pie de la letra, lo importante es definir un flujo inicial y respetarlo, por ejemplo en algún punto en vez de usar ramas releases, use git tags, al final esto solo es un apoyo a mejorar la productividad del equipo y de la entrega de software.