Par Anonyme (non vérifié) , 29 avril 2026

Deux modèles, deux coûts

Les branches SVN sont des copies de répertoire dans le dépôt. La copie est bon marché sur le serveur, mais changer de branche implique le réseau. Les branches Git sont des pointeurs — une ref de 41 octets.

Commandes 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

Jusqu'à SVN 1.5 (2008), merger était un processus manuel. SVN 1.5+ a ajouté les propriétés svn:mergeinfo. Git suit nativement les merges dans le graphe de commits.

Merging en pratique

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

# Git merge feature de retour vers main
git checkout main
git merge feature

Résolution de conflits

Les deux systèmes utilisent un merge à trois voies et produisent des marqueurs de conflit.

Mergeing répété

Git gère trivialement "j'ai mergé depuis main la semaine dernière, qu'est-ce qui a changé ?".

Cherry-picking

# SVN
svn merge -c 12345 ^/trunk

# Git
git cherry-pick <sha>

Hygiène de branches

Comme les branches Git sont bon marché, les équipes les utilisent libéralement.

Visibilité

git log --graph --all rend tout le graphe en secondes. SVN ne visualise pas nativement les branches comme un DAG.

Là où SVN tient bon

  • Si votre stratégie est "trunk seulement avec branches release rares".
  • Le contrôle d'accès par répertoire de SVN.

Impact de la migration

Le plus grand changement culturel en passant de SVN à Git est le branching.