Git 工作流程
2019-04-17 本文已影响0人
林键燃
Git 工作流程
应用的分支及其描述
分支应用情景
git-flow
production 分支（长期分支）
定义：生产环境分支
作用：记录每一个正式发布版本，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，风险较大!
