Two models, two costs

SVN branches are directory copies in the repository. The copy is cheap on the server (a metadata operation), but switching branches involves the network and a working-copy update. Git branches are pointers - a 41-byte ref. Creating, switching, and deleting branches is instantaneous and offline.

Branching commands

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

# Git
git checkout -b feature
git switch feature

Merge tracking

Until SVN 1.5 (2008), merging was a manual process - track which revisions had been merged, supply them explicitly. SVN 1.5+ added svn:mergeinfo properties that record what has been merged. It works, but the property-based model has edge cases that surprise users.

Git tracks merges natively in the commit graph. A merge commit has multiple parents; Git uses three-way merge against the merge base, which is computed from the graph itself. The model is simpler and more robust at scale.

Merging in practice

# SVN merge feature back to trunk
svn switch ^/trunk
svn merge ^/branches/feature
svn commit -m "Merge feature"

# Git merge feature back to main
git checkout main
git merge feature

Conflict resolution

Both systems use three-way merge and produce conflict markers. Tooling differs: Git's git mergetool integrates with kdiff3, Beyond Compare, vimdiff, and many others. SVN supports tools too, but the integration story is older and less polished.

Repeated merging

Git handles "I merged from main last week, what changed since?" trivially - the merge base advances, and the next merge picks up only what is new. SVN required svnmerge.py tools before 1.5, and even with svn:mergeinfo, repeatedly merging between branches occasionally produces tricky conflicts that are easier to redo than to resolve.

Cherry-picking

# SVN
svn merge -c 12345 ^/trunk

# Git
git cherry-pick <sha>

Both support it. SVN's svn:mergeinfo tracks cherry-picks; if you later merge the source branch in full, SVN knows not to reapply the cherry-picked revisions. Git relies on patch-id heuristics; the same merge often skips already-cherry-picked content but not always.

Branch hygiene

Because Git branches are cheap, teams use them liberally - feature branches, hotfix branches, throwaway experiments. SVN branches, costing a server-side copy and a working-copy switch, encourage longer-lived branches and discourage casual experimentation.

Visibility

Git's git log --graph --all renders the entire branch and merge graph in seconds. SVN does not natively visualise branches as a DAG - they are directories, and tools have to reconstruct the graph from copy/merge metadata. Tools exist, but the experience is less first-class.

Where SVN holds its own

• If your branching strategy is "trunk only with rare release branches", the difference vanishes.
• SVN's per-directory access control means branches under branches/secret/ can be hidden from most users - harder to do in Git.

Migration impact

The biggest cultural shift in moving from SVN to Git is branching. Teams that branched once a quarter in SVN often branch dozens of times a day in Git. Plan training around this, not around the command differences.