Branching And Merging Strategies

Branching Strategy and Naming Conventions

When branching, sprint branches must be branched from master while individual or bug branches must be branched from their respective sprint branches.

Sprint Branches

Sprint branches hold the latest implementations of all features decided in a sprint. Name the following format: sprint_[sprint#]

Individual Sprint Branches

Individual sprint branches hold the implementations of all features an individual is responsible for. Name the following format: sprint_[sprint#]_[individual_name]

Bug Branches

Bug branches hold the fixes or patches for a specific bug addressed in an issue. Name the following format: sprint_[sprint#]_[issue#]

Merging Strategies

At the end of a sprint, all features implemented held in individual branches or all bug fixes held in bug branches for that sprint will be merged into the sprint branches. All the features and bug fixes must be tested thoroughly before merging. Each individual responsible for an individual or bug branch will submit a pull request to the sprint branch. The team will code-review the changes and provide feedback for further technical improvement. When members feel that the changes are acceptable, they will approve the pull request. When a pull request is approved by all participated members, the individual or bug branch could be merged safely into the sprint branch, and the pull request will be closed.

Warning:

• DO NOT merge when others haven't approved your changes.
• When attempting to merge others' branches into your branch, you must ask for permission from the person responsible for that branch, and merge locally when approved. DO NOT merge on GitHub because others' branches will be affected.