Git Usage Rules (Branching, Merging) - bounswe/2021SpringGroup12 GitHub Wiki

With our team divided into 3 subteams, we should set up a few rules in the repo so that those 3 subteams and each individual can work on the same repo in coherence.

The persistent branch structure consists of 7 branches (Master, android/dev, android/main, frontend/dev, frontend/main, backend/dev, backend/main).

The master branch is for general repo and should be used for big milestones and stable releases of all subteams. The code here is approved by all subteams thus the versions of subteams work coherently with each other.

• The code in master branch shall be stable all the times.
• The changes to this branch can be done using a pull request from one of the subteam/main branches. Except the situations where a team independent change must be made, in that case a branch should be created based on the master and should be merged back into master with a pull request.
• The pull requests for this branch should be approved by at least 3 people from 3 different teams before merge.

These branches are for each team to have their stable releases. The code here may not be working coherently with another teams code yet because it is only approved in-subteam. But this is the latest stable release of a subteam thus it can be used by other teams for testing.

• When a team needs to use another teams code, this is the branch they should be able to use.
• Changes to these branches can be done using a pull request from the dev branch of the related team.
• Pull requests for this branch must be approved by all of the subteam members before merge.

This is the ongoing development branch that is collective to the subteam. Most of the prs will be merged into this branch thus it may not be always stable. As other in-subteam members keep using the code in here, it will be slowly tested and fixed.

• These branches are for development cycles and should only be used by the related teams members.
• Any new feature should be implemented on a new branch based on this branch and then should be merged into this branch using a pr.
• Pull requests for this branch must be approved by at least 1 other subteam member before merge.
• When the subteam decides a new stable version is reached, a new pr should be created to merge this branch into subteam/main

This is the ongoing development branch for each feature. Once the implementation is done, a pr should be opened to merge this branch into subteam/dev.

• should be concise and should contain information about the feature to be implemented.
• This branch should be based on 'subteam/dev'.
• When the owner decides it is ready for review, they should create a pr from this branch into the dev branch.