39

I am doing a development project.

The company is using SVN, so for main commit and checkout should be done via SVN.

However, I don't like SVN and am a git user. Since only when I think my code is good I will commit to the company SVN, I would like to use git for my own history keeper.

I don't need to use git to do SVN thing, nor vice versa.

Can I version control my same code using SVN and git at the same time? No interaction between them.

Jackson Tale
  • 25,428
  • 34
  • 149
  • 271
  • 4
    Just ignore the `.git` folder for SVN and the `.svn` folder for Git and you should be fine. Or are you asking how to basically push/pull from both at once? – Blender Oct 05 '12 at 08:21
  • But why? git works perfectly fine with a svn repository on the other side, why not benefit from that? – Benjamin Bannier Oct 05 '12 at 08:22
  • 5
    Certainly possible, and a fair move towards your colleagues, not to push unfinished changes. however there is one _huge_ danger hidden in there: you will tend to make very few commits to the companies repository. That means you will produce much more conflicts compared to your colleagues. When using subversion it makes sense to use a frequent commit behaviour. I had to learn that the hard way :-) – arkascha Oct 05 '12 at 08:27
  • 2
    It's the worst version-control practice! See http://www.codinghorror.com/blog/2008/08/check-in-early-check-in-often.html and http://stackoverflow.com/questions/107264/how-often-to-commit-changes-to-source-control – bahrep Oct 05 '12 at 10:30
  • 1
    Jeff Atwood: "Developers who work for long periods -- and by long I mean more than a day -- without checking anything into source control are setting themselves up for some serious integration headaches down the line." – bahrep Oct 05 '12 at 10:31

1 Answers1

43

You can clone a subversion repository to your machine using git svn clone <SVN repo URL>. The code will be available as a git repository. You can do your work there and make local commits as you please. There is a command line option to get a "shallow" checkout rather than the entire repository which is often useful. I forget what it is.

Anytime, you want to run the equivalent of svn update, do a git svn rebase. This will fetch new commits which were checked into SVN after you last synchronised and then rebase your changes onto the new tip.

When you're ready with your commits, do a git svn dcommit. This will send all your new commits to svn one by one. You can also squash your local commits into a single one and send it by first doing a local rebase and then an svn dcommit. This should be done on the initial branch (usually master).

The very fact that you're checking out from subversion and then working locally in git means that there is "interaction" between them so your last statement is not valid.

Noufal Ibrahim
  • 71,383
  • 13
  • 135
  • 169
  • 3
    There was an edit made to the answer which should have been posted as a comment. I've reverted the edit and posted the addition verbatim in this comment -- It's commonly considered as a bad practice to commit all your changes as a single revision (e.g. see http://stackoverflow.com/questions/107264/how-often-to-commit-changes-to-source-control and http://www.codinghorror.com/blog/2008/08/check-in-early-check-in-often.html). – Noufal Ibrahim Oct 05 '12 at 14:00
  • For shallow checkouts: `git svn clone -s -r1002:HEAD http://paul@svn.xxxxxx.com/repos/ -T trunk -b branches -t tags` where “1002” must be replaced with the earlier revision you want to keep. – Paul Sturm Apr 20 '18 at 16:45