Version control is perhaps one of the most helpful tools for collaborative software development. Think of it as being able to keep a history of every change made to the tracked code and for merging together separate features into a shared codebase.
It used to be a pain using Subversion or CVS—-that’s Concurrent Versions System, not the neighborhood drug store. As with most things in technology, the shortcomings encountered with Subversion and CVS resulted in other options to appear. Most of the other options lost market share with the race ultimately being won by Git.
What’s so great about Git is that not only is it super simple to use, but it is also a distributed version control system (DVCS) that was designed for collaboration amongst multiple software developers. This collaborative approach is an improvement over previous systems that forced code to be stored in separate silos intended for single developers. It’s no surprise that Git functions so well considering that it was created by Linus Torvalds, who just happens to be the creator and original developer of the Linux operating system. Git also isn’t restricted to software development only and can also support document version control for managing
Workflows
The concept of workflows in Git provide a structure for the underlying principles in using Git for custom software development.
At its core, developers utilize the master branch as the current released code that is found on production systems. This should be the most recent, stable release that serves as the basis for future development.
In addition to the master branch, a development branch will also exist. This development branch serves as the pipeline for features that are under development. For improved usage, specific features are developed on individual feature branches, which utilize a feature/ prefix for indicating that the respective branch contains code for a specific feature.
In some instances, a stage branch will also exist. The stage branch is intended to serve as a step between the current production version and the development branches by providing a branch for the compilation of new features and improvements. This branch can be though of as what’s ready for review. Assuming that everything is acceptable here, then the next step would be to schedule a production release where the master branch would be updated and the release version would be incremented respectively.
We utilize the approach as outlined above for all of our custom software development projects as we’ve found this model to be the most productive. We’re not constrained by working on one thing at a time and are able to deliver projects much quicker by allowing simultaneous development to occur. An added bonus is that developer onboarding is much simpler using this approach as well by being to bring in new developers that are able to begin contributing immediately without worrying about interrupting other developers.