Introduction

SVN is not a native Git remote, so you cannot treat it like origin and run a normal git push. If you need to send work from an existing Git repository into Subversion, the usual bridge is git svn, which translates between Git commits and SVN revisions.

The important design choice is whether you need a one-time import of the current code or an ongoing bridge where Git commits continue to land in SVN. git svn is best for the second case, but it works most smoothly when the history you are sending is linear and the SVN repository already has a standard trunk, branches, and tags layout.

Prepare The SVN Repository Layout

Many SVN repositories use this structure:

trunk/
branches/
tags/

If the repository is new, create that layout first on the SVN side. Then connect your Git repository to the trunk path.

git svn init https://svn.example.com/project/trunk

If the repository already uses the standard layout, you can point git svn at the repository root and let it discover the structure:

git svn init --stdlayout https://svn.example.com/project

After initialization, fetch SVN metadata into the Git repository:

git svn fetch

That step matters because git svn needs to know how Git history maps to SVN revisions before you start sending commits back.

Rebase And Keep The Branch Linear

Before sending Git commits to SVN, make sure your branch is linear relative to the SVN tracking branch:

git svn rebase

Then inspect the history you plan to send:

git log --oneline --decorate --graph

This is where Git and SVN differ most. Git handles non-linear history naturally; SVN does not. git svn dcommit works best when the commits you are sending form a clean linear sequence.

Send Git Commits To SVN

Once the repository is initialized and rebased, use dcommit rather than push:

git svn dcommit

dcommit takes your local Git commits, converts them into SVN revisions, and updates the mapping metadata. After it completes, you should usually run another rebase to sync the Git side with the rewritten metadata:

git svn rebase

That extra sync step avoids confusion later, especially if other people are committing to the SVN repository directly.

One-Time Snapshot Import Versus Full History

If your real goal is only to put the current source tree into SVN, a snapshot import may be simpler than preserving Git history. The reason is that Git history and SVN history are structurally different. Trying to mirror a complex Git DAG into SVN can become messy quickly.

For an ongoing bridge, keep expectations realistic:

• merges may not round-trip cleanly
• tags are represented differently
• branch workflows need more discipline than in pure Git

If the organization expects SVN to become the long-term source of truth, it is usually better to adopt an SVN-compatible workflow early rather than continuing heavy Git-only branching patterns and hoping translation will remain painless.

Common Pitfalls

• Trying to use git push directly against an SVN URL.
• Running git svn dcommit on a branch with merge-heavy history that is not linearized.
• Forgetting to git svn rebase before and after dcommit.
• Assuming Git tags and SVN tags behave the same way.
• Treating git svn as a perfect two-way mirror rather than a compatibility bridge with tradeoffs.

Summary

• SVN is not a normal Git remote, so use git svn, not git push.
• Initialize against trunk or use --stdlayout for a standard SVN repository.
• Fetch and rebase before sending local commits.
• Use git svn dcommit to translate Git commits into SVN revisions.
• Keep history linear and expectations modest, because Git and SVN model history differently.