Tu copia, la del equipo

Local y remoto

Git es distribuido: cada persona tiene el repositorio completo, con toda su historia, en su computadora. Para trabajar en equipo se acuerda una copia central, el remoto, que suele vivir en un servicio como GitHub, GitLab o Bitbucket. Por costumbre se llama origin.

Tu repositorio guarda además una foto de cómo estaba el remoto la última vez que hablaste con él: las ramas origin/main, origin/feature… No se actualizan solas; cambian solo cuando te comunicas con el remoto.

git clone https://github.com/ana/tienda.git   # copia el remoto completo y crea origin
git remote add origin URL      # conecta un repositorio que creaste con git init
git fetch                      # trae lo nuevo del remoto a origin/…, sin tocar tus ramas
git pull                       # fetch + merge de origin/tu-rama en tu rama
git push -u origin carrito     # sube la rama y la deja enlazada (luego basta git push)

Si alguien subió commits a una rama que tú también cambiaste, tu push se rechaza: el remoto no acepta perder el trabajo ajeno. La solución es integrar primero lo suyo con git pull (o git pull --rebase) y volver a subir. Existe git push --force, que pisa el remoto con tu versión, pero en ramas compartidas borra el trabajo de otros: casi nunca es la respuesta.

Pull requests

Un pull request (PR; en GitLab, merge request) es una propuesta: «quiero integrar la rama carrito en main». No es una orden de Git sino una función del servicio, donde el equipo ve los cambios, comenta línea por línea, pide correcciones y, cuando está conforme, aprueba. El flujo habitual:

1. Creas una rama, haces commits y la subes con git push -u origin carrito.
2. Abres el PR hacia main, con un título y una descripción de qué cambia y cómo probarlo.
3. Las pruebas automáticas corren sobre la rama y otra persona revisa. Si pide cambios, haces más commits en la misma rama y el PR se actualiza solo.
4. Con la aprobación, se integra y se borra la rama.

Para que esto no dependa de la buena voluntad, la rama principal se protege: nadie puede hacer push directo, todo entra por PR, con un mínimo de aprobaciones y con las pruebas en verde. En un proyecto ajeno donde no tienes permiso de escritura, primero haces un fork (tu copia del repositorio en tu cuenta), subes ahí tu rama y abres el PR desde el fork hacia el original.

Merge, squash o rebase

Al integrar un PR, GitHub ofrece tres botones. Create a merge commit conserva todos los commits de la rama y agrega uno de merge. Squash and merge junta todos los commits del PR en uno solo sobre main: la historia de main queda con un commit por PR, aunque se pierde el detalle. Rebase and merge copia los commits uno por uno encima de main, sin commit de merge. Cada equipo elige uno y lo usa siempre.

Antes de leer la respuesta