Git Team Development Process Specification

For multi-person collaborative programming in a team, Git repository management needs to have specifications. The following are the specifications used by my team.

Continuously updated

Branch Naming Rules

1. Main branch: master [Protected branch]
2. Feature branch: feat/<name>
3. Bug fix branch: fix/<name>

Operation Steps

1. Create corresponding branch based on master

2. Develop locally using git add, git commit, etc., push to remote repository, creating corresponding upstream branch.

   Note: Use syntax sugar like fixed #issueNum in commit messages to associate issues. This way, when MR succeeds, the issue will automatically close, making it easier to track which code submission relates to which ticket

3. CI service pulls target branch code for building, runs in internal environment, confirms OK

4. Merge master code, if there are differences then handle with rebase merge, and re-validate functionality

5. Initiate MR to master

6. Administrator reviews, if there are modification points then develop corresponding modifications, and submit labeled as fixup:xxxx

7. After confirmation OK, merge into master, delete original branch

8. CI service pulls master main branch code for building, deploys to production, and creates tag markers

9. If BUGs are encountered in production, immediately rollback during the release process, and repeat the above process in the repo to fix as soon as possible.

Explanation

• Since branches are created locally by each developer and eventually pushed upstream, naming according to the above rules prevents branch naming conflicts
• Build releases automatically collect statistics on all submission modification points, so accurately filling out commit-message descriptions is particularly important