I'm modifying an open-source project that's stored in an SVN repo. Since my changes will likely take a while to complete, I've checked the project out as a Git repo using the git-svn bridge. I don't have access to the project's Subversion repo so I can't push changes back to it, but I'd like to publish my Git repo (on GitHub) so others can track development of my modifications.
To update a "git svn" repo, you use git svn rebase
, which, as the name suggests, rebases any changes on top of the new changes from the Subversion repo. Of course, it's not a good idea to push any branches you've rebased into a public Git repo, so in regards to a repo cloned from an SVN repository, I have a couple of related questions:
git-svn rebase
) to a public repo?git svn dcommit
). If you adhere to this policy, is it okay to publish the rebased master branch to a public repo?It is safe to publish an SVN branch, but only if all commits are pushed to the SVN repo using git-svn dcommit
. If you have no changes in the branch, then git-svn rebase
will just do a fast forward.
If someone branches from the your published branch, it's important that they know that it is from an SVN repo. That's because if you ever try to accept their changes, the only way to push them into the SVN repo is by essentially rebasing their changes. After you publish the committed changes again, they will have to deal with the conflicting commits, since the hash will not match.
It's safe to work in master
, but probably not practical. From above, you can't publish your commits until you run git-svn dcommit
. So if you have any work you don't want to commit, you will need to move it to a separate branch before trying to publish the latest SVN commits (i.e. git-svn rebase; git push
)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With