Migrate an SVN repository to Git with history

git svn can import SVN revisions into Git, but a successful migration needs more than a clone command. Map authors, inspect the SVN layout, decide how branches and tags should appear in Git, and validate the result before switching writers.

Prepare the source and author map

Confirm that git svn is installed; some Git distributions package it separately. Record the SVN URL, credentials mechanism, repository size, and whether the layout uses trunk, branches, and tags.

List author identities from structured SVN log output:

svn log --xml --quiet https://svn.example.com/project > svn-log.xml

Parse the XML to collect unique author names, then create a reviewed users.txt:

alice = Alice Example <alice@example.com>
bob = Bob Example <bob@example.com>

These are illustrative identities. Use the actual names and email addresses agreed for the migration. Avoid extracting authors by splitting human-readable log lines on spaces, and do not fabricate email addresses from usernames.

Import a standard layout

git svn clone https://svn.example.com/project \
  --stdlayout --prefix=svn/ --authors-file=users.txt project-git
cd project-git
git branch --all
git log --oneline --decorate -10

For a custom layout, configure --trunk, --branches, and --tags to match it. The explicit prefix makes imported tracking refs easier to recognize, such as refs/remotes/svn/trunk and refs/remotes/svn/tags/v1.0.

Keep the default git-svn-id metadata during an incremental migration. Using --no-metadata removes information needed for normal revision mapping and later synchronization; it is not a harmless cleanup option for a repository you still intend to fetch or commit through git svn.

Large histories can take substantial time depending on revision count, network access, and content. If an author is missing, update the map and resume with git svn fetch after inspecting the error.

Create the intended Git refs

Inspect the current local branch and confirm it represents trunk before renaming it:

git branch --show-current
git log --oneline HEAD -5
# After confirming this is the intended trunk branch:
git branch -m main

Convert selected imported refs explicitly:

git branch release-1 refs/remotes/svn/release-1
git tag v1.0 refs/remotes/svn/tags/v1.0

Use names that actually exist in your import. SVN tags are directories and can have subsequent modifications; decide which revision each Git tag should represent. This example creates a lightweight Git tag, not an annotated tag carrying new release metadata. Review deleted historical branches and tags separately rather than assuming the current layout exposes every historical ref.

Validate and cut over

Compare important release trees, authors, dates, and representative file histories. SVN merge tracking does not automatically become an equivalent Git merge graph. Empty directories, svn:externals, properties, and large external artifacts also need explicit migration decisions.

git svn show-ignore > .gitignore can provide a starting point for ignore rules. Inspect the generated patterns and test them before committing; SVN properties and Git ignore semantics are not identical.

During a staged migration, fetch additional SVN revisions. At final cutover, stop SVN writes, fetch again, and update the intended local branches. For a trunk branch with no local Git-only commits, git svn rebase can incorporate the latest trunk revisions; inspect all other branch and tag mappings separately.

Add the new Git remote and push only the approved refs:

git remote add origin git@example.com:team/project.git
git push -u origin main
# Publish these only if they were reviewed and created above:
git push origin release-1 refs/tags/v1.0

Keep SVN read-only until the team has validated the Git workflow and backups. Tools such as svn2git or reposurgeon can support more specialized conversions, but still require a rehearsed mapping and validation plan.

See git-svn and Subversion's repository history documentation.