Elige un modelo sencillo de ramas de Git

En un primer proyecto en equipo, mantén pequeño el modelo de ramas: main debe estar siempre lista para desplegarse y cada tarea debe tener una única rama de funcionalidad de corta duración. Si el equipo está creando una landing page con React y una API de checkout, el trabajo puede mantenerse en feature/pricing-page y feature/create-checkout-session en lugar de concentrarse en una única rama de desarrollo compartida. Esta separación permite que dos desarrolladores trabajen en paralelo sin mezclar código sin terminar. Evita añadir ramas develop, release o hotfix hasta que el proyecto tenga un proceso de lanzamiento real que las necesite.

Acuerden el flujo de trabajo antes de comenzar con el primer ticket. Dejen por escrito que main solo acepta cambios mediante una pull request, que las ramas de funcionalidad parten de main y que las ramas fusionadas se eliminan. Por ejemplo, una tarea de restablecimiento de contraseña debería avanzar desde el issue a la rama de funcionalidad, luego pasar por la revisión y llegar finalmente a main, sin hacer push directo a la rama compartida. Estas reglas convierten el control de versiones en un hábito de equipo predecible, en lugar de dejarlo en manos de preferencias personales.

Configura main y las reglas para nombrar ramas

Protege main en la configuración del repositorio antes de que alguien abra una pull request. Exige que se superen las comprobaciones automatizadas y que haya al menos una aprobación, y bloquea los force pushes para que un error local no pueda reescribir el historial compartido del equipo. Para un equipo de cuatro personas, exigir un revisor suele ser una regla inicial práctica; aumenta el requisito para código sensible de pagos o autenticación. Mantén la regla visible en CONTRIBUTING.md para que una persona nueva en el equipo pueda seguirla sin tener que pedir una explicación privada.

Usa nombres de ramas que indiquen la intención y, cuando esté disponible, el ID de la tarea. Algunos ejemplos son feature/42-reset-password, fix/57-cart-total, docs/api-setup y chore/update-node. Los nombres en minúsculas con guiones son más fáciles de revisar en la salida del terminal y en las listas de pull requests que nombres como John'sNewBranch o work. Elimina las ramas después de fusionarlas para que la lista remota refleje el trabajo activo en lugar de acumular meses de experimentos abandonados.

Comienza las funcionalidades desde una rama main actualizada

Antes de programar, sincroniza el repositorio local con el remoto y crea la rama de funcionalidad a partir de la rama main actual. Ejecuta git switch main, luego git pull --ff-only origin main y crea la rama con git switch -c feature/42-reset-password. La opción --ff-only impide que Git cree silenciosamente un commit de merge inesperado durante esta actualización. Partir de una base actualizada reduce la probabilidad de que una tarea de tres días entre inmediatamente en conflicto con un cambio integrado ayer.

Comprueba el nombre de la rama y el punto de partida con git status y git log --oneline --decorate -5 antes de editar archivos. Si la tarea ya tiene una rama existente, ejecuta primero git fetch origin y compárala con origin/main en lugar de crear una segunda rama con un nombre similar. Si una rama está un commit por detrás, puedes actualizarla con git rebase origin/main después de confirmar que tu trabajo local está guardado en un commit. No hagas rebase de una rama que varios compañeros estén utilizando activamente, a menos que el equipo haya acordado reescribir el historial resultante.

Haz commits de Git pequeños y fáciles de revisar

Haz commits lo bastante pequeños como para que otro desarrollador pueda entender cada cambio en uno o dos minutos. Una funcionalidad de checkout podría utilizar un commit para la migración de la base de datos, otro para el endpoint y otro para el formulario, mientras que una corrección tipográfica de tres líneas normalmente debería mantenerse en un solo commit. Ejecuta las pruebas pertinentes antes de cada push, porque un commit fácil de revisar que falla el conjunto de pruebas existente sigue ralentizando al equipo. Mantén los archivos generados, los secretos del entorno local y los cambios de formato no relacionados fuera de la rama.

Escribe los mensajes de commit en modo imperativo, como Add password reset validation o Fix cart total rounding. Cada mensaje debe explicar la intención, mientras que el diff muestra los detalles de implementación. Después de comprobar el resultado localmente, publica una rama nueva con git push -u origin feature/42-reset-password. Si descubres un error antes de la revisión, corrígelo con amend o haz squash localmente; una vez que los revisores hayan empezado a comentar, es preferible crear un commit correctivo nuevo para que la discusión siga siendo rastreable.

Abre un pull request y ejecuta CI

Abre el pull request en cuanto la rama esté lista para la revisión, aunque el cambio solo afecte a seis archivos. Establece main como rama de destino, enlaza la tarea, describe qué ha cambiado y registra el comando exacto de validación, como npm test y npm run lint. Para un cambio en un formulario de inicio de sesión, incluye la ruta afectada, el comportamiento del teclado, una captura de pantalla del estado de error y cualquier paso de migración que el revisor deba ejecutar. Marca la solicitud como borrador solo cuando quieras recibir comentarios iniciales antes de solicitar la aprobación.

Utiliza la integración continua para ejecutar en el pull request las mismas comprobaciones de calidad que el equipo espera en el portátil de un desarrollador. Una primera pipeline útil puede instalar las dependencias, ejecutar las pruebas unitarias, ejecutar el linting y compilar la aplicación en cuatro pasos independientes y visibles. Si la compilación falla porque se omitió un archivo package-lock, corrige la rama y vuelve a hacer push en lugar de pedir al revisor que ignore el indicador rojo. CI es una señal, no un sustituto de la revisión: una prueba puede pasar mientras un botón sigue siendo inaccesible o una respuesta de API expone datos privados.

Revisa, integra y mantén estable main

Considera los comentarios de revisión como cambios en el diseño compartido, no como una votación sobre el autor. Si un revisor pide validación en el servidor para un campo de precio, actualiza el código, añade una prueba específica para un valor negativo como -1 y responde con el commit o la ubicación del archivo. Resuelve las dudas en el pull request para que el historial final registre por qué cambió la implementación. Pide un segundo revisor cuando el primer comentario revele una preocupación más amplia sobre la seguridad, la pérdida de datos o el comportamiento de una API pública.

Elige una política de merge y aplícala de forma coherente. Para un primer proyecto, hacer squash de una funcionalidad de cinco commits en un único commit descriptivo mantiene limpio el historial de main, mientras que los equipos que necesitan una arqueología detallada de las versiones pueden conservar los commits individuales. Haz el merge solo después de que las comprobaciones requeridas estén en verde, las aprobaciones estén actualizadas y la rama no esté atrasada respecto a main según la regla del repositorio. Después del merge, anuncia cualquier paso manual de despliegue o migración antes de empezar la siguiente tarea.

Resolver conflictos y limpiar ramas

Cuando main cambie mientras trabajas, actualiza la rama antes de solicitar la aprobación final. Obtén los cambios remotos, ejecuta git rebase origin/main y resuelve los conflictos archivo por archivo; por ejemplo, conserva el componente de botón compartido más reciente mientras mantienes el nuevo comportamiento de checkout. Después de editar un conflicto, ejecuta git add en el archivo y git rebase --continue; luego vuelve a ejecutar las pruebas. Si el conflicto se vuelve confuso, git rebase --abort devuelve la rama a su estado anterior al rebase, para que puedas pedir ayuda sin perder el trabajo confirmado.

Una vez fusionado el pull request, elimina la rama remota con git push origin --delete feature/42-reset-password y elimina la copia local con git branch -d feature/42-reset-password. Después, ejecuta git switch main y git pull --ff-only origin main antes de elegir el siguiente ticket. Si queda trabajo sin terminar, crea una rama nueva a partir de la versión actualizada de main en lugar de continuar con una rama ya fusionada. Después de una semana, el repositorio debería mostrar una rama main estable, un conjunto reducido de tareas activas y un historial que explique cada cambio visible para el usuario.

Artículos relacionados

Lecturas adicionales

Git

control de versiones

integración continua