Branching makes developer’s life easier
I have recently been working on one of our new projects, and I needed to have my own copy of our system with full functionality. The changes made by me would affect the whole system so my workmates couldn’t work on their features then.
Although every respectful development company uses version control systems, typically every change is made to main repository – then every developer can be up to date and they can work on the same project. But sometimes – as in my case – your changes are going too deep to work on the same repository. Here branching comes in. It is used globally in any version control system. It allows you to create branches that are (depends on system) independent copies of HEAD (or another branch) created from one particular commit in main repository.
Branches allow you to work on your own copy of the project, making changes and then merging it with root repository branch (HEAD or master, depends on system). What are the pros of using this – let’s call it – subsystem? Let’s imagine a situation, where you are developing a new product and all of the work is committed to main repo. Then you find a bug that needs to be applied immediately on – technically speaking – production server. What can you do then? If it is important, you may go to production files system and risk de-synchronisation while you are changing your files obeying the versioning system. Otherwise you can do it the “good” way. If you are developing a new product or a new functionality – create a branch on a certain commit???. Then you can make changes, remove old code etc while your main “path” is still fully functioning. Let’s get back to our problem. If we need to correct that bug we can make a branch, then correct this bug, merge it with main repository branch and push it into production. You can even change the branch you’ve created to be your main HEAD if your changes are so big and you are sure that you all changes have been applied by your colleagues (i.e. you’ve changed about 70% of main classes in your system and merging the code could be too difficult or you are just releasing version 1.0 of your product).
That was just a simple explanation what branching really is in technical terms. What are my feelings about this system? I started working with system versioning in December last year, when I needed to control code version of my private project. Very quickly I came to the point where I needed separate copies of my project to develop 2 tasks at once. First task was bug-fixing oriented and the second one was just a new design of application itself. At that time I had 3 branches (HEAD, bug-fix, new-design). HEAD was just main application, the same version as the one on the production server and those 2 branches I had created were to accomplish this 2 tasks. I fixed bugs very quickly and merged it with main repository and then pushed it into production server without messing up with the rest of repository and without revealing my new features to application users.
In summary, I can recommend you to start using branches (if you haven’t started using it yet). Even big repositories with a lot of collaborators can be reorganised to use branches. And it will bring more positive results that you can even imagine. But if you are new to versioning, and you want (and you should!) to dive into it, I would recommend you to start with Git versioning system. It is an easy to learn, worldwide used system with a lot of community support (i.e. check out what GitHub has to offer for you). For starters I would recommend GitinOneHour by Scott Chacon. Additionally you should definitely check out Getting Good With Git by Andrew Burgess. Both resources will introduce you to basic and more advanced uses of control versioning. After you start working with git, repositories and branches you will ask yourself several times“Why wasn’t I using it before?” and you will work faster and more efficiently.
If I have convinced you to give it a try, take a look at this tutorial video:
Image source: GitGuru.com
