使用git进行合并分支说难也不难，因为就使用一下那几个命令而已！但是不小心操作总会有一些难以预料的问题出现、但是coder们总是会做出奇怪的举动。
合并分支的时候O(∩_∩)O
快速了解下分支流程。
分支类似科幻电影里面经常出现的平行宇宙，只是分支之间还能合并。
git默认的是master分支，如果所有的开发都在master分支，这其实非常操蛋。这么吊的工具怎么可能没有好的分支策略。
- 正常分支
- origin/master：主分支
- origin/develop：开发分支
em 首先代码库默认有一个，且只有一个主分支Master，这个分支是仓库初始化的时候默认创建的。但实际上还有另一主分支 develop（开发主分支）、只是很多开发并不会启用develop分支。当develop分支上代码达到一定稳定的时候，所有的改动就会被合并到master中。并用一个发行版来标记它。所以每当被合并到master中就意味着一次release版本发布。这个时候才会使用(hook script)钩子去自动构建我们的项目、并部署正式服务器。
- 临时分支
- feature：功能分支（特征分支）
- release：预发布分支（发行分支）
- fixbug：修补bug分支（热补丁分支）
为什么会有临时分支这种东西，上面说到主分支是用来管理重大版本发布的。日常的开发应该是在另外一条分支上进行develop，而临时分支是在develop分离出来做迭代以及bug修复的。达到阶段目标在合并到develop分支当中。
这张图很久以前看到的，源地址忘记了，若发现侵权请联系本人删除。
- Git创建Develop分支的命令：
git checkout -b develop master
将Develop分支发布到Master分支的命令：
# 切换到Master分支
git checkout master
# 对Develop分支进行合并
git merge develop
基本上只有会是develop分支合并到master中。由于master是必须使用的就不在多介绍，下面说下其它分支。
Feature
这个分支一般来说是不会存在原始仓库的。而是存在开发人员的仓库中。
- 当开始开发一个新功能时，从 develop 分支分离出来。
# 从 develop中分离出一个分支
git checkout -b myfeature develop
- 合并一条已经完成的 Feature 分支到 develop 分支
完成了的功能需要合并到 develop 分支，以确切把其添加到下一个要发行的版本中。
# 切换到develop分支中
git checkout develop
# 对myfeature分支进行合并
git merge myfeature
# 删除myfeature分支 合并完一定要删除。
git branch -d myfeature
# 推送至develop分支。
git push origin develop
Release
不要认为这是从master中分出来，这实际上是从develop分支中发布的。当我们需要迭代一个稳定版本的时候我们就会从develop中分离一个分支名字用于展示指定的新版本号。
- 创建一条 Release 分支
# 从develop中分离出release-1.2
git checkout -b release-1.0 develop
# 推送到本地仓库中。
git commit -a -m "create version number to 1.0"
release 可能会存在一段时间、等待bug修复。不要在这个分支在加大功能，这非常扯蛋。当确定没问题之后合并到master中。
# 切换到master主分支
git checkout master
# 合并分支
git merge release-1.0
# 打标签。
git tag -a 1.2
注意不光要合并到master、develop分支也要合并。
# 切换到develop主分支
git checkout develop
# 合并分支
git merge release-1.0
# 合并完 master 、develop分支可以删除release了。
git branch -d release-1.0
Hotfix
这个分支就是来修复bug的。其实和release分支很相似，只不过生命周期更短，可能需要合并多次。
从master分离出来之后合并时候需要合并两次。
- 创建一条 Hotfix 分支
# 从master中分离出hotfix-1.0.1
git checkou -b hotfix-1.0.1 master
# 推送到本地仓库
git commit -a -m "create hotfix-1.0.1"
改玩bug了就可以合并到master 、 develop中了。
# 切换到master
git checkout master
# 将hotfix合并到master中。
git merge hotfix-1.0.1
# 打标签
git tag -a 1.3
在把改动的代码合并到develop中。
# 切换到develop
git checkout develop
# 将hotfix合并到develop中。
git merge hotfix-1.0.1
# 删除hotfix。
git branch -d hotfix-1.0.1
合并分支操作并没有那么简单，分支流程大致是这样的。
规范代码开发流程
git 分支分为集成分支、功能分支和修复分支，分别命名为 develop、feature 和 hotfix，均为单数。不可使用 features、future、hotfixes、hotfixs 等错误名称。
1.git主分支(master)。它是自动建立，用于发布重大版本更新（github 现在默认是是main 因种族歧视问题） 2.git开发主分支(develop)。日常开发在此分支上进行 3.git临时性分支：用于应对一些特定目的的版本开发(验证OK后，应该删除此分支)
- 功能（feature）分支：它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。可以采用feature-的形式命名。
- 预发布（release）分支：指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。预发布分支是从Develop分支上面分出来的，预发布结束以后，
必须合并进Develop和Master分支。它的命名，可以采用release-的形式。
- 修补bug（hotfix）分支：软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。修补bug分支是从Master或Develop分支上面分出来的。修补结束以后，
再合并进Master和Develop分支。它的命名，可以采用hotfix-***的形式。
开发流程
暂定临时分支feature、hotfix两种启用。暂不启用RP、code review。
1.基于develop生成新临时开发分支。 2.测试、正式环境上线通过。 3.合并至develop分支，并生成对应的tag版本。 4.完成特定功能开发后(验证OK后，应该删除此分支)。 5.README.md文档中记录tag版本生成时间以及具体的功能名称。
修复bug流程
根据最新已经上线的分支代码创建hotfix分支。
1.基于develop或者上个tag版本(根据实际情况而定)生成新临时开发分支。 2.测试、正式环境上线通过。 3.合并至develop分支，并生成对应的tag版本。 4.若存在临时开发分支-完成特定功能开发后(验证OK后，应该删除此分支)。 5.若存在临时开发分支-临时开发分支合并已经修复bug的develop代码。 6.若存在临时开发分支-临时开发分支完成特定功能开发后(验证OK后，应该删除此分支)。 7.README.md文档中记录tag版本生成时间以及具体的功能名称。
案例
开发需求
git checkout develop // 切换开发分支，git pull origin develop 并同步最新的develop分支代码。（强制）
git checkout -b feature-sizeGroup //基于develop分支创建新的开发分支（强制）
git checkout develop // feature-sizeGroup完成上线后develop分支准备合并分支（强制）
git merge feature-sizeGroup // 合并开发功能分支（强制）
git tag -a v1.4 -m "my version 1.4" // 合并完成创建标签备注中简单说明开发功能（强制）
git push origin v1.4 // 推送tag标签到远程仓库（强制）
git branch -d feature-sizeGroup //删除本地的临时开发分支(非强制)
git push origin --delete feature-sizeGroup // 删除远程的临时开发分支（强制）
vim README.md // 保存新增tag版本记录（强制）
git add README.md // 追踪README.md文件。（强制）
git commit -m "发布新的tag" // 将暂存区里的改动给提交到本地的版本库（强制）
git push origin develop // 推送改动后的develop（强制）
master 合并周期
每月月底最后几个工作日完成对master 对develop分支的合并。
tag 版本命名
版本命名规范
- 版本: v1.1.1 ( Build 101001 )
- 版本格式 bigVersion.middleVersion.smallVersion
- bigVersion 大版本(年度或者重大更新（强制更新，老版本存在不兼容等情况）) 取值范围 1-99
- middleVersion 迭代版本 取值范围 1-99
- smallVersion bug修复增强发布。 取值范围 1-999
- Build为版本纯数字格式化。