GitHub Push/Pull Paso a Paso
GitHub asusta más por el vocabulario que por la mecánica. Push y pull son dos direcciones del mismo tubo: bajar lo que el equipo ya fusionó, y subir lo que tú acabas de terminar. Esta guía cubre el ciclo diario que usamos en repos de Laravel, Vue y sitios estáticos.
Antes de tocar código
- Crea una cuenta en GitHub y agrega tu llave SSH (o usa HTTPS con un personal access token).
- Pide acceso al repositorio. Sin invitación, el clone va a fallar y no es “culpa de Git”.
- Instala Git y abre una terminal en la carpeta donde quieres el proyecto.
Clonar (la primera vez)
En la página del repo, copia la URL SSH ([email protected]:org/repo.git) y corre:
git clone [email protected]:org/repo.git && cd repo
Eso crea una copia local ligada al remoto llamado origin. A partir de aquí ya no clonas otra vez: actualizas.
Pull: bajar el trabajo de los demás
Antes de empezar el día, y otra vez antes de abrir un pull request:
git checkout main && git pull origin main
Si trabajas en una rama, primero actualiza main y luego fusiona o rebasea tu rama. Un pull con cambios locales sin commitear te va a detener: o haces stash, o commiteas. No ignores el aviso.
Push: subir lo tuyo
- git status para ver qué cambió.
- git add de los archivos que sí van (nunca .env).
- git commit -m "mensaje en presente: corrige el formulario de cotización".
- git push origin tu-rama
La primera vez que la rama no existe en GitHub, Git te sugiere --set-upstream. Acéptalo. Después, abre el Pull Request en github.com, pide review, y no hagas push a main directo salvo que el equipo lo tenga explícito.
Cuando algo sale mal
Conflictos no son un error moral. Abre el archivo, busca las marcas <<<<<<, elige el código correcto, git add y continúa. Si empujaste de más, no hagas force push a main. En ramas propias, coordina antes de reescribir historia.
Si tu equipo aún mueve ZIP por WhatsApp, este flujo ya es una mejora. El siguiente paso es un PR pequeño, con un reviewer, y un deploy que no dependa de “lo subi anoche”.