Archives de la catégorie Branching
How to manage our software branches to :
-understand when creating a new branch
-be sure to manage correctly bug fix for different deliveries
Trunk branch or X.Y.Z branch
trunk is the main software branch which have a robust version X.Y.Z with :
-X: represents the major version which indicates enough modifications to create a new Service package
-Y: represents the minor version which indicates little modifications
-Z: represents bug fixes version which indicates that after a release delivery, some roundtrip came to correct bugs
Service Pack branch or 1.Y.Z branch , 2.Y.Z branch and so on…
A new service pack branch is creating from the trunk branch when team project decides to deliver a major version of an application. This Service Pack branch will be used when we want to commit minor versions of our software application. When major modifications will be merged on the trunk from development branches, team project will create another Service Pack branch with an increment on X value (2.Y.Z).
Hot Fix branch or 1.0.Z branch , 1.1.Z branch and so on…
the hot fix branch(1.0.Z, 1.1.Z) is creating from our 1.Y.Z Service pack branch only when team project decide to deliver a release on production environment. this branch, for example 1.0.Z will contains all bug fix of the release 1.0.0 . So when team project deliver for the first time a version on production environment (called Release version 1.0.0), after few times, some bug will be discovered and team project will correct those bugs on Hot Fix branch (1.0.Z). if a major bug or many minor bug will be fixed, team project will deliver another release 1.0.1 which means :
1.0.0 + first bug fix modification = 1.0.1
Release branch or 1.0.0 branch, 1.0.1….2.0.0,2.01…
Release branch is a read-only branch that represent a delivery on production environment. So, each time, team project make a delivery on production environment, it will keep a « copy » branch (1.0.0 1.0.1 etc)
Development branch contain major modifications. They are created from trunk branch and are merged on the trunk after those major application modification are completed. Team project make this merge on the trunk only when they will decide to deliver those major modification, so team create also the service pack, hot fix and release branch
Branch Application Life Cycle Management
An example to understand. Team project decide to create a car seller application so they create those branch:
-a trunk branch and Service Pack branch called 1.Y.Z
After one month, team have a robust application and decide to make a delivery on production environment:
-a Hot Fix branch 1.0.Z and a Release branch called 1.0.0 are created
-a merge is done from 1.Y.Z Service Pack branch to Trunk
After few weeks some bug are detected :
-Team project correct them and commit all changes on 1.0.Z Hot Fix branch , 1.Y.Z Service Pack branch and X.Y.Z trunk branch after tests.
management decide to make a new delivery with those bug fix:
-a new 1.0.1 Release branch is created from 1.0.Z branch and is delivered on production environment.
another team work on home seller application which is a major modification of car seller application (we will sell cars and homes):
-a new Development branch is created from trunk and is called HomeSell
After two months, management decide to deliver the major modification to sell home:
-team project make a merge from « HomeSell » Development branch to Trunk and resolves all conflicts
-a new 2.Y.Z Service Pack Branch is created from trunk branch just merged.
-a new 2.0.Z Hot fix branch is created and also a read-only 2.0.0 Release branch is created and delivered on production environment
Points of Interest
with this software branch management, team project will understand when and how creating a branch.
first version – I will add a pictures to represent software branching