Git-svn operation philosophy?
I have access to an svn repository at work but I’m going to start to work with a distributed team and I’d like to start to fire up git use on this project (as a pilot).
- Copy part of SVN repo to new repo?
- When using a DVCS in front of Subversion should I merge or rebase before pushing?
- After checking out a git branch, do remote FTP changes only affect branch or master too?
- Maven: Commit single artifact to svn repository
- SVN - Checksum mismatch while updating
- SubGit Synchronisation issue: error: svn: E175002: connection refused by server
2 Solutions collect form web for “Git-svn operation philosophy?”
Because svn doesn’t support the same range and style of branching/merging as git does, you will be limited as to how much of that you can do with the upstream repository. Locally however, it is just a normal git repository, so you can branch and merge and cherry-pick and rebase and everything else your heart desires.
The differences to worry about are interacting with upstream: rather than
git pull as you would normally use to update the changes, you’ll use
git svn rebase, and git will try to replay your local commits onto the remote HEAD, stopping along the way and letting you know about the conflicts you need to resolve, if any (rather than merging them, as is normal with pure git repositories). When you commit, you’ll use
git svn dcommit, which makes your local commits into a linear history and applies them to the upstream HEAD in svn.
To add to Matt Enright’s answer, consider also svn2git (and the reverse script
git2svn), in order to get a more git-like repository structure.
(i.e. try to not have the branches as directory, like they are in SVN)