This is not a blog about what version control software to use, there are many out there and all do mostly the same job. Version Control (VC) systems allow developers to keep ‘versions’ of code and to allow the sharing of code within a team.
The most common VC System today is GIT which can be web based, using GIT Hub or used locally on each developers machines and code shared that way. I personally use GIT with “remotes” on my home server so I can share my code between my development PC and my laptop.
My vote for a good Configuration Management / VC structure is based on many years of Delivery and Configuration Management experience and is the concept of branches or streams.
Release Branch
This is the branch that will eventually become your product. All Integration or Bug Fixing branches come off this one branch, we call the branch the One Truth. This branch is formally tested before release to the customer. I won’t say tested by people as it is now common to have Continuous Delivery (CD) set up in many organisations. I have no experience, as of yet, of the reliability of CD so will shy away from discussing this at the moment.
Integration Branch
The Integration Branch is base lined from the Release Branch. This branch is used as the basis for development, the developers will take a branch from this and perform development on their own branch. This branch can be re-based against the Release Branch to pick up any bug fixes that have been applied to it and as a natural activity by the developers when they rebase from the Integration Branch they will pick up the bug fixes in their code. The Integration Branch is delivered to the Release Branch when formal testing has passed, as an aside I find the best Integration Testers, if doing it manually, are developers and not a dedicated “test only” team.
The purpose of Integration testing is to ensure that things fit together and don’t break. I have worked on projects where they only ever test the success path through all delivery phases, except the unit testing, of a product and didn’t attempt to enter invalid values in their test scripts or even pull a network cable, and they wondered why they had so many defects raised by the customer …..
Defect Fixing Branch
This is basically the same as the integration branch but used purely for defect fixing.
Development / Defect Branches
These are the branches where the actual development takes place. Developers do their work, test it, rebase from the Integration / Defect Fixing Branch and then deliver the code to the Integration / Defect Fixing Branches. I have purposely stayed away from specific terms as in pull, push etc as they could mean differing things on different VC systems.
There are variations on this theme but if I was to start a project from scratch I would ensure something very similar to this was in place before any development work started.
Android Stuff 