Git básico para quien viene de SVN

Si has trabajado con SVN durante años, seguramente sabes usarlo con soltura, pero cada vez es más frecuente encontrarte con proyectos, tutoriales o compañeros que solo hablan en Git. La buena noticia: no es empezar de cero. Los conceptos son parecidos, pero Git añade una pieza que SVN no tiene: cada copia local es un repositorio completo, no solo una «copia de trabajo».

En este artículo vemos Git básico para quien viene de SVN: la diferencia conceptual clave, y los comandos equivalentes a los que ya usas a diario.

La diferencia clave: centralizado vs distribuido

SVN es centralizado: hay un único servidor con el historial completo, y tu copia local solo tiene la versión actual de los archivos. Cada commit viaja directo al servidor.

Git es distribuido: cuando haces git clone, te descargas el repositorio entero, con todo su historial. Puedes hacer commits, crear ramas y ver el historial completo sin conexión a internet. Solo necesitas red para sincronizar con el servidor remoto (push / pull).

Esto tiene una consecuencia práctica importante: en Git, «guardar cambios» son dos pasos, no uno. Primero confirmas los cambios en tu repositorio local (commit), y luego, cuando quieras, los subes al servidor (push). En SVN esos dos pasos son uno solo.

Tabla de equivalencias SVN → Git

Quiero hacer esto	En SVN	En Git
Descargar el proyecto	`svn checkout url`	`git clone url`
Traer los cambios del servidor	`svn update`	`git pull`
Guardar cambios localmente	—	`git add .` + `git commit -m "mensaje"`
Subir cambios al servidor	`svn commit -m "mensaje"`	`git push`
Ver el historial	`svn log`	`git log`
Deshacer cambios no guardados	`svn revert archivo`	`git checkout -- archivo`
Ver qué ha cambiado	`svn diff`	`git diff`
Crear una rama	`svn copy trunk branches/x`	`git branch x`
Cambiar de rama	`svn switch`	`git checkout x`

El concepto nuevo: el área de preparación (staging)

Esto es lo que más despista al llegar de SVN. Antes de hacer commit, Git tiene un paso intermedio llamado staging area (o índice): eliges exactamente qué cambios entran en el próximo commit, incluso si has modificado diez archivos y solo quieres confirmar cambios en tres.

git add archivo1.php archivo2.php   # solo estos dos entran en el commit
git status                          # ver qué está en staging y qué no
git commit -m "Corrige validación del formulario"Lenguaje del código: PHP (php)

Si quieres el equivalente más parecido a «confirmar todo lo modificado», como haces en SVN:

git add .
git commit -m "mensaje del commit"Lenguaje del código: JavaScript (javascript)

Ramas: la gran diferencia práctica

En SVN, crear una rama es literalmente copiar una carpeta dentro del repositorio (branches/), y suele ser una operación que pesa y que evitas hacer a la ligera. En Git, las ramas son baratísimas: son solo un puntero a un commit, se crean en un segundo y es normal crear una rama nueva para cada tarea pequeña.

git branch nueva-funcionalidad        # crear la rama
git checkout nueva-funcionalidad      # cambiar a ella
git checkout -b nueva-funcionalidad   # crear y cambiar en un solo paso

git checkout main                     # volver a la rama principal
git merge nueva-funcionalidad         # traer los cambios de la rama a mainLenguaje del código: PHP (php)

Un primer flujo de trabajo completo

git clone https://github.com/usuario/proyecto.git
cd proyecto

git checkout -b arreglo-bug-login

# ... editas archivos ...

git add .
git commit -m "Arregla el bug de sesión duplicada en el login"

git push origin arreglo-bug-loginLenguaje del código: PHP (php)

Ese último push sube tu rama al servidor remoto (GitHub, GitLab o Bitbucket, por ejemplo). Desde ahí, lo habitual es abrir un Pull Request (o Merge Request en GitLab): una propuesta para que alguien revise tus cambios antes de fusionarlos a la rama principal. Es el equivalente moderno a pedir una revisión antes de un svn commit directo a trunk.

El archivo .gitignore

Al igual que SVN tiene svn:ignore, Git usa un archivo de texto plano llamado .gitignore en la raíz del proyecto para excluir archivos que no quieres versionar (carpetas de dependencias, archivos de configuración local, logs…):

/vendor/
/node_modules/
.env
*.logLenguaje del código: JavaScript (javascript)

Buenas prácticas para empezar

Haz commits pequeños y frecuentes, con mensajes claros — igual que en SVN, pero aquí es gratis (no dependen del servidor).
Usa git status constantemente: te dice exactamente en qué punto estás.
Crea una rama para cada tarea, por pequeña que sea. Es barato y evita mezclar cambios sin relación.
Haz git pull antes de empezar a trabajar cada día, igual que harías svn update.
No hace falta dominar rebase ni comandos avanzados el primer día: con clone, add, commit, push, pull y branch ya puedes trabajar con soltura.