分支开发实践

---

前言

大家好，我是一个刚踩过坑，拍拍灰尘，又跳到坑里的菜鸟开发。

此篇主要通过一个案例来演示分支开发的实践过程。

---

提示：以下是本篇文章正文内容，下面案例可供参考

一、准备工作

1.创建远程仓库

以github作为远程仓库为例，github地址：https://github.com/new

创建示例：

创建成功后，拉取代码到本地

git clone [https地址] # 拉取代码

2.初始化本地仓库

git init # 初始化本地仓库，多出一个.git的隐藏文件夹

3.首次提交

提交流程：完成内容编辑=>添加到暂存区=>提交本地仓库=>提交远程仓库

git remote add origin [ssh地址] # 给远程仓库建立别名origin
echo "0.0.1-SNAPSHOT" >> version.xml #  内容编辑
git add version.xml # 添加新文件到暂存区，并建立索引
git commit -m "version init" # 提交本地仓库 -m指msg
git push -u origin master # 推送master分支到远程仓库，-u 相当于 --set-upstream 添加上游引用

提示：master分支为稳定主线分支，用来打tag的静态版本发布或回滚。

成功示例：

二、第一个版本开发

场景：公司要求A开发一个用户管理和视频播放功能，并上线

1.新建开发分支

git checkout -b dev/v1.0.x  # 新建一个开发分支dev/v1.0.x 并切换到对应分支

2.完成开发

开发A在dev/v1.0.x分支上开发功能完成

echo "视频播放功能 100%" > movie.file # 视频功能
echo "用户中心功能 100%" > user.file # 用户功能
0.0.1-SNAPSHOT => 1.0.0-SNAPSHOT # 修改配置

拟定：

1. .file文件是功能代码
2. version.xml是配置文件，开发完要修改版本号

3.提交代码

这里执行一次提交代码流程。

git add . # 添加全部文件到暂存区
git commit -m"用户中心、视频播放功能开发完成" # 提交本地仓库
git push origin dev/v1.0.x # 提交远程仓库

成功示例：

4.代码回归

dev/v1.0.x分支上的功能代码要合并到master分支再打tag静态版本

git checkout master # 回到master分支
git pull # 托取最新代码，防止别人也提交
git merge dev/v1.0.x # 合并到主干

5.版本上线

注意：线上版本的配置和开发的配置有区别。

上线流程：创建临时分支=>修改线上配置=>提交配置到本地仓库=>打tag包=>推送tag到远程仓库=>删除临时分支=>运维拿tag线上发布

git checkout -b release/v1.0.0 # 新建临时分支release/v1.0.0用于发布
0.0.1-SNAPSHOT => 1.0.0 # 修改version.xml配置文件的版本号
git commit -am"v1.0.0线上配置" # -am直接从工作区添加到本地仓库
git tag -a "release_v1.0.0" -m "第一个版本上线" # 打包tag,-a是annotate -m是msg 
git push origin release_v1.0.0 # 推送打包后的tag文件到远程仓库
git checkout master # 切换到本地的master分支
git branch -D release/v1.0.0 # 强制删除分支，不管你有没有merge，-d也可以使用

成功示例：

这里有几个问题：

1. 为什么用release临时分支?
   答：修改线上配置，用来打包tag
2. 为什么只推送tag到远程仓库？
   答：tag用于版本发布
3. branch和tag之间的区别是什么？
   答：分支可能是多次commit ，tag是一次commit

成功示例：

二、第一个版本新增功能

场景：公司要求A开发弹幕功能，弹幕功能开发至30%，出现线上bug波许优先解决并发布，但是不能把弹幕功能代码发布出去。

1.开发弹幕功能

git checkout -b dev/1.1.x # 创建并切换到dev/1.1.x分支
echo "弹幕功能 30%" > screen.file # 弹幕功能开发至30%

2.出现线上bug

git commit -m"弹幕功能开发30%" # 出现bug，首先提交已开发代码至本地仓库
git checkout dev/v1.0.x # 其次切换到dev/v1.0.x 分支去修复bug
echo "BUG修复完成" > bug.file # 修复bug完成
1.0.0-SNAPSHOT => 1.0.1-SNAPSHOT # 修复bug同样改配置
git add . # 添加
git commit -m"修复线上bug" # 提交本地仓库
git push orgin dev/v1.0.x # 提交远程仓库

注意：若一次没修复成功，可以多次commit提交，直到修复成功为止。多次commit提交去修复，但是只需要一次tag去发布修复代码，这就是branch和tag区别。

2.发布修复版本

修复代码回归master

git checkout master 
git pull
git merge dev/v1.0.x # 修复代码合入主干
git push # 推送master到远程仓库

提示：重复一次发布流程即可

git checkout -b release/v1.0.1
1.0.1-SNAPSHOT => 1.0.1 # 修改配置
git commit -am"修改线上配置" 
git tag -a "release_v1.0.1" -m "v1.0.x的bug修复版本" # tag
git push origin release_v1.0.1 # bug修复版推送到远程仓库
git checkout master # 回到master
git branch -D release/v1.0.1 # 删除临时的发布分支

成功示例：

3.继续开发弹幕功能

A继续开发弹幕功能从30% => 100%，重复一次提交流程

git checkout dev/v1.1.x # 回到dev/v1.1.x分支继续开发弹幕功能
echo "弹幕功能 70%" > screen-plus.file # 开发剩余的70%弹幕功能
git add . # 添加全部文件到暂存区
git commit -m"弹幕功能剩余70%" # 提交本地仓库
git push origin dev/v1.1.x # 推送到远程仓库

4.弹幕功能上线

弹幕功能回归主干

git checkout master 
git pull
git merge dev/v1.1.x # 弹幕功能回归主干
git push # 推送远程仓库

重复一次发布流程即可

git checkout -b release/v1.1.0
1.1.0-SNAPSHOT => 1.1.0 # 修改为线上配置
git merge dev/v1.0.x # 上线前合入修复的bug，同时修改冲突
git add . 
git commit -m"弹幕功能上线"
git tag -a "release_v1.1.0" -m "弹幕功能上线" # tag
git push origin release_v1.1.0 # 推送到远程仓库
git checkout master # 回到master
git branch -D release/v1.1.0 # 删除临时的发布分支

成功示例：



运维可以直接拿release-v1.1.0来发布

三、第二个版本开发

场景：公司要求A、B一起开发搜索功能，C开发会员功能。A开发前端，B开发后端，他们需要合作联调。C独立开发会员功能，且C优先开发完成。公司要求先发布vip功能，再发布搜索功能。

1.创建分支

注意：由于多人协作，创建开发分支，再创建特性分支，详细见图

git checkout master # 回到master分支
git pull # 拉去最新代码，防止被人提交
git checkout -b dev/v2.0.x
git branch feature/v2.0.0_search # 创建特性分支用于搜索功能开发
git branch feature/v2.0.0_vip # C创建特性分支用于会员功能开发
git branch feature/v2.0.0_search1 # A创建特性分支用于搜索功能前端开发
git branch feature/v2.0.0_search2 # B创建特性分支用于搜索功能后端开发

2.多人协作开发

第一天：AB 开发各自的功能，开发完成合入feature/v2.0.0_search分支进行联调
第二天：AB联调的时候，C已经开发完，准备发布会员功能，在feature/v2.0.0_vip分支上创建临时分支=>修改线上配置=>打tag包=>推送到远程仓库=>删除临时分支release。
第三天：AB联调并解决BUG，ABC的分支都合入到dev/v2.0.x，然后重复发布流程即可。

至此，大致的分支开发 以及 发布流程已经完成，查看下远程仓库的tag，如图

---

总结

分支开发，是一个团队常用的开发方式，不仅仅方便多人协作，也方便解决BUG 和 版本上线。但是团队应该根据实际情况来选择是否采用分支开发的方式，各有利弊。

参考文档

github示例：https://github.com/runsground/branch-dev/tree/master
分支开发视频：https://www.bilibili.com/video/BV1iC4y1s7T3
git基础：https://www.runoob.com/git/git-tutorial.html