Dos modelos, dos costos

Los branches de SVN son copias de directorio en el repositorio. La copia es barata en el servidor, pero cambiar de branch implica la red. Los branches de Git son punteros — una ref de 41 bytes.

Comandos de branching

# SVN
svn copy ^/trunk ^/branches/feature -m "Create feature branch"
svn switch ^/branches/feature

# Git
git checkout -b feature
git switch feature

Tracking de merges

Hasta SVN 1.5 (2008), el merging era un proceso manual. SVN 1.5+ añadió propiedades svn:mergeinfo. Git rastrea merges nativamente en el grafo de commits.

Mergeando en la práctica

# SVN merge feature de vuelta a trunk
svn switch ^/trunk
svn merge ^/branches/feature
svn commit -m "Merge feature"

# Git merge feature de vuelta a main
git checkout main
git merge feature

Resolución de conflictos

Ambos sistemas usan merge de tres vías y producen marcadores de conflicto.

Mergeo repetido

Git maneja "mergee desde main la semana pasada, ¿qué cambió?" trivialmente.

Cherry-picking

# SVN
svn merge -c 12345 ^/trunk

# Git
git cherry-pick <sha>

Higiene de branches

Como los branches de Git son baratos, los equipos los usan liberalmente.

Visibilidad

git log --graph --all renderiza el grafo entero en segundos. SVN no visualiza nativamente branches como un DAG.

Donde SVN se mantiene

• Si tu estrategia de branching es "solo trunk con branches release raras".
• El control de acceso por directorio de SVN.

Impacto de la migración

El cambio cultural más grande al migrar de SVN a Git es el branching. Equipos que branchean una vez al trimestre en SVN suelen branchear docenas de veces al día en Git.