# FINN's Migration from Subversion to Git: Workflow and Productivity Benefits

DevFeed: [FINN's Migration from Subversion to Git: Workflow and Productivity Benefits](<https://devfeed.tech/articles/given-the-git-31973.md>)

Original publisher: [Read original article](<https://tech.finn.no2013/03/20/given-the-git/>)

Author: mick

Published: 2013-03-20T11:14:08Z

Content type: opinion

Language: en

Sources: [Finn.no](<https://devfeed.tech/sources/finn-no.md>)

Topics: [Git](<https://devfeed.tech/topics/git.md>), [CI/CD](<https://devfeed.tech/topics/cicd.md>), [Programming](<https://devfeed.tech/topics/programming.md>)

Tags: [coding](<https://devfeed.tech/tags/coding.md>), [commit](<https://devfeed.tech/tags/commit.md>), [continuous-deployment](<https://devfeed.tech/tags/continuous-deployment.md>), [developers](<https://devfeed.tech/tags/developers.md>), [docs](<https://devfeed.tech/tags/docs.md>), [git](<https://devfeed.tech/tags/git.md>), [pair-programming](<https://devfeed.tech/tags/pair-programming.md>), [programming](<https://devfeed.tech/tags/programming.md>), [repositories](<https://devfeed.tech/tags/repositories.md>), [review](<https://devfeed.tech/tags/review.md>), [stable](<https://devfeed.tech/tags/stable.md>), [tests](<https://devfeed.tech/tags/tests.md>)

## AI overview

FINN describes its migration from Subversion to Git, focusing on peer review, private repositories, branching, and individual productivity. The article also explains using feature branches with squashed or rebased changesets to support cleaner history and continuous deployment.

## Source excerpt

"There is no way to do CVS right." - Linus FINN is migrating from subversion to the ever trendy git. We've waited years for it to happen, here we'll try to highlight why and how we are doing it. Working together There's no doubt that git gives us a cleaner way of working on top of each other. Wherever you promote peer review you need a way of working with changesets from one computer to the next without having to commit to and via the trunk where everyone is affected. Creating custom branches comes with too much (real or perceived) overhead, so the approach at best falls to throwing patches around. Coming away from a pair-programming session it's better when developers go back to their own desk with such a patch so they can work on it a bit more and finish it properly with tests, docs, and a healthy dose of clean coding. It properly entitles them as the author rather than appearing as if someone else took over and committed their work. Git's decentralisation of repositories provides the cleaner way by replacing these patches with private repositories and its easy to use branches. Individual productivity Git improves the individual's productivity with benefits of stashing, squashing, reseting, and rebasing. A number of programmers for a number of years were already on the bandwagon using git-svn against our subversion repositories. This was real proof of the benefits, given the headaches of git-svn (can't move files and renaming files gives corrupted repositories) With Git, work is encouraged to be done on feature branches and merged in to master as complete (squashed/rebased) changesets with clean and summarised commit messages. This improves efforts towards continuous deployment due to a more stable HEAD. Rolling back any individual feature regardless of its age is a far more manageable task. By squashing all those checkpoint commits we typically make we get more meaningful, contextual, and accurate commit messages. Reading isolated and complete changesets provides