## Team development branch naming strategy
1. master：
The main branch is responsible for recording the iteration of the online version, and the code of this branch is completely consistent with the online code.
2. develop：
The development branch, which records relatively stable releases, from which all feature branches and bugfix branches are created.
Other branches are short-term branches, which need to be deleted after functional development is completed
3. feature/*：
The feature (function) branch is used to develop new functions. Different functions create different function branches. After the development of the function branch is completed and the self-test is passed, it needs to be merged into the develop branch and then deleted.
4. bugfix/*：
The bug fix branch is used to fix non-urgent bugs. For common bugs, you need to create a bugfix branch for development. After the development completes the self-test and no problems, it is merged into the develop branch, and the branch is deleted.
5. release/*：
The release branch is used for code launch preparation. This branch is created from the develop branch. After creation, the test classmates release it to the test environment for testing. If bugs are found during the testing process, developers need to fix bugs on the release branch. After all bugs are fixed , before going online, you need to merge the release branch into the master branch and the develop branch.
6. hotfix/*：
Emergency bug repair branch. This branch is only used in emergencies. It is created from the master branch to urgently repair online bugs. After the repair is completed, the branch needs to be merged into the master branch to go online, and then merged into the develop branch.
## Team development process
##Comment Guidelines (Git Commit Guidelines.)
```
<type>(<scope>): <subject>
<empty line>
<body>
<empty line>
<footer>
```
The above is the message format specification after a Commit, which is divided into three parts: title, content details, and end, each with its own purpose and no redundant items.
The header is the first line, which can be previewed directly on the page. As shown in the figure above, there are three parts <type>, <scope>, <subject>, and the meanings are as follows
1. Type
- feat: new feature (feature)
- fix: fix bugs
- docs: documentation
- style: Format (changes that do not affect code execution)
- refactor: refactoring (that is, not a new feature, nor a code change that fixes a bug)
- test: add test
- chore: changes to the build process or auxiliary tools
2. Scope
It is used to describe the scope of the impact of this Commit, that is, a brief description of the parts that will be involved in the revision. This was originally an optional item, but it can be seen from the actual AngularJS project that it has basically become a required item.
3. Subject
It is used to briefly describe this change, but an overview is fine, because specific information will be given in the Body later. And it's best to follow these three rules:
- Start with a verb, use the first-person present tense, such as change, not changed or changes
- Do not capitalize the first letter
- do not end with a period (.)
4. Body
The content in <body> is an expansion of the content in the subject above. It is described in more detail here. The content should include the motivation for modification and the comparison before and after modification.
5. Footer
The main place in the footer is to place `incompatible changes` and `Issue close` information, refer to the following two examples
## Summarize
* All new function development and bug fixes (non-urgent) must be pulled from the develop branch for development, and the development will be merged into the develop branch without any problems after self-testing
* The release branch is released to the test environment, and the developer creates the release branch (requires the tester) and publishes it to the test environment. If a bug is found during the test, the developer needs to track the release branch to fix the bug, and the tester is required before going online. Submit the merge request to the master branch, ready to go online, and need to be merged back to the develop branch.
* The hotfix branch is only allowed to be pulled from the master in an emergency. The hotfix branch needs to be merged into the develop and master branches at the same time (two merge operations in total)
* Except for the master and develop branches, other branches must be deleted after development is completed
## Appendix:
* [R&D Team GIT Development Process Newbie Learning Guide](https://aicode.cc/yan-fa-tuan-duigit-kai-fa-liu-cheng-xin-ren-xue-xi.html)
* [Common skills of Git study notes](https://aicode.cc/git-xue-xi-bi-ji-zhi-chang-yong-ji-qiao.html)
* [Git study notes branch management](https://aicode.cc/git-xue-xi-bi-ji-zhi-fen-zhi-guan-li.html)
* [git-flow cheat sheet](http://danielkummer.github.io/git-flow-cheatsheet/index.zh_CN.html)
* [Git practice in team](http://www.open-open.com/lib/view/open1461324562769.html)
* [Git Best Practices in Teams--How to Use Git Flow Correctly](http://www.open-open.com/lib/view/open1451353135339.html)
* [Git: teach you how to have something to say when committing](http://www.open-open.com/lib/view/open1461324865908.html)
* [Use git rebase to avoid unnecessary merges](http://www.open-open.com/lib/view/open1461325157318.html)