branch description
master branch
The master branch is only deployed online. Every time a new function is verified in the test environment, it can be merged into the master branch. Make sure that the master branch is the latest code online.
develop branch
For deployment to an integrated test environment.
feat/xxx branch
The naming rule is: feat/{version}-{feature point}. The feature branch is pulled based on the latest master branch, and merged with the development branch after development. Then go to the test environment.
hotfix/xxx branch
For online bugs, it can only be cut from the latest master branch.
The basic principle
- Basic feature branch development + MR workflow
- A global master branch, which is an online stable branch
- The develop branch cannot be merged into the master branch or the hotfix/* branch, otherwise it will pollute the master and hotfix
- As a stable branch, master can be merged into other branches at any time
- Avoid including changes across multiple functional modules in a commit. The commit granularity is subject to revert. A commit only does one thing, which can save a lot of trouble when revert is required
- In theory, any branch can be merged with the most stable master branch at any time, but usually there are no bug fixes that must be merged, or online features that must be merged, and there is no need to deliberately merge the master during development and before the mr, and lagging behind the target branch will not bring Code conflicts, on the contrary, improper resolution of conflicts will pollute the currently developed feature branch, and then pollute every downstream branch that is merged and imported by the branch.
example
Requirements iteration
- During development,
cut out a new function branch based on the latest master, named feat/1.2-new-card. Develop normally - submit - When testing,
push your own feat branch to the remote, submit MR and merge it into the development branch, and conduct CodeReview during the test. Deploy to the test environment after passing.
Notice:
- It is forbidden to push code directly to the develop branch.
- Make sure that the test environment includes all functions online.
- If there is a problem during the testing
, fix it on your own feat branch, push it to the remote after completion, and merge it into the development branch by raising the MR. - Go online
Rebase or merge the latest master branch on the feat branch, resolve possible conflicts, and push it to the remote, raise the MR and merge it to the master branch, and conduct CodeReview (the review at this time is mainly to resolve conflicts). Ready to go live after the merge is complete.
BugFix
- Test environment: Fix directly on the feat branch, and then submit MR to the develop branch.
- Online environment: fork the hotfix/xxx branch from the master branch, merge it into the develop branch after solving the problem, and directly merge it back to the master branch after passing the verification.
MR conflict
- If there is a conflict when the feature branch is submitted to the master branch, then merge or rebase the latest master branch from your own branch, and push again after the conflict is resolved.
- If there is a conflict when the feature branch is submitted to the development branch, you can try to merge it experimentally in the local target branch to see whose code conflicts with it, find relevant people, and analyze the cause of the conflict together.
- If it is a conflict with the master branch. For example, feature/1.2-new-card mentions mr to the develop branch, indicating that there is a conflict. One possible reason is that develop has merged the latest master branch, while feature/1.2-new-card conflicts with the master branch, resulting in There is a conflict with mr this time, so in this case, the conflict with develop can be resolved indirectly by merging the latest master through feature/order.
- If not, it is necessary to manually cut the branch from the target branch (usually the develop branch), merge the source branch to resolve the conflict, submit it to the remote, and then submit the MR to the bata branch.
- Therefore, even if the feature branch needs to be merged with the master, it should happen after the MR is raised, and the commit that merges the master must be the latest one in the commits list of the MR. It is very convenient to use reset --hard to roll back (if MR has been merged).
Commit message writing specification
Generally, the conventional submission specification recommended by commitlint is used , and the format of the message is checked during pre-commit. Those that do not conform to the specification will not be submitted successfully.
other references
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow