分支说明和对应的操作
master分支
Git主分支的名字，默认叫做master。它是自动建立的，版本库初始化以后，默认就是在主分支在进行开发。
主分支，永远处于稳定状态，对应当前线上版本。
以tag标记一个版本，因此在master分支上看到的每一个tag都应该对应一个线上版本。
-
不允许在该分支直接提交代码。
示意图
dev分支
开发分支，包含了项目最新的功能和代码，所有开发都依赖dev分支进行。
可以用来生成代码的最新隔夜版本（nightly）。如果想正式对外发布，就在master分支上，对dev分支进行"合并"（merge）。
小的改动可以直接在dev分支进行，改动较多时应该切出新的feature分支进行。
注：更好的做法是dev分支作为开发的主分支，也不允许直接提交代码。小改动也应该以feature分支提merge request合并，目的是保证每个改动都经过了强制代码review，降低代码风险。暂时不启用这个方式。
Git创建dev分支的命令：
git checkout -b dev master
将dev分支发布到master分支的命令：
# 切换到Master分支
git checkout master
# 对dev分支进行合并
git merge --no-ff dev
--no-ff参数：默认情况下，Git执行"快进式合并"（fast-farward merge），会直接将Master分支指向Develop分支。
使用--no-ff参数后，会执行正常合并，在Master分支上生成一个新节点。
feature分支
功能分支，开发新功能的分支。
开发新的功能或者改动较大的调整，从develop分支切换出feature分支，分支名称为feature-xxx。
开发完成后合并回develop分支并且删除该feature-xxx分支。
功能分支的名字，可以采用feature-*的形式命名。
创建一个功能分支：
git checkout -b feature-x dev
开发完成后，将功能分支合并到dev分支：
git checkout dev
git merge --no-ff feature-xxx
删除feature分支：
git branch -d feature-xxx
release分支
发布分支，新功能合并到dev分支，准备发布新版本时使用的分支。预发布分支是从dev分支上面分出来的，预发布结束以后，必须合并进dev和master分支。
当dev分支完成功能合并和部分bug fix，准备发布新版本时，切出一个release分支，来做发布前的准备，分支名约定为release-*。
发布之前发现的bug就直接在这个分支上修复，确定准备发版本就合并到master分支，完成发布，同时合并到dev分支。
创建一个预发布分支：
git checkout -b release-1.2 dev
确认没有问题后，合并到master分支：
git checkout master
git merge --no-ff release-1.2
# 对合并生成的新节点，做一个标签
git tag -a 1.2
再合并到dev分支：
git checkout dev
git merge --no-ff release-1.2
最后，删除预发布分支：
git branch -d release-1.2
fixbug分支，紧急修复bug分支
紧急修复线上bug分支
当线上版本出现bug时，从master分支切出一个fixbug-分支，完成bug修复，然后将fixbug-合并到master和dev分支(如果此时存在release分支，则应该合并到release分支)，合并完成后删除该fixbug-*分支。
注意：以上就是在项目中应该出现的分支以及每个分支功能的说明。其中稳定长期存在的分支只有master和dev分支，别的分支在完成对应的使命之后都会合并到这两个分支然后被删除。
创建一个修补bug分支：
git checkout -b fixbug-0.1 master
修补结束后，合并到master分支：
git checkout master
git merge --no-ff fixbug-0.1
git tag -a 0.1.1
再合并到develop分支：
git checkout develop
git merge --no-ff fixbug-0.1
最后，删除"修补bug分支"：
git branch -d fixbug-0.1
总结：
- master: 线上稳定版本分支。
- dev: 开发分支，衍生出feature分支和release分支。
- release: 发布分支，准备待发布版本的分支，存在多个，版本发布之后删除。
- feature: 功能分支，完成特定功能开发的分支，存在多个，功能合并之后删除。
- fixbug: 紧急热修复分支，存在多个，紧急版本发布之后删除。
项目中分支操作流程示例
1、切到dev分支，更新dev最新代码。
git checkout develop
git pull --rebase
2、新建feature分支，开发新功能
git checkout -b feature-xxx
git add
git commit -m "feat(xxx): commit a"
git commit -m "feat(xxx): commit b"
# 其他提交
如果此时dev分支有一笔提交，影响到你的feature开发，可以rebase dev分支，前提是该feature分支只有你自己一个在开发，如果多人都在该分支，需要进行协调：
# 切换到dev分支并更新dev分支代码
git checkout dev
git pull --rebase
# 切回 feature 分支
git checkout feature-xxx
git rebase develop
# 如果需要提交到远端，且之前已经提交到远端，此时需要强推(强推需慎重！)
git push --force
3、完成feature分支，合并到dev分支
# 切到dev分支，更新下代码
git check dev
git pull --rebase
# 合并feature分支
git merge feature-xxx --no-ff
# 删除feature分支
git branch -d feature-xxx
# 推到远端
git push origin dev
4、当某个版本所有的feature分支均合并到dev分支，就可以切出release分支，准备发布新版本，提交测试并进行bug fix
# 当前在dev分支
git checkout -b release-xxx
# 在 release-xxx 分支进行 bug fix
git commit -m "fix(xxx): xxxxx"
5、所有 bug 修复完成，准备发布新版本
# master分支合并release分支并添加tag
git checkout master
git merge --no-ff release-xxx --no-ff
# 添加版本标记，这里可以使用版本发布日期或者具体的版本号
git tag 1.0.0
# dev分支合并release分支
git checkout dev
git merge --no-ff release/xxx
# 删除 release 分支
git branch -d release/xxx
至此，一个新版本发布完成。
6、线上出现 bug，需要紧急发布修复版本
# 当前在master分支
git checkout master
# 切出fixbug分支
git checkout -b fixbug-xxx
... 进行bug fix提交
# master分支合并fixbug分支并添加tag(紧急版本)
git checkout master
git merge --no-ff hotfix/xxx --no-ff
# 添加版本标记，这里可以使用版本发布日期或者具体的版本号
git tag 1.0.1
# dev分支合并fixbug分支(如果此时存在release分支的话，应当合并到release分支)
git checkout develop
git merge --no-ff fixbug-xxx
# 删除fixbug分支
git branch -d hotfix-xxx
至此，紧急版本发布完成。
提交信息规范
git commit 格式如下：
():
具体格式：
:
type: 本次commit的类型，诸如bugfix docs style等
scope: 本次 commit 波及的范围
subject: 简明扼要的阐述下本次 commit 的主旨，1.使用祈使句；2.首字母不要大写；3.结尾无需添加标点；
body: 同样使用祈使句，在主体内容中我们需要把本次commit详细的描述一下，比如此次变更的动机，如需换行，则使用 |
footer: 描述下与之关联的issue或break change
各个部分的说明如下：
- type 类型，提交的类别
- feat: 新功能
- fix: 修复 bug
- docs: 文档变动
- style: 格式调整，对代码实际运行没有改动，例如添加空行、格式化等
- refactor: bug 修复和添加新功能之外的代码改动
- perf: 提升性能的改动
- test: 添加或修正测试代码
- chore: 构建过程或辅助工具和库（如文档生成）的更改
- scope 修改范围
- 主要是这次修改涉及到的部分，简单概括，例如 login、iap、search
- subject 修改的描述
- 具体的修改描述信息
Commit messages格式要求
# 标题行：50个字符以内，描述主要变更内容
#
# 主体内容：更详细的说明文本，建议72个字符以内。 需要描述的信息包括:
#
# * 为什么这个变更是必须的? 它可能是用来修复一个bug，增加一个feature，提升性能、可靠性、稳定性等等
# * 他如何解决这个问题? 具体描述解决问题的步骤
# * 是否存在副作用、风险?
#
# 如果需要的化可以添加一个链接到issue地址或者其它文档
范例:
feat(home): 首页新功能
fix(login): 登录错误处理
test(search): 搜索逻辑添加测试代码
提交信息规范说明：
type + scope 能够控制每笔提交改动的文件尽可能少且集中，避免一次很多文件改动或者多个改动合成一笔。
subject 使用中文，方便检索和阅读。
避免重复的提交信息，如果发现上一笔提交没改完整，可以使用 git commit --amend 指令追加改动，尽量避免重复的提交信息。
分支之间操作的注意事项
- 同一分支git pull使用rebase
首先看一张图：
想从中看出一条清晰的提交线几乎是不可能的，充满了 Merge remote-tracking branch 'origin/xxx' into xxx 这样的提交记录，同时也将提交线弄成了交错纵横的图，没有了可读性。
这里最大的原因就是因为默认的 git pull 使用的是 merge 行为，当你更新代码时，如果本地存在未推送到远程的提交，就会产生一个这样的 merge 提交记录。因此在同一个分支上更新代码时推荐使用 git pull --rebase。
下面这张图展示了默认的 git pull 和 git pull --rebase 的结果差异，使用 git pull --rebase 目的是修整提交线图，使其形成一条直线。
默认的 git pull 行为是 merge，可以进行如下设置修改默认的 git pull 行为：
# 为某个分支单独设置，这里是设置 dev 分支
git config branch.dev.rebase true
# 全局设置，所有的分支 git pull 均使用 --rebase
git config --global pull.rebase true
git config --global branch.autoSetupRebase always
使用 git pull --rebase 操作是比较好的，能够得到一条很清晰的提交直线图，方便查看提交记录和 code review，但是由于 rebase 会改变提交历史，也存在一些不好的影响。
- 分支合并使用 --no-ff
# 例如当前在 develop 分支，需要合并 feature/xxx 分支
git merge --no-ff feature/xxx
--no-ff feature 含义：
先解释下Git中的fast-forward：举例来说，开发一直在dev分支进行，此时有个新功能需要开发，新建一个feature-a分支，并在其上进行一系列开发和提交。
当完成功能开发时，此时回到dev分支，此时develop分支在创建feature-a分支之后没有产生任何的commit，那么此时的合并就叫做fast-forward。
fast-forward 合并的结果如下图所示：
这种merge的结果就是一条直线了，无法明确看到切出一个新的feature分支，并完成了一个新的功能开发。
因此此时比较推荐使用git merge --no-ff，得到的结果就很明确知道，新的一系列提交是完成了一个新的功能，如果需要对这个功能进行code review，那么只需要检视叉的那条线上的提交即可。