Introduction

Yes, git svn dcommit after ordinary Git merging can be dangerous if you do not understand how git-svn maps Git history back into Subversion. Git supports non-linear history with merge commits, while SVN expects a linear series of revisions. git svn dcommit therefore replays your Git commits into SVN in a flattened form, and that can produce confusing history or surprising results if your branch contains merges.

Why the Risk Exists

A Git repository is a directed acyclic graph of commits. A Subversion branch is effectively a linear revision history. git svn dcommit takes the commits on your current Git branch that have not yet been pushed to SVN and commits them one by one to the SVN side.

That means git svn dcommit does not preserve Git's merge structure in the way a Git remote would. A merge commit is not magically represented as an SVN merge with the same semantics. Instead, git-svn tries to linearize the history.

This is why a branch history that is completely normal in pure Git can become awkward when dcommit is involved.

What Goes Wrong After Merging

Suppose you do this:

git checkout master
git merge feature-branch
git svn dcommit

If feature-branch introduced commits through an ordinary Git merge, several things can happen:

• the merge commit itself may not translate cleanly
• the commit order replayed to SVN may differ from the mental model you had in Git
• after dcommit, local Git history can be rewritten relative to the SVN-tracking branch
• teammates using git-svn can get confused if they merged differently

The biggest conceptual problem is that Git merges record branching structure, while dcommit wants a clean linear patch series.

The Safer Workflow: Rebase, Then dcommit

The usual git-svn advice is to keep the branch you dcommit from linear. In practice, that means rebasing your work on top of the latest SVN state instead of merging into it.

A safer flow looks like this:

1git svn rebase
2git checkout my-work-branch
3git rebase remotes/trunk
4git checkout master
5git merge --ff-only my-work-branch
6git svn dcommit

Or, more simply, work on a feature branch and rebase it before dcommitting from the integration branch.

The key idea is that the branch you dcommit should look like a clean straight line of commits.

Why git svn rebase Matters

Before dcommit, you should almost always synchronize with the latest SVN revisions using:

git svn rebase

This fetches the latest SVN changes and rebases your local Git work on top of them. That reduces the chance of replaying commits onto an outdated SVN state.

Using git pull or a normal Git merge on a git-svn branch is usually the wrong instinct. git-svn workflows are built around rebasing rather than merge-heavy integration.

Feature Branches Are Still Fine

You can still use local Git feature branches productively with git-svn. The safe pattern is:

• do whatever local branching you want
• before integration back to the SVN-bound branch, rebase and linearize
• only dcommit a branch with clean, ordered commits

If a feature branch has messy merge history, you can clean it up with interactive rebase or cherry-pick the relevant commits onto a fresh linear branch.

git checkout -b dcommit-ready remotes/trunk
git cherry-pick abc123 def456 ghi789
git svn dcommit

That is often clearer than trying to force a complicated merge history through SVN.

What Happens After dcommit

Another important detail is that git svn dcommit can effectively rewrite how your local Git history relates to the SVN-tracking branch. After dcommitting, it is common to reset or rebase local branches to line up with the new SVN-backed commit sequence.

So even when nothing goes wrong semantically, dcommit is not a normal Git push. Treat it as a translation step, not as a native Git remote operation.

Common Pitfalls

The most common mistake is treating git svn dcommit like git push and assuming merge commits will be preserved naturally. They will not.

Another mistake is merging from remotes/trunk into a working branch when git svn rebase was the right synchronization step.

Developers also often keep a messy local history and only think about linearization at the last second. With git-svn, the dcommit branch should be kept clean intentionally.

Finally, do not forget to inspect the branch before dcommitting. If git log --graph --oneline shows a complex merge topology, stop and clean it up first.

Summary

• 'git svn dcommit after normal Git merging can be risky because SVN expects linear history.'
• 'dcommit replays commits rather than preserving Git merge structure.'
• Keep the branch you dcommit from linear by using git svn rebase and ordinary rebasing.
• Local feature branches are fine, but clean them up before dcommit.
• Treat git svn dcommit as a translation to SVN, not as a normal Git push.