Migrating from SVN to Git version control - Part 2

Your own private GitHub

mr sh
Credit: GitLab

In the first part of this series on migrating from SVN to Git I talked about the reasons why we decided to make the switch. Now I'd like to talk about how you can migrate an existing project under SVN to Git while retaining its history, and about the web server we're using to collaborate with Git.

If you decided to make the switch too, there's a point where you're going to want to migrate in your existing projects into your shiny new Git server. One simple way to do this is to just export your code from SVN (which gives you the code without the .svn directories) and load it into a fresh Git repository as the initial commit. The problem here however is that you lose all of your commit history from SVN. If that's not a concern, you can do that and it will work just fine, but in most cases the history is important.

Luckily, the Git tools include an SVN migration component that can make the process fairly painless. The exact steps are going to depend on your environment a little and how you're hosting Git but here are some good resources which describe the process in depth:

Migrate an SVN Project to GitLab

For us, we are using an excellent Git server called GitLab. It's very polished and gives you many of the features you'd expect from GitHub, all for free! It's like your own privately hosted GitHub really. Migrating from our SVN repository to GitLab required only a few commands:

1) Clone the SVN project

If you don't care about tags and branches you can run

git svn clone https://path.to.your.svn.repo/myProject

If you do care and you have the standard SVN layout of /TRUNK /TAGS /BRANCHES you can run

git svn clone --stdlayout --no-metadata https://path.to.your.svn.repo/myProject myProject.git-svn

Or if you care and you have a non-standard layout, you can specify each path name

git svn clone --trunk my-trunk --branches my-branches --tags my-tags https://path.to.your.svn.repo/myProject myProject.git-svn

This might take a while as Git pulls down all of the revision history for your project but once it's done you'll have a local repo with all of your history ready to be pushed up to GitLab.

2) Add your GitLab repo as a remote origin

Move into your new folder where you cloned the SVN project (cd myProject.git-svn) then run the following command to add a remote origin linking your GitLab repo to this local repo:

git remote add master yourgitlabuser@your.gitlab.url.com:groupname/project-name.git

replacing yourgitlabuser with your actual username and your.gitlab.url.com:groupname/project-name.git with the web address of your gitlab server followed by the path to your repo.

3) Push the project into Git

Finally, push your local repository with all of the SVN history up to GitLab.

git push --set-upstream gitlab master

And that's it!

GitLab

Git is cool and all, but if you can only use it on your local machine it's not super useful for team collaboration and software development. To open up Git for a team environment you're going to want to run a Git web server which will become the "public" repository even though you'll probably keep it private. To do this we are using GitLab which our newest hire turned us on to as he had been using it for a previous project. It's fantastic. We're using the self hosted and free community edition which was exactly what we were looking for (self hosted that is). 

activity stream full GitLab

Installation is a breeze if you're able to set up a new server for the purpose, in our case a VM, as GitLab provides an omnibus package that will install and configure the whole ball of wax for you.

It took like 15 minutes before we had our own GitHub, seriously. 

GitLab gives you a ton of features including:

  • File Browser
  • Code Viewer
  • Issue Tracker
  • Project Wikis
  • Merge Requests
  • Activity Streams
  • Commit Graphing
  • WebHooks and Integrations
snippets full GitLab

It's been working really well for us, I definitely recommend checking it out. As a bonus it integrates with Slack which our company switched to back in August 2014. Before this integration, you'd routinely hear a developer shout out "COMMITTING!" to make other devs aware, followed by "UPDATING!". Now whenever a git push comes through, the commit along with the comments and details are instantly posted to our #GitLab channel and everyone knows. No more shouting. 

We've Migrated

It's been 1 month today since we switched over and there is definitely no looking back. We had a short period of confusion and relearning in the first week or two but now things are humming along and we're loving it. The Git flow branching strategy is working well, we've settled into our tools (mostly git command line or posh git), reflog'd our way out of a few mistakes, and we're back to focusing on development proper. We're still using Git as a centralized repository like SVN but it feels much more current and modern than SVN did, mostly thanks to GitLab I think. 

ITWorld DealPost: The best in tech deals and discounts.
Shop Tech Products at Amazon