Git 工作流程
应用的分支及其描述
分支应用情景
git-flowproduction 分支(长期分支)
定义:生产环境分支
作用:记录每一个正式发布版本,TAG 所在分支
合并关系:允许 release
\ hotfix
分支的合并
push:不允许
建立时机:master
分支创建完成
初始代码来源:仓库创建
master 分支(长期分支)
定义:开发分支
作用:保持最新的开发代码
合并关系:允许 feature
\ release
\ hotfix
分支的合并
push:不允许
建立时机:仓库初始化
初始代码来源:production
分支
release 分支
定义:发布分支
作用:表示一个正式发布版本
合并关系:不允许任何分支合并
push:允许
建立时机:线上代码满足发布要求
初始代码来源:任意线上 commit,推荐使用 master
分支
完成操作:合并至 master
\ production
分支、在 production
分支的 commit 上打相应的 TAG
删除操作:合并至 master
\ production
分支,成功发版后,即可删除
feature 分支
定义:新功能分支
作用:独立的功能需求
合并关系:master
分支
push:允许
建立时机:需要开发新的功能
初始代码来源:任意线上 commit,推荐使用 master
分支
完成操作:合并至 master
分支
删除操作:完成功能,合并至 master
分支后,即可删除
hotfix 分支
定义:修复BUG分支
作用:用于修复已发布版本 BUG
合并关系:不允许任何分支合并
建立时机:发布版本出现 BUG
初始代码来源:production
分支
完成操作:合并至 master
\ production
分支
删除操作:完成 BUG 修复,合并至 master
\ production
分支后,即可删除
工作流程概述
流程图
git-flow.png概述
- 从
master
分支中创建出production
分支 - 从
master
分支中创建出一个release
分支 - 从
master
分支中创建出所有的feature
分支 - 当一个
feature
分支的功能开发完成后,合并到master
分支中 - 当
release
分支测试通过之后,同时合并到master
分支和production
分支 - 当
production
分支有紧急 BUG 需要修复时,从production
分支创建一个hotfix
分支,在hotfix
分支中进行 BUG 的修复 - 当 BUG 在
hotfix
分支中修复完成之后,同时合并到master
分支和production
分支
Git 相应操作
命令行版本
- 从
master
分支中创建出一个production
分支
// 切换到 master 分支
git checkout master
// 创建 production 分支,并切换到 production 分支
git checkout -b production
// 推送到远程仓库,并建立本地分支与远程分支的映射关系
git push --set-upstream origin production
- 从
master
分支中创建出一个release
分支
// 切换到 master 分支
git checkout master
// 创建 release 分支,并切换到 release 分支;release 分支常带有对应的版本号,如 1.0.0
git checkout -b release-1.0.0
// 推送到远程仓库,并建立本地分支与远程分支的映射关系
git push --set-upstream origin release-1.0.0
- 从
master
分支中创建出 所有的feature
分支
// 切换到 master 分支
git checkout master
// 创建 feature 分支,并切换到 feature 分支;feature 分支命名需跟开发的功能模块相对应,如 feature-o2o
git checkout -b feature-o2o
// 推送到远程仓库,并建立本地分支与远程分支的映射关系
git push --set-upstream origin feature-o2o
- 当一个
feature
分支的功能开发完成后,合并到master
分支中
// 切换到 master 分支
git checkout master
// 合并 feature-o2o 分支
git merge --no-ff feature-o2o
// 删除对应本地 feature 分支
git branch -d feature-o2o
// 删除对应的远程分支,命令1
git push origin :feature-o2o
// 删除对应的远程分支,命令2
git push origin --delete feature-o2o
- 当
release
分支测试通过之后,同时合并到master
分支和production
分支
// 切换到 master 分支
git checkout master
// 合并 release-1.0.0 分支
git merge --no-ff release-1.0.0
// 切换到 production 分支
git checkout production
// 合并 release-1.0.0 分支
git merge --no-ff release-1.0.0
// 成功部署之后,即可删除对应的 release 分支
git branch -d release-1.0.0
// 删除对应的远程分支,命令1
git push origin :release-1.0.0
// 删除对应的远程分支,命令2
git push origin --delete release-1.0.0
- 当
production
分支有紧急 BUG 需要修复时,从production
分支创建一个hotfix
分支,在hotfix
分支中进行 BUG 的修复
// 切换到 production 分支
git checkout production
// 创建 hotfix 分支,并切换到 hotfix 分支;hotfix 分支常带有对应的版本号,如 1.0.1
git checkout -b hotfix-1.0.1
// 推送到远程仓库,并建立本地分支与远程分支的映射关系
git push --set-upstream origin hotfix-1.0.1
- 当 BUG 在
hotfix
分支中修复完成之后,同时合并到master
分支和production
分支
// 切换到 master 分支
git checkout master
// 合并 release-1.0.0 分支
git merge --no-ff hotfix-1.0.1
// 切换到 production 分支
git checkout production
// 合并 release-1.0.0 分支
git merge --no-ff hotfix-1.0.1
// 成功部署之后,即可删除对应的 hotfix 分支
git branch -d hotfix-1.0.1
// 删除对应的远程分支,命令1
git push origin :hotfix-1.0.1
// 删除对应的远程分支,命令2
git push origin --delete hotfix-1.0.1
常见问题 && 解决方案
问题 1:新建本地分支并与远程分支建立映射关系
解决方案 --- 命令版
解决方案一
// 采用此方法会在本地新建 feature-test 分支,并与远程分支 feature-test 建立映射关系
git checkout -b feature-test origin/feature-test
解决方案二
// 如果本地已经存在 feature-test 分支,则可以直接与远程分支 feature-test 建立映射关系
// 切换到 feature-test 分支
git checkout feature-test
git push --set-upstream origin feature-test
问题 2:release 分支完成最后测试之后,为什么要同时合并到 master 和 production 分支上?
原因 --- 避免 BUG 重现
- 为什么要合并到
master
分支上?
release
分支上可能会测到并修复一些问题,所以master
分支需要同步,避免之后版本出现相同的问题 - 为什么要合并到
production
分支上?
合并到production
分支上用于项目部署,此时production
分支上的项目是线上版本
问题 3:hotfix 分支完成 BUG 修复之后,为什么需要合并回 master
分支?为什么一开始不直接从 master
分支切出?
原因 --- 避免 BUG 重现
- 为什么需要合并回
master
分支?
避免master
分支再次合并至production
分支时,问题重现 - 为什么一开始不直接从
master
分支切出hotfix
分支出来修复问题?
因为master
分支中可能有功能尚在开发中还未测试,此时 Master 分支中的代码可能存在没有测出的 BUG,风险较大!
网友评论