在实际项目中，我们通常使用如下图所示的分支进行版本间的管理和控制：
1. master: 主分支，主要用来版本发布。
2. develop: 日常开发分支，该分支正常保存了开发的最新代码。
3. feature: 具体的功能开发分支，只与 develop 分支交互。
4. release: release分支可以认为是master 分支的未测试版。比如说某一期的功能全部开发完成，那么就将 develop 分支
合并到 release 分支，测试没有问题并且到了发布日期就合并到master 分支，进行发布。
5. hotfix：线上 bug 修复分支。
场景 一 : 现在有dev本地分支与远程分支，master本地分支与远程分支，现在需要将dev的分支代码合并到master主干上（此类场景通常用于简单的开发，其弊端在于develop分支只有发布完了才能进行下一个版本开发，开发会比较缓慢。）:
思路步骤 :
1.切换到本地分支dev上，并且pull拉取一下远程dev分支上的改动地方（git pull origin dev）
2.将所有本地修改进行commit并且push到远程dev分支上，保证没有遗漏的，确保当前本地dev与远程dev是一致的
(git push origin dev)
3.将当前本地分支切换到本地master上(git checkout master)
4.将本地分支dev合并到本地master上，需要注意的是在进行merge(合并)的时候需要禁用fast-forward模式
(git merge --no-ff -m "message" dev)）
5.将本地已经合并了dev分支的master进行push到远程master上 (git push origin master)。
场景二 ：在开发过程中（即在dev分支中），需要多个功能模块进行开发，并且每一个功能模块都是独立的，此时可以使用feature分支（feature分支是基于dev分支的，需要合并到dev分支）：
思路步骤 :
1.从dev分支上建立一个feature分支，并切换到该分支进行开发（git checkout -b myfeature develop）
2.开发完成后，提交修改文件到本地仓库暂存区（git add . 然后 git commit -m "message"）
3.将feature分支合并到develop分支（先切回dev分支：git checkout dev 然后：git merge --no-ff -m "message" myfeature ）
3.合并完成后需要删除此feature分支(git branch -d myfeature)
4.将本地分支dev分支push到远程dev分支 (git push origin dev）
场景 三 ：在开发工作基本完成后，我们需要进行版本构建以及系统化测试，此时则需要用到release分支，release分支可以理解为是pre-master，即待发版本。(release分支是基于dev分支的，需要合并到主分支和dev分支)：
思路步骤 :
1.从dev分支上建立一个release分支，并切换到该分支进行开发（git checkout -b release-1.2 develop）
2.开发完成后，提交修改文件到本地仓库暂存区。（git add . 然后 git commit -m "message"）
3.将release分支合并到develop分支（先切回dev分支：git checkout dev 然后：git merge --no-ff -m "message" release-1.2 ）
4.将release分支合并到master分支（先切回master分支：git checkout master然后：git merge --no-ff -m "message" release-1.2 ）
5.合并完成后需要删除此release分支(git branch -d release-1.2)
6.将本地分支dev、master分支push到远程dev、master分支 (git push origin dev和git push origin master）
场景 四：在版本发布后，出现紧急线上bug需要及时修复时，则需要用到 hotfix 分支（hotfix 分支是基于master分支的，需要合并到主分支和dev分支）
思路步骤 :
1.从master分支上建立一个hotfix分支，并切换到该分支进行开发（git checkout -b hotfix-1.2.1 master）
2.开发完成后，提交修改文件到本地仓库暂存区。 （git add . 然后 git commit -m "message"）
3.将hotfix分支合并到develop分支（先切回dev分支：git checkout dev 然后：git merge --no-ff -m "message" hotfix-1.2.1）
4.将hotfix分支合并到master分支（先切回master分支：git checkout master然后：git merge --no-ff -m "message" hotfix-1.2.1）
5.合并完成后需要删除此hotfix分支(git branch -d hotfix-1.2.1)
6.将本地分支dev、master分支push到远程dev、master分支 (git push origin dev和git push origin master）
另外：Git进行版本管控时，明确的版本号可增强可发人员的理解。
a.主版本.次版本.修订号
1.0.0
版本号主要有3部分构成（由两个.分割成三部分）主版本、次版本、修订号：
主版本：程序的主版本号，除非系统做整体重构，一般不变化
次版本：功能版本号，一般为功能迭代的版本号，每次版本号为上一次正常按迭代计划发版的次版本 + 1;主版本发生变更，次
版本需重置为0
比如：上次按正常按迭代计划发版的版本号为v1.9.0，本次版本号为 v1.(9+1).0，即 v1.10.0
修订号：每次线上BUG修复，该版本号相对上次修订号+1 （前提：相同主版本以及次版本）;主版本和次版本发生变更，修订号需重置为0
比如：上次修订号为v1.9.3，本次版本号为 v1.9.(3+1)，即 v1.9.4
b. 分支命名规范
1.主分支：
master：master 分支就叫 master 分支
develop：develop 分支就叫 develop 分支
2.辅助分支：
1 Feature 分支
feature/v1.16.0_xxx
feature/v1.16.0_yyy
feature/v1.16.0_zzz
v1.16.0 表示当前迭代的版本号，xxx、yyy、zzz 表示当前迭代的功能或业务单元的名称
2. Release 分支
release/v1.17.0
release/v1.18.0
v1.17.0、v1.18.0 根据上线需求和系统上线计划，合理规划版本号，每个大版本号表示一次上线正常上线过程。
3. Hotfix 分支
hotfix/v1.17.1
hotfix/v1.17.2
v1.17.1、v1.17.2 表示v1.17.0 这个版本做了2次线上问题热修复。
