[版本控制]原来Git分支都是这么用的

微信号：GitShare
微信公众号：爱折腾的稻草
如有问题或建议，请在公众号留言^[1]

十多年的钢城网站建设经验，针对设计、前端、开发、售后、文案、推广等六对一服务，响应快，48小时及时工作处理。成都全网营销推广的优势是能够根据用户设备显示端的尺寸不同，自动调整钢城建站的显示方式，使网站能够适用不同显示终端，在浏览器中调整网站的宽度，无论在任何一种浏览器上浏览网站，都能展现优雅布局与设计，从而大程度地提升浏览体验。创新互联从事“钢城网站设计”,“钢城网站推广”以来，每个客户项目都认真落实执行。

Git的分支类型

1、Master分支

一个项目的代码库应该有且只有一个主分支，所有提供给用户使用的正式版本，都是在这个主分支上，我们称为Master分支。

2、Develop分支

日常使用的开发分支。这个分支可以用来生成代码的隔夜版本，如果开发功能测试完成后，想正式对外发布，就在Master分支上，对Develop分支进行“合并”（Merge）。

3、临时分支

除了日常开发设置分支外，还有一种临时分支，以应对一些特定目的的版本开发。

• 功能分支：它是为了开发某种特定的功能，从Develop分支上分出来的。开发完成后，合并到Develop分支上。其命名规范：feature-*

• 预发布分支：在发布到正式版本之前，我们可能需要有一个预发布版本进行测试。预发布分支是从Develop分支上分出来的，预发布结束后，必须合并到Develop分支和Master分支。其命名规范：release-*

• 修补Bug分支：软件正式发布后，出现一些Bug，这时就需要创建一个分支，来进行Bug修复。修复Bug分支是从Master分支上分出来的，修补结束后，在合并到Develop和Master分支。其命名规范：fixbug-*

Git的分支使用

1、develop分支(develop)

• Git创建develop分支
  develop分支是从master分支中分出来的，其命令：

git checkout -b develop master

• 将develop分支发布到master分支

# 切换到master分支
git checkout master

# 对develop分支进行合并
git merge --no-ff develop

Git Merge在默认情况下是执行“快进式合并”，也就是将master分支直接指向develop分支，并没有建立新的节点。
为了保证版本演进的清晰，我们一般采用正常合并，即使用--no-ff参数，master分支上生成一个新节点。

2、功能分支(feature-*)

• Git创建功能分支
  feature分支是虫develop分支中分出来的，其命令：

# x 版本号，如：1.1
git checkout -b feature-x develop

• 将feature分支合并到develop分支
  开发完成后，需要将功能分支合并到开发分支，其命令：

git checkout develop
git merge no-ff feature-x 

• 删除功能分支

git branch -d feature-x

3、预发布分支(release-*)

• Git创建预发布分支
  预发布分支是从develop分支中分出来的，其命令：

# x 版本号，如：1.1
git checkout -b release-x develop

• 将预发布分支合并到master分支
  预发布分支测试没有问题后，需要合并到master分支，其命令：

git checkout master
git merge --no-ff release-x

# 对合并生成的新节点，做一个标签(打上版本标签)
git tag -a x

• 删除预发布分支

git branch -d release-x

4、修复Bug分支(fixbug-*)

• Git创建修复Bug分支
  修复Bug分支是从master分支中分出来的，其命令：

# x版本号，如：1.1.1
git checkout -b fixbug-x master

• 将修复Bug分支合并到master分支
  bug修复完成后，需要合并到master分支，其命令：

git checkout master
git merge --no-ff fixbug-x 
git tag x

• 将修复bug分支合并到develop分支

git checkout develop
git merge --no-ff fixbug-x

• 删除修复bug分支

git branch -d fixbug-x

总结

在Git系统中合并代码有git merge 和git rebase两种方式。为什么我们不讲git rebase呢，因为它不常用。

• rebase的优势在于项目的历史提交信息非常完整。

• rebase的劣势在于安全性和可跟踪性。

• rebase的黄金法则：==绝对不要在公共分支上使用它==。