关于分支分类
主分支
- master 分支，存储官方发布历史，始终都是稳定状态。
- develop 分支，作为功能集成历史的分支。
辅助分支
- feature 分支，一个功能特性的开发分支。
- release 分支，进行测试发布。
- hotfix 分支，快速修复 master 分支的 bug。
分支的生命周期
master 分支与 develop 分支与项目的生命周期共存亡
feature 分支
- feature 分支，当开始一个新特性的开发时，从 develop 检出 feature 分支。feature 分支的本质特性处于开发阶段，它就会存在，将来会被合并会 develop 分支。
# 创建 feature 分支
$ git checkout -b myfeature develop
Switched to a new branch “myfeature”
# 当完成 feature 分支开发后，合并到 develop 分支，以将它们添加到即将发布的版本中
$ git checkout develop
Switched to branch 'develop'
# 将 feature 合并到 develop 分支
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
# 删除 feature 分支
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
# 提交到远程
$ git push origin develop
release 分支
- release 分支，release 分支是为发布新的产品版本而设计的。当 develop 分支上的代码已经包含了所有即将发布的版本的软件功能，并且可以发布测试环境时，我们就可以考虑创建 release 分支了。在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息（版本号、编译时间等等）。通过在 release 分支上进行这些工作可以让 develop 分支空闲出来以接受新的 feature 分支上的代码提交，进入新的开发迭代周期。所有在当前即将发布的版本之外的业务需求一定要确保不能混到 release 分支之内。在这个新的分支可能会存在一段时间，直到发布。 在此期间，可以在此分支做一些小的错误修复，但不能添加大的新特性。
# release 分支从 develop 分支检出
$ git checkout -b release-1.0 develop
Switched to a new branch "release-1.0"
$ git commit -a -m "version number to 1.0"
- 当 release 分支测试通过并准备发布时，需要执行一些操作。 首先，release 分支被合并 master 分支（每往 master 提交一次，就是一个新的版本）。 同时，对 master 的提交必须打 tag，以便将来找到这个历史版本。 最后，release 分支所做的更改需要重新合并到 develop 分支，这样将来的版本也包含这些错误修复。
# 合并到 master，并打 tag
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.0
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.0
# 保存 release 分支所做的更改，需要把 release 分支合并回develop 分支
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff release-1.0
Merge made by recursive.
(Summary of changes)
# 完成后，可以删除 release 分支了
$ git branch -d release-1.0
Deleted branch release-1.0 (was ff452ee).
关于 tag 版本号的说明：
主版本号.次版本号.修订号。
版本号递增规则如下：
主版本号：做了不兼容的 API 修改
次版本号：做了向下兼容的功能性新增
修订号：做了向下兼容的 bug 修正
hotfix 分支
- 当生产环境上出现了严重的 bug，需要立即修复的时候，就需要从 master 分支上指定的 tag 版本派生 hotfix 分支来进行紧急修复工作。这样做是不会打断正在进行的 develop 分支的开发工作，能够保障新特性的开发与紧急修复 bug 的工作同时开展。
# hotfix 分支从 master 检出
$ git checkout -b hotfix-1.0.1 master
Switched to a new branch "hotfix-1.0.1"
$ git commit -a -m "version number to 1.0.1"
# 修改 bug
$ git commit -m "Fixed production bug"
# 当完成修复，hotfix 分支需要合并到 master，也要合并到 develop 分支，以便下个版本也包含这次修复。
# 合并到 master 并打 tag
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff hotfix-1.0.1
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.0.1
# 合并到 develop 分支(如果此时存在 release 分支时，就需要将 hotfix 分支合并到 release 分支，而不是 develop 分支。其实当 release 分支完成的时候，这次修复也就被合并到 develop 分支了。)
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff hotfix-1.0.1
Merge made by recursive.
(Summary of changes)
# 最后，删除这个 hotfix 分支
$ git branch -d hotfix-1.0.1
分支命名规范
最好是以分支的类型为前缀进行命名，如：feature-* 、release-* 、or hotfix-*
总结
- feature 分支，从 develop 分支检出，必须合并回 develop 分支。
- release 分支，从 develop 分支检出，必须合并回 develop 分支和 master 分支。
- hotfix 分支，从 master 分支检出，必须合并回 develop 分支和 master 分支。
特殊处理
可能遇到的问题：同时进行多个 feature 分支开发时，怎么保障每个分支的代码是安全可靠？
解决方案：
- 首先一个规则是：feature 分支，从 develop 分支检出，必须合并回 develop 分支。
- 如果这时 develop 已经有人提交了另外一个已经完成的 feature1 分支，此时的 develop 分支的代码并没有经过测试，也不确定什么时候能发布生产环境。但这时又有新的需求进行开发（不用等上一个 feature1 分支上线），按规则也要从 develop 分支上检出一个新的 feature2 分支。
- 这种情况下，需要用 git revert 命令，将 develop 分支回滚到上一次 release 或 hotfix 分支 merge 到 develop 的版本，这样就可以保障 develop 分支上的代码与 master 上的代码一致，并且是安全可靠的。这时再用 git checkout -b feature2 develop 创建 feature2 分支。
- 最后，再将 develop 分支恢复到上一个 feature1 提交的版本。
另外，可以参考一下 https://blog.csdn.net/yxlshk/article/details/79944535 这里介绍的两种回滚日志的区别。
