Facundo Uferer
Tu PC no depende de la nube: el repositorio completo vive en tu disco
A diferencia de los sistemas centralizados obsoletos (como SVN), Git es peer-to-peer. Tu clon local posee el grafo completo de commits, tags y ramas. Los servidores como GitHub son simplemente repositorios remotos con un alias convencional: origin.
- ✓
git commit(inmediato, sin latencia de red) - ✓
git branch&git switch(creación y cambio de ramas en milisegundos) - ✓
git log&git diff(consulta del historial histórico completo offline) - ✓
git merge&git rebase(integración local autónoma)
Almacena la copia canónica de referencia para el equipo. Se sincroniza exclusivamente mediante protocolos de red (SSH o HTTPS).
git push: transfiriendo tus commits confirmados a la nube
Hacer git commit guarda los cambios en tu PC. Para compartirlos con tu equipo o respaldarlos en GitHub, necesitas ejecutar git push. Esto envía los paquetes de objetos y avanza la referencia origin/main en el servidor.
La gran diferencia: git fetch vs git pull
Muchos principiantes confunden estos comandos: git fetch es pasivo y seguro (descarga objetos y actualiza origin/main sin tocar tus archivos de trabajo). git pull es agresivo: hace fetch y ejecuta un merge inmediato sobre tu rama actual.
Commit C4 subido por tu compañero en la nube.
origin/main (ref): Apunta a C2
Working Tree (archivos): Apunta a C2 (Limpio)
💡 Usa git fetch cuando quieras revisar qué cambios hay antes de integrarlos a ciegas.
Por qué usamos git push -u origin main y qué hace el upstream
La primera vez que subes una rama, Git no sabe a qué rama remota vincularla. La bandera -u (--set-upstream) crea un enlace permanente en tu configuración local. A partir de ese momento, basta con escribir git push o git pull a secas.
[core]
repositoryformatversion = 0
[remote "origin"]
url = git@github.com:facundo/proyecto.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "main"]
remote = origin
merge = refs/heads/main Everything up-to-date
Branch 'main' set up to track remote branch 'main' from 'origin'.
Error: [rejected - non-fast-forward] y cómo resolverlo
Si tu compañero publicó cambios en GitHub mientras tú trabajabas en local, sus historias divergen. Git te bloquea el push para proteger el código ajeno. La solución obligatoria es descargar (pull), integrar y volver a empujar.
! [rejected] main -> main (non-fast-forward)
error: failed to push some refs to 'github.com:org/repo.git'
hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., 'git pull ...') before pushing again. El ritual diario de sincronización en 5 pasos
Seguir esta rutina técnica al inicio y final de cada jornada de desarrollo evita el 95% de los conflictos y desincronizaciones en equipos de software.
Bajar cambios antes de tocar nada
Comienza tu día actualizando main con los cambios que tus compañeros integraron mientras descansabas.
git switch main
git pull Crea una rama específica
Nunca desarrolles directamente sobre main. Aísla tu objetivo en una rama feature bien nombrada.
git switch -c feat/user-auth Commits pequeños y frecuentes
No acumules 5 días de trabajo en un único commit gigante. Haz commits atómicos y testeables.
git add -p
git commit -m "feat(auth): validate token" Publica con upstream tracking
Publica tu rama en el repositorio remoto configurando el seguimiento con la bandera -u.
git push -u origin feat/user-auth Abre el Pull Request para revisión del equipo
En GitHub, crea el PR hacia main, describe el contexto, enlaza el ticket o issue correspondiente y espera la aprobación de CI/CD.