Flujo de trabajo Git en equipo: tu primer día paso a paso

Tu primer día en un equipo, el miedo no es escribir código: es romper el trabajo de otra persona. Ya sabes hacer git add, git commit y git push, pero en tus proyectos eras el único que tocaba el repositorio, así que nunca importó demasiado cómo dejabas las cosas. El flujo de trabajo Git de un equipo es el protocolo que deja que ocho personas toquen el mismo proyecto sin pisarse. Este es el ciclo que vas a repetir cada día, paso a paso, y los movimientos que delatan a un recién llegado.

¿Por qué el Git en solitario no te prepara para el equipo?

En solitario, main es tuyo. En un equipo, main es de todos, y si lo rompes bloqueas a la gente que estaba trabajando encima. Ese es el cambio de fondo, y de él salen todas las reglas que vienen después.

Cuando programas solo, haces commits directamente sobre main porque nadie más lo lee. El historial es tu diario privado: da igual que un commit se llame “cambios” y contenga medio proyecto. En cuanto entras en un equipo, ese mismo historial se convierte en algo que otras personas van a leer, revisar e integrar con su propio trabajo. Y main deja de ser tu zona de pruebas para convertirse en la versión que se despliega.

Aspecto	En solitario	En un equipo
Dónde escribes código	Directo sobre main	En una rama de feature aislada
Quién lee tu historial	Solo tú, a veces	Toda la persona que revise tu Pull Request
Cuándo integras	Cuando quieras, sin avisar	Tras una revisión y con main actualizado
Quién aprueba el cambio	Nadie	Al menos otra persona del equipo
Si rompes main	Te molesta a ti	Bloquea a todo el que estaba trabajando encima

Ese salto suena a burocracia hasta que lo vives. La primera vez que alguien construye una feature sobre tu commit roto, entiendes por qué existe el ciclo. La guía completa de por qué el equipo trabaja así la tienes en trabajar en equipo con Git y GitHub; aquí vamos al ciclo concreto.

Paso 1: empieza siempre desde un main actualizado

Antes de escribir una sola línea, sitúate en main y trae los últimos cambios del remoto. main avanzó mientras tú dormías, porque otras personas mergearon su trabajo, y ramificar desde una versión vieja es la forma más silenciosa de crearte conflictos.

# Sitúate en main y trae lo que el equipo haya mergeado
git switch main
git pull

git switch es el comando para moverte entre ramas. Durante un tiempo llevó una nota de “experimental”, pero esa nota ya se retiró: hoy es estable y es la forma recomendada de cambiar de rama. git pull descarga lo nuevo del remoto y lo integra en tu main local. Después de estos dos comandos, tu punto de partida es idéntico al del resto del equipo. Ahora sí puedes ramificar.

Paso 2: crea una rama de feature para tu tarea

Cada tarea vive en su propia rama, creada a partir de ese main fresco. Una rama es una línea de trabajo paralela: escribes ahí, rompes ahí, experimentas ahí, y main sigue intacto mientras tanto.

# -c crea la rama y te mueve a ella en un solo paso
git switch -c feature/validar-email

El prefijo feature/ es una convención, no una regla de Git. A Git le da igual cómo se llame la rama, pero al equipo no: un nombre como feature/validar-email dice de un vistazo qué hay dentro. Muchos equipos usan feature/, fix/ o chore/ como prefijo; mira cómo nombran las ramas tus compañeros y copia ese estilo. La regla que sí es de Git: esa rama parte del main en el que estabas, así que actualizarlo antes (paso 1) no era opcional.

Paso 3: haz commits pequeños y frecuentes

Un commit pequeño es un mensaje a la persona que va a revisar tu código. Cuando trabajabas solo, el commit servía para guardar tu progreso y punto. Ahora tiene un segundo lector, y ese lector necesita entender tu razonamiento sin sentarse a tu lado.

Compara estos dos historiales. Uno cuenta una historia; el otro es una caja negra.

a3f9c21 feat: valida el formato del email en el registro
7b2e410 test: añade casos de email inválido
c8d1f05 refactor: extrae la regex a una constante

Frente a un único commit d4e0f88 cambios varios con cuarenta archivos dentro. El primero se revisa en cinco minutos porque cada paso es una idea. El segundo obliga a tu compañero a reconstruir en su cabeza todo lo que hiciste, y ahí es donde los bugs pasan la revisión sin que nadie los vea.

Un detalle práctico que confunde a mucha gente al empezar: git commit -am solo prepara los archivos que Git ya está siguiendo. Si has creado un archivo nuevo, ese atajo lo ignora, y tienes que hacer git add de forma explícita:

git add src/validators/email.ts
git commit -m "feat: valida el formato del email en el registro"

Paso 4: sube tu rama con git push -u

Tu rama vive solo en tu máquina hasta que la subes al remoto. Y hasta que no está en el remoto, ni el equipo la ve ni puedes abrir un Pull Request con ella.

# La primera vez, -u enlaza tu rama local con la del remoto
git push -u origin feature/validar-email

La -u (abreviatura de --set-upstream) enlaza tu rama local con la del remoto. Es un gesto de la primera vez: a partir de ahí, cada nuevo commit se sube con un git push a secas, sin repetir el nombre de la rama, porque Git ya sabe a dónde va. Si lo omites la primera vez, Git te lo recuerda con el comando exacto que te falta.

Paso 5: abre un Pull Request

Un Pull Request es la petición formal de integrar tu rama en main. Lo abres desde GitHub cuando tu rama ya está subida, y a partir de ese momento tu trabajo deja de ser tuyo: pasa a ser una propuesta que el equipo puede leer, comentar y aprobar.

La descripción del PR es la parte que más se descuida y la que más se agradece. No repitas lo que ya dicen los commits. Explica el porqué: qué problema resuelve, qué decisión tomaste y por qué, y qué debería mirar con lupa quien revise. Si el email ahora se valida con una expresión regular concreta, di por qué esa y no otra. Un buen PR responde las preguntas antes de que tu compañero tenga que escribirlas. Si quieres el detalle de qué es y cómo se estructura, lo desarrollo en qué es exactamente un Pull Request.

¿Cómo recibo la revisión de código sin tomármelo personal?

Los comentarios de la revisión van dirigidos al código, no a ti. Esta es la parte que más cuesta el primer día, porque nadie te avisa de que ver muchos comentarios en tu PR es lo normal y lo bueno, no una señal de que lo hiciste mal.

La revisión funciona así: alguien lee tu diff, deja comentarios y quizá pide cambios. Tú respondes, corriges lo que tenga sentido y discutes con argumentos lo que no. Cuando cambias algo, haces nuevos commits en la misma rama y los subes con git push; el Pull Request se actualiza solo. Cada comentario que atiendes es un bug menos que llega a producción, y quien revisa está poniendo su nombre junto al tuyo en ese merge. Está de tu lado.

Lo que sí es una mala señal: responder a la defensiva, o mergear ignorando los comentarios porque tenías prisa. Eso quema la confianza más rápido que cualquier bug.

Paso 6: merge, y luego borra la rama

Cuando el PR está aprobado, se hace merge y tu código entra en main. En casi todos los equipos el merge se hace desde el botón de GitHub, no desde tu terminal, para que quede registrado quién aprobó qué. A partir de ahí, tu rama ya cumplió su función.

# Vuelve a main, tráete tu propio cambio ya mergeado y borra la rama local
git switch main
git pull
git branch -d feature/validar-email

git branch -d borra la rama local solo si ya está integrada en main, así que es una red de seguridad: si Git se niega, es que aún hay commits sin mergear ahí. La rama remota suele borrarse desde el propio botón de merge en GitHub. Se borra porque su historia ya vive dentro de main; conservarla solo llena la lista de ramas de fantasmas que nadie recuerda para qué servían.

Y con eso cierras el ciclo. Vuelves al paso 1 para la siguiente tarea, otra vez desde un main actualizado que ahora incluye tu propio trabajo. Cuando el equipo crezca y necesitéis acordar reglas más estrictas sobre cuándo y cómo se ramifica, ahí entran las estrategias de ramas como Git Flow, GitHub Flow y trunk-based. Para tu primer día, este ciclo te cubre entero.

Antes de seguir, ordena tú mismo los pasos del ciclo. Este ejercicio te pone las fases en desorden para que las coloques como las harías en tu primer día:

Cargando ejercicio...

Errores de primer día

Trabajar directo sobre main

El clásico. Haces git switch main por costumbre, escribes tu código ahí y lo subes. Ahora tu trabajo a medio hacer está en la rama que se despliega, sin revisar, mezclado con el de todos. Regla mental: si al mirar en qué rama estás ves main, no escribas todavía, ramifica.

Una rama gigante con un único commit de cuarenta archivos

Trabajas dos semanas en silencio y sueltas todo de golpe en un solo commit. Nadie puede revisar eso de verdad, así que quien te revisa hace scroll, se rinde y aprueba a ciegas. Has convertido la revisión en un trámite vacío. Trocea en commits pequeños y, si la tarea es enorme, en varios PRs.

git push --force sobre una rama compartida

Forzar el push reescribe la historia del remoto y puede borrar commits de otra persona que trabajaba sobre tu rama. Si de verdad necesitas forzar, git push --force-with-lease es más seguro porque falla si el remoto avanzó desde la última vez que lo miraste, en lugar de machacarlo sin preguntar. No es la única forma segura de forzar, pero sí la que evita el accidente más común. Sobre una rama que otros tocan, lo mejor es directamente no forzar.

Ramificar desde un main viejo

Te saltas el git pull del paso 1 y creas tu rama sobre una versión de hace tres días. Todo va bien hasta que abres el PR y aparece una montaña de conflictos que no tienen nada que ver con tu tarea. Actualizar main antes de ramificar te ahorra esa tarde entera.

Tomarte la revisión como algo personal

Ya lo dijimos arriba, pero se repite porque es el error que más gente quema el primer mes: los comentarios son sobre el código, y atenderlos es exactamente el trabajo, no un castigo.

Checklist de tu primer día

• Antes de ramificar, git switch main seguido de git pull
• Cada tarea en su propia rama de feature con nombre descriptivo
• Commits pequeños, cada uno con una sola idea y un mensaje claro
• git add explícito para los archivos nuevos (no confíes en -am)
• git push -u origin <rama> la primera vez; luego git push a secas
• El PR describe el porqué del cambio, no solo el qué
• Tras el merge, borra la rama local con git branch -d

Practica el ciclo antes de tu primer día

Leer el ciclo es una cosa, tenerlo en los dedos es otra. En el curso Git de cero a profesional recorres este flujo de trabajo en un entorno guiado: creas la rama, haces los commits, abres el Pull Request y pasas la revisión hasta que el ciclo te sale solo, sin miedo a romper nada real.

Un concepto nuevo cada semana

Suscribirme

Preguntas Frecuentes

¿Puedo tener varias ramas de feature a la vez?

Sí, y es normal. Cada tarea independiente va en su propia rama, y te mueves entre ellas con git switch <nombre>. Lo único que conviene evitar es empezar una rama nueva a partir de otra rama sin terminar, porque entonces atas el destino de las dos.

¿Cada cuánto debería hacer commit?

Cada vez que completes una idea pequeña y coherente: una función que ya valida, un test que pasa, un refactor cerrado. No esperes al final del día. Un commit por idea hace que tu historial se lea como pasos lógicos y que revertir algo concreto sea trivial.

¿Qué pongo en la descripción del Pull Request?

El porqué, sobre todo. Explica qué problema resuelve el cambio, qué decisión de diseño tomaste y dónde debería fijarse quien revise. Los commits ya cuentan el qué; la descripción cuenta el contexto que no cabe en un mensaje de commit.

¿Y si me piden cambios en la revisión?

Corriges lo que tenga sentido y lo comentas si no lo tiene. Haces nuevos commits en la misma rama, un git push, y el Pull Request se actualiza solo sin que tengas que abrir otro. Pedir cambios es la parte sana del flujo de trabajo Git en equipo, no un rechazo.

¿Tengo que borrar la rama después del merge?

Sí. Una vez mergeada, su historia ya vive dentro de main, así que la rama solo ocupa sitio y confunde. Borra la local con git branch -d y la remota desde el botón de merge en GitHub. Si más adelante necesitas ese código, sigue estando en el historial de main.