Git Flow流程图
所有的项目都会有三个分支
- master: 面向运维发布的分支。作为主分支应该确保时刻处于可发布状态。
- demo: 面向演示的分支。与master分支平行。
- develop：面向开发者的主要分支。应确保该分支包含下次版本等待发布的所有内容。
发版前
- 当一个版本迭代周期进尾声后，QA开始检验develop分支。
- 测验过当前develop分支的内容是可发布状态后，所有的修改都应该merged into demo。
- QA发布Demo发版通知，发版人员在发布Demo后，QA再次检验Demo环境下各个功能是否正常。
- Demo环境确认无误后，所有Demo分支上的改动merge向master分支，并通知运维发布正式环境。
- master后打一个tag，tag名为当前发布版本+时间。 （1.0.0 2019-03-03）
所以每当有新代码被merge到master后，就意味着一个新的版本已经生成，下一步一定是发布。否则可能会出现的问题：某个代码已经merge到master上了，但没发布。其余功能全上了后，发现有一个相关功能出现问题。
建议使用自动发布脚本来完成这一系列的操作，避免人为操作的影响造成漏洞。
其他分支：
除了master和develop分支外，还需要其他的分支来支持日常开发以及对应的紧急修复等更复杂的情况。但这些分支都有一个共同的特性：他们都只有有限的生命周期，不像master或develop一样是永驻的。
大致分为以下几类：
Feature branches
Hotfix branches
Release branches
这些分支都有一个特定的目的，同时也有严格的merge规则。
Feature branches
特性分支(有时称为主题分支)用于为即将发布的或遥远的将来的版本开发新特性。当开始一个特性的开发时，包含这个特性的目标发行版很可能还不知道。特性分支的本质是，只要特性还在开发中，它就会存在，但是最终会被合并回develop中，或者被丢弃。
Feature作为开发者管理自身的功能点的迭代，一般不需要推向origin。
$ git checkout -b feature/article
规则：feature分支只能mergin到develop分支。
Finish feature
feature完成后需要删除该分支。
$ git checkout develop
$ git merge --no-ff myfeature
$ git branch -d myfeature
$ git push origin develop
--no-ff
--no-ff的作用是在merge分支的同时，把原先分支的提交记录一并合并到develop分支上。如果只是执行默认merge，则只会生成一条
Merge branch xxx of xxxx.com into xxx
Hotfix branches
- 当有紧急修复发生时，从master分支上checkout出hotfix分支。
$ git checkout -b hotfix/article - 修复完成后merge交由QA验证。验证通过后merge到master和develop分支。
- 删除当前hotfix分支。
提交规范
日常提交分为以下几种
feat: A new feature
fix: A bug fix
docs: Documentation-only changes
style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
refactor: A code change that neither fixes a bug nor adds a feature
perf: A code change that improves performance
test: Adding missing tests
chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
deps: Updates about dependencies
建议团队内引进
feat:
fix:
refactor:
deps:
