Recently we have finished migration of all our Java projects from SVN to GIT. Why have we done it?
#1 Merging
First of all, let’s talk about one of the most important aspects of all version control systems – merging. In case you work in a project with at least two developers you probably merge your code every single day. And what is merging? Merging is a method of creating conflicts. And a conflict is a natural artifact of programming together. This is something you cannot be scared of. No matter how good your VCS is, when two developers edit the same line in the same file, you will end up with a conflict. And since I’m using GIT, I’m not afraid of conflicts anymore. In my experience I have much less conflicts with GIT than I had with SVN – especially the ones connected with moving and renaming files. It’s also much easier to revert the merge without losing your local changes in case it’s necessary. The main reason for that is that you can easily commit local changes before merging with a public branch.
#2 Branching
Branching in GIT is much easier and faster. What is more, branches do not have to be public, which can completely change the way you use your VCS (and the way you write your code). When I worked with SVN I didn’t like branching. And I wasn’t alone. Everyone seems to dislike this operation. Creating a branch was slow and comparing branches was extremely slow. And at the end you had to merge. With every team I worked with we had a couple of rules regarding branching:
- branch only if necessary
- do not refactor code while on a branch
- do not move files
- under no circumstances can you rename folders
The main reason to follow the rules was to avoid tree conflicts. Obviously, the last three rules are useful for every VCS, but breaking them in GIT doesn’t create as many problems as compared to SVN.
#3 Local changes
Another big advantage of using GIT is handling local changes. You can create multiple local branches without publishing them. You can compare different versions even if you don’t have access to the Internet. You can also rebase not published branches in order to polish them as much as necessary before making them public. Just remember not to rebase the code that went public already.
#4 Speed
One cannot compare GIT with SVN and skip the speed factor. It’s obvious that doing the work on your local machine is often faster than sending the data to public server and waiting for the results. As GIT does most of its work locally, you can experience great speed which doesn’t limit your work. Do you want to compare branches between each other? A few seconds and you are done. Would you like to work on multiple branches simultaneously and switch between them every couple of minutes? No problem, every switch will also take no more than a few seconds. Would you like to try the same thing with SVN? Absolutely not. With GIT you can do things that you would never consider doing with SVN. And it’s not only about working locally versus working with remote servers. GIT has been designed to work fast and it does.
#5 Tools
There are a lot of different ways to use GIT. It possible to use command line tools, GUI tools or both at the same time. Command line is the most fundamental aspect of GIT and it’s recommended that everybody should know the basics. It also has a great code completion, so it’s very easy to navigate through your repository. If you are using Windows, make sure to use GIT Bash (included in the default installation).
Apart from command line you can find integrated tools for different IDE’s (Intellij or Eclipse) or external graphical tools (like SourceTree). They are especially useful during code comparison.
#6 Public repositories
Another important aspect of choosing VCS is the popularity and quality of hosting solutions. Even though at Goyello we use internal GIT repositories, the availability of public repositories is extremely useful. You can store some open source projects and small private projects there or pay for premium services. Some of the most popular are GitHub and Bitbucket. Both of them have a great support for GIT and can provide a great service in case you don’t have your own infrastructure.
#7 Git Branching Models
Because merging and branching is so easy you can use different branching models to organize work of your team. Developers can create a branch for every feature, release phase or they can mix different approaches. They can also use a hierarchical approach where only a few senior developers can commit to a master branch while reviewing code from less experienced peers in other branches.
A great description of a few possible flows is available in the link below:
https://www.atlassian.com/git/tutorials/comparing-workflows
Be well-prepared!
Since we started using GIT, we don’t see any reason for using SVN anymore. Despite the fact that different teams use different flows and tools, everybody is much more satisfied and productive than before. In case you are considering the migration I would like to add a few pointers to help you out.
Make sure everybody in the team has a basic knowledge of GIT. They don’t have to be experts, but they have to understand the difference between staging, committing and pushing. Developers should also be able to differentiate between local and public branches. GIT is a little bit more complex than SVN, but don’t be discouraged by that fact. Create some sample project in your team and play with it for a few days.
There is a great free e-book available online which I highly recommend:
https://git-scm.com/book/en/v2. You can also check some great tutorials, like this one:
https://www.youtube.com/watch?v=ZDR433b0HJY.
There are online tools which can migrate your SVN repository to GIT repository. Check them out and run the migration for test purposes. Check if it worked and if tags are available. Play with your project in GIT repository and make sure you know how to do everything you did with SVN. And when you are ready, run the migration once again and disable SVN repository (or change it to read only). Schedule this operation with every team member.
Don’t be afraid of a command line. GIT has a great command line and it’s very useful to know the basics. You don’t have to use it every time, but you certainly should know the syntax of most common operations. Personally I use my IDE for committing files and for displaying differences, but for other operations I usually use Git Bash.
Have fun and increase your productivity!
1 comment
Comments are closed.