El flujo de trabajo de Git que realmente funciona para desarrolladores solistas

Aún recuerdo el momento exacto en que me rompí. Eran las 2 AM de un martes, y estaba mirando un conflicto de fusión entre mi rama feature/redesign y main. ¿La broma? Yo era el único desarrollador en el proyecto. Literalmente estaba en un conflicto de fusión conmigo mismo.

Tres días de trabajo—perdidos. No por un fallo catastrófico de disco duro o un repositorio eliminado. No, perdí esos tres días porque había seguido religiosamente un flujo de trabajo de Git diseñado para equipos de más de 10 desarrolladores. Tenía ramas de características, ramas de corrección rápida, ramas de lanzamiento y una rama develop que existía únicamente para hacerme sentir profesional. La ironía no se me escapó: había pasado más tiempo gestionando Git que escribiendo código.

Esa noche, sentado en mi oficina en casa con café frío y un ego golpeado, tomé una decisión. Iba a despojarme de cada ceremonia de Git que no me sirviera como desarrollador solista. No más flujos de trabajo de equipo de culto. No más pretender que necesitaba la misma infraestructura que un equipo de ingeniería de 50 personas.

Lo que surgió de esa frustración es el flujo de trabajo que he utilizado para enviar más de 40 proyectos solistas desde entonces. No es sexy. No impresionará a nadie en una conferencia tecnológica. Pero funciona, y lo que es más importante, me deja construir cosas.

Por qué la mayoría de los flujos de trabajo de Git fallan para desarrolladores solistas

El problema con la mayoría de los tutoriales y flujos de trabajo de Git es que están escritos por personas que trabajan en empresas con múltiples equipos, procesos de revisión de código y canalizaciones de despliegue que involucran al menos tres entornos diferentes. Cuando eres un desarrollador solista, no tienes esas restricciones—pero tampoco tienes esas redes de seguridad.

GitFlow, el flujo de trabajo que dominó la década de 2010, es un ejemplo perfecto. Fue diseñado por Vincent Driessen para un problema específico: gestionar lanzamientos para software que necesitaba soportar múltiples versiones simultáneamente. Si estás construyendo una aplicación de escritorio que los clientes instalan localmente, GitFlow tiene sentido. Si eres un desarrollador solista enviando un producto SaaS o un sitio web para un cliente, es un exceso total.

El viaje típico de un desarrollador solista con Git es algo así: comienzas con solo hacer commit a main (o master, dependiendo de cuándo aprendiste Git). Luego lees un artículo sobre "flujos de trabajo de Git profesionales" y te sientes culpable. Implementas ramas de características. Luego añades una rama develop porque eso es lo que mostraba el diagrama. Antes de mucho tiempo, estás pasando 20 minutos al día solo gestionando ramas, y ni siquiera estás seguro de por qué existen la mitad de ellas.

He estado allí. He tenido repositorios con ramas llamadas feature/nueva-característica, feature/nueva-característica-2, feature/nueva-característica-en-realidad-final, y feature/nueva-característica-de-verdad-esta-vez. Si nunca has tenido una crisis de nombres de ramas, o estás mintiendo o no has estado desarrollando solo el tiempo suficiente.

El problema fundamental es que los flujos de trabajo de equipo están diseñados para resolver problemas de equipo: coordinar el trabajo entre múltiples personas, prevenir conflictos, gestionar procesos de revisión de código y mantener estabilidad en entornos compartidos. Cuando trabajas solo, la mayoría de estos problemas simplemente no existen. No puedes tener un conflicto de fusión con alguien más si no hay nadie más.

La regla de los tres commits que lo cambió todo

Después de mi desastre a las 2 AM, comencé a analizar mis patrones de trabajo reales. Revisé mi historial de Git de los seis meses anteriores y miré cada rama que había creado, cada fusión que había hecho y cada conflicto que había resuelto. Lo que encontré fue iluminador.

El noventa por ciento de mis ramas de características contenía tres commits o menos antes de fusionarse. No eran características complejas, de varias semanas, que necesitaban aislamiento. Eran pequeñas mejoras, correcciones de errores y cambios incrementales que había separado artificialmente en ramas porque pensé que eso era lo que hacían los "desarrolladores reales".

El restante diez por ciento—las características realmente complejas—eran donde las ramas tenían sentido. Pero incluso entonces, noté algo: las ramas que causaban problemas eran las que había dejado abiertas durante más de una semana. Cuanto más tiempo vivía una rama, más probable era que causara problemas al fusionarse de nuevo.

Esto me llevó a lo que llamo la Regla de los Tres Commits: Si un cambio toma más de tres commits, probablemente sea demasiado grande y deba descomponerse. Si no se puede descomponer, es uno de los raros casos en los que una rama realmente ayuda.

Esta regla me obligó a pensar de manera diferente sobre cómo trabajo. En lugar de crear una rama para "rediseñar toda la interfaz de usuario", crearía una rama para "actualizar estilos de botones" o "implementar nuevo componente de navegación". Cada rama vivía uno o dos días como máximo, contenía cambios enfocados y se fusionaba limpiamente.

El cambio psicológico fue significativo. Deje de pensar en términos de "características" y comencé a pensar en términos de "incrementos desplegables". Cada rama tenía que representar algo que podía enviar a producción sin romper la funcionalidad existente. Esto naturalmente mantenía las ramas pequeñas y de corta duración.

El día que envié un bug a producción (y por qué mejoró mi flujo de trabajo)

Déjame contarte sobre el peor despliegue de mi carrera. Estaba trabajando en un proyecto para un cliente—un sistema de reservas para una pequeña cadena hotelera. Había estado trabajando en una rama de características durante dos semanas (sí, lo sé, rompí mi propia regla) que añadía una nueva integración de pago.

La rama se había desviado significativamente de main. Había estado tan enfocado en la característica de pago que no había estado al día con las pequeñas correcciones y mejoras que había estado haciendo directamente en main para solicitudes urgentes del cliente. Cuando llegó el momento de fusionar, tuve conflictos en 14 archivos.

Resolví los conflictos, ejecuté las pruebas (pasaron) y desplegué a producción. Dentro de una hora, recibí una llamada en pánico del cliente. El formulario de reservas estaba roto. No la nueva integración de pagos—el formulario de reservas básico que había estado funcionando bien durante meses.

¿Qué pasó? Al resolver uno de los conflictos de fusión, accidentalmente mantuve la versión incorrecta de una función. Las pruebas no lo detectaron porque no había escrito pruebas para ese caso particular (lección aprendida). El error fue completamente culpa mía, pero el flujo de trabajo había facilitado cometer ese error.

Ese incidente me enseñó algo crucial: como desarrollador solista, mi mayor riesgo no es el código de otras personas—es mi propio código de hace dos semanas. Cuando cambio de contexto entre diferentes partes de un proyecto, estoy esencialmente colaborando con versiones pasadas de mí mismo. Y el yo del pasado es a menudo un colega poco confiable.

Esta realización llevó al segundo pilar de mi flujo de trabajo: la Regla de la Semana. Ninguna rama vive más de una semana. Si una característica va a tardar más que eso, la divido en piezas más pequeñas que pueden completarse y fusionarse dentro de una semana. Si eso no es posible, utilizo banderas de características para fusionar código incompleto en main mientras lo mantengo oculto de los usuarios.

La Regla de la Semana me ha salvado innumerables veces. Me obliga a mantenerme cerca de main, lo que significa que siempre estoy trabajando con la versión más actual de la base de código. Previene el tipo de divergencia que lleva a conflictos de fusión complejos. Y me mantiene honesto sobre el alcance—si no puedo terminar algo en una semana, probablemente estoy tratando de hacer demasiado a la vez.

El verdadero costo de la complejidad de las ramas

Hablemos de números. Realicé un seguimiento de mis actividades relacionadas con Git durante tres meses antes y después de simplificar mi flujo de trabajo. Los resultados fueron sorprendentes:

Casi nueve horas a la semana. Eso es más de una jornada laboral completa que estaba dedicando a ceremonias de Git en lugar de escribir código. En un año, son más de 450 horas—más de 11 semanas laborales completas.

Pero los ahorros de tiempo ni siquiera eran el beneficio más significativo. Lo que realmente cambió fue mi carga mental. Antes, a menudo me encontraba mirando mi terminal, tratando de recordar qué rama tenía qué cambios, si ya había fusionado algo o si necesitaba hacer un rebase antes de fusionar. Estas micro-decisiones se sumaban a una carga cognitiva significativa.

Después de simplificar mi flujo de trabajo, esas decisiones desaparecieron. Siempre sabía dónde estaba mi trabajo porque solo había una o dos ramas como máximo. Nunca tuve que pensar en estrategias de rebase o estrategias de fusión porque las ramas eran tan de corta duración que los conflictos eran raros.

Los datos también revelaron algo que no esperaba: mi frecuencia de commits aumentó en un 40%. Con menos fricción en mi flujo de trabajo, estaba haciendo commits más a menudo, lo que significaba commits más pequeños y enfocados. Esto facilitó la comprensión de mi historial y, cuando fue necesario, revertir cambios específicos sin deshacer un montón de trabajo no relacionado.

Por qué "Compromete pronto, compromete a menudo" es incorrecto para desarrolladores solistas

Aquí hay una opinión controvertida: el consejo de "comprometerse pronto, comprometerse a menudo" es en realidad perjudicial para los desarrolladores solistas. Sé que esto va en contra de la sabiduría convencional, pero escúchame.

El propósito de los commits no es crear un registro detallado de cada pulsación de tecla. Es crear puntos de control significativos que cuenten una historia sobre cómo evolucionó tu código. Cuando estás trabajando solo, eres la única persona que necesita entender eso.