Introduction

When a new branch appears in Subversion after your initial git svn clone, Git does not always discover it automatically. The fix is usually to make sure your svn-remote configuration includes the branch path pattern, then run git svn fetch again so the new SVN branch is imported into your Git metadata.

Check the git svn Branch Mapping

The first thing to inspect is .git/config. A git svn repository stores its SVN layout under an svn-remote section. If the branches setting already uses a wildcard, newly created SVN branches can usually be fetched without any extra setup.

1[svn-remote "svn"]
2    url = https://svn.example.com/project
3    fetch = trunk:refs/remotes/trunk
4    branches = branches/*:refs/remotes/*
5    tags = tags/*:refs/remotes/tags/*

The important line is the wildcard mapping. It tells git svn how to translate any branch under the SVN branches directory into a corresponding remote ref in Git. If your config only names one specific branch, new SVN branches will remain invisible until you update that mapping.

Fetch the New SVN Branch

Once the mapping is correct, fetch again:

git svn fetch
git branch -r

After the fetch completes, the new branch should appear in the remote branch list. If SVN created branches/release-2.0, you will typically see a corresponding remote ref such as release-2.0 or remotes/release-2.0, depending on how the repository was configured.

To start working on it locally, create a Git branch that tracks the imported SVN ref:

git checkout -b release-2.0 remotes/release-2.0

That gives you a normal local branch while preserving the git svn link to the underlying SVN history.

Handle Repositories with Nonstandard Layouts

Some SVN repositories do not use the usual trunk, branches, and tags layout. In those cases, the fix is still the same in principle, but the exact path pattern changes. For example, if branches live under project/active-branches, your config needs to reflect that exact directory.

You can update the config manually and fetch again:

git config svn-remote.svn.branches 'project/active-branches/*:refs/remotes/*'
git svn fetch

Be precise with the path. git svn is not guessing the branch layout from the server each time. It relies on the patterns stored locally. If the path is wrong, fetch may succeed but still skip the new branch because nothing matched.

If only one new SVN branch matters and you do not want a wide wildcard, you can map that branch explicitly. That is less flexible, but sometimes useful in legacy repositories where the branch tree is messy or enormous.

Common Pitfalls

One common mistake is assuming git fetch and git svn fetch are interchangeable. They are not. git fetch talks to Git remotes, while git svn fetch talks to the Subversion server and updates the imported refs.

Another problem is forgetting to inspect .git/config. If the branches line is missing or too narrow, no amount of repeated fetching will reveal the new SVN branch.

Branch names can also be confusing once they are imported. The ref name visible in Git comes from the mapping you configured, not from some universal default. Always confirm the actual remote ref name with git branch -r before creating a local branch.

Finally, be careful when editing the svn-remote settings in an established repository. Changing mappings after a lot of history has already been imported can make the remote ref layout harder to reason about. Make a small, deliberate change and fetch again.

Summary

• 'git svn learns about new SVN branches from the svn-remote mapping in .git/config.'
• A wildcard such as branches/*:refs/remotes/* usually lets git svn fetch import later-created branches.
• Use git svn fetch, not plain git fetch, to pull new refs from Subversion.
• Confirm the imported branch name with git branch -r before checking it out locally.
• Nonstandard SVN layouts work too, but the path mapping must match the repository exactly.