Welcome back to the dissection lab! This week let us travel into the realm of Source, taste the fruits of repository branching and have a cup of wisdom. If you’re ever developing software you must use some sort of version control system, otherwise known as source code management.
Source Code Management
SCM is a means of allowing easy collaboration on a project, a whole group of developers can work together towards a common goal. Version-ing protects changes to the source code facilitating easy reverts and guards against hard drive failure. There are two varieties of SCM, client-server and distributed.
The client-server model uses a server as a single repository for source code. A developer would synchronise to that single repository in order to make changes, very simple pulling, pushing. The distributed model has a central server but every developer has a local copy of that repository on their HDD. An example of each are Subversion and Git, each with certain advantages and disadvantages.
SVN follows the client-server model. It is very easy to learn as at a basic level all you need to do is checkout the repository, make a change and commit it. A team of developers can pick it up very quickly with just 3 commands and anything more advanced (branching) can be incorporated on the fly. Unfortunately due to the centralised nature of SVN it requires network access. So if you’re on the move and don’t have internet access you cannot make any changes. On the plus though newbies can pick up SVN with a really good GUI, TortoiseSVN.
Git is the absolute boss when it comes to SCM. The commands are a little more in-depth and there are more of them than SVN, with quite unfriendly error messages, but it allows development anywhere. If you had a server at home and a laptop on the road you would be able to continue working as you’d have a local copy of the repository; when you regain network access you can push your local changes to the server for the entire team. Additionally every development machine becomes a local backup of the repository, protecting against server failure. In general Git is faster than SVN anyway, it was built for the Linux kernel and can easily scale up to hundreds of developers, although as you’re checking out the entire repository you could be waiting on a long download. It’s a little unfriendly and the GUI is awful, to use Git you’ve just got to make the command line plunge (cmd is just better anyway).
Branching and Merging Strategy
No matter what SCM tool you go for it is best to follow some standard practices and properly manage the repository. Disasters can occur when developers are working on the same files concurrently, to counter this branching can be utilised. Branches are copies of the repository, within the repository, effectively a duplicate which allows work to be separated out. The generic idea is to preserve a master branch on the repository, this branch has passed integration tests and can be passed on to release. All development happens separate from this branch and can possibly occur across many branches depending on the nature of coding.
For instance, take a master branch at version at 1.0.0, a new feature for the product will have a feature branch created and designated as 1.1.0, while a hotfix to the master may be designated 1.0.1. During development once a branch has been completed and tested it is merged into the master, rebranding the master as that version. If the above hotfix is incorporated before the feature were completed then the new master would be merged into the feature to keep it up to date. An illustration is perhaps the best way to go:
This is quite rudimentary and it can get more complicated if you have even more future feature branches, but as a starting platform it’s quite nice. Ideally for long term development the features and hotfixes should be periodically merged into the master anyway (at the end of sprints), this defeats conflicts early. So now this removes some of the pain with parallel development and enables easy tracking of new features and hotfixes.
Thanks for reading, tune in next time for a breakdown of Issue Tracking with JIRA!