Source code control is key to an effective team. Having multiple experienced developers in your team will also result in some developers working on different issues, some of which will take some more time to develop. And with the current frantic release pressures in the software factory and the risks involved in building new features you will have different developers work on different branches.
Don’t waste time having developers sit on their hands, just branch and code on! Therefore, branching is cool. Now if you use your source code control system to the full extent like we do, then as a teamlead you will eventually end up having to inform the team about all the branching and merging that goes on.
That’s ok, but how to communicate this effectively to your team? You might try to do that by simply sending an e-mail. Like this..
Hi all,
Kees volunteered to merge the 2.7.3 code changes (including the last 2.7.2 hotfix C changes that are in there) to the trunk. When that is finished, AND the trunk build is GREEN, only then we will create a 2.7.4 branch for the database-split. Meanwhile Henk also fixed a hot-issue on 2.7.3, which is then also to be merged to trunk (2.7.4 if it is there). And now that we are on STAGING with 2.7.3, All the fixes for 2.7.3 that will be needed are then also to be merged to both trunk / 2.7.4. Only if the 2.7.4 branch has been created, Gundi is allowed to change the trunk with all the experiences he has from the 2.8 Refactor branch, not sooner….
Thanks,
Melle
Teamlead
Well if your team of Kees, Henk and Gundi grasp these kinds of quick e-mail notes all praise to your team but it might be better if you take the time to draw a nice diagram with that.
Click on image for a redrawing of this image.
Now be honest: this is much clearer then the email, right?
The above example was used in our SVN based repository, but visibility is universal. You can use it both for a centralized based repository (CVS) like subversion and a decentralized/distributed version control system (DVCS) like Git. Have a look at another beautiful explanation of the git-branching model here. Visibility shows.
Making branching visible to your organisation
As developers we know what branching involves. We are so close to the code that we know from the top of our heads what functionality is in what branch-number. Sometimes developers even know what detailed issue-numbers are (not) in what branch. That’s all cool but we are writing the software for the entire organisation, our clients, not only ourselves. To make branching visible to your organisation it is vital to use clear names for your branches. Not in the version control system, but in the communication. That way it will be clear what functionality a certain branch contains. As an example:
- 2.7.2 hotfix C – CreditCard Entry
- 2.7.3 LowCost
- 2.7.4 database split
As you see, we try to attach a name with the version number that marketing and brand managers might will understand. Especially when a release to live is done the announcement of “2.7.3 is live!” will be too cryptic. “2.7.3 LowCost is live!” at least denotes the functional meaning of the release. Of course, releases often contain more then just one new item or fix. That means that it might be hard to come up with a proper name for a certain release; just pick the main feature in that case.
More links about branching:
Swapping release dates and thus swapping whole API changes is cumbersome. Martin Fowler has already written a very nice no-FeatureBranch article about that.