【DevOps】Git 图文详解（九）：工作中的 Git 实践

本系列包含：

• Git 图文详解（一）：简介及基础概念
• Git 图文详解（二）：Git 安装及配置
• Git 图文详解（三）：常用的 Git GUI
• Git 图文详解（四）：Git 使用入门
• Git 图文详解（五）：远程仓库
• Git 图文详解（六）：Git 利器 - 分支
• Git 图文详解（七）：标签管理
• Git 图文详解（八）：后悔药 - 撤销变更
• Git 图文详解（九）：工作中的 Git 实践

Git 图文详解（九）：工作中的 Git 实践 

1.Git Flow

Git Flow（Git 工作流程）是指软件项目中的一种 Git 分支管理模型，经过了大量的实践和优化，被认为是现代敏捷软件开发和 DevOps（开发、技术运营和质量保障三者的交集）的最佳实践。

✅ 主分支：

master

，稳定版本代码分支，对外可以随时编译发布的分支，不允许直接 Push 代码，只能请求合并（

pull request

），且只接受

hotfix

、

release

分支的代码合并。

✅ 热修复分支：

hotfix

，针对线上紧急问题、Bug 修复的代码分支，修复完后合并到主分支、开发分支。

• ① 切换到 hotfix 分支，从 master 更新代码；
• ② 修复 Bug；
• ③ 合并代码到 dev 分支，在本地 Git 中操作即可；
• ④ 合并代码到 master 分支。

✅ 发版分支：

release

，版本发布分支，用于迭代版本发布。迭代开发完成后，合并

dev

代码到

release

，在

release

分支上编译发布版本，以及修改 Bug（定时同步 Bug 修改到

dev

分支）。测试完成后，此版本可以作为发版使用，然后把稳定的代码 Push 到

master

分支，并打上版本标签。

✅ 开发分支：

dev

，开发版本分支，针对迭代任务开发的分支，日常开发原则上都在此分支上面，迭代完成后合并到

release

分支，开发、发版两不误。

✅ 其他开发分支：

dev-xxx

，开发人员可以针对模块自己创建本地分支，开发完成后合并到

dev

开发分支，然后删除本地分支。

2.金屋藏娇 stash

当你正在

dev

分支开发一个功能时，代码写了一半，突然有一个线上的 Bug 急需要马上修改。

dev

分支 Bug 没写完，不方便提交，就不能切换到主分支去修复线上 Bug。Git 提供一个

stash

功能，可以把当前 工作区、暂存区 未提交的内容 “隐藏” 起来，就像什么都没发生一样。

# 有未提交修改，切换分支时报错
$ git checkout dev
error: Your local changes to the following files would be overwritten by checkout:
        README.md
Please commit your changes or stash them before you switch branches.
Aborting
 
# 隐藏
$ git stash
Saved working directory and index state WIP on main: 2bc012c s
 
# 查看被隐藏的内容
$ git stash list
stash@{0}: WIP on main: 2bc012c s
 
# 比较一下，什么都没有，一切都没有发生过！
$ gitdiff# 去其他分支修改bug，修复完成回到当前分支，恢复工作区
$ git stash pop

在上面示例中，有未提交修改，切换分支时报错。错误提示信息很明确了，

commit

提交或

stash

隐藏：

Please commit your changes or stash them before you switch branches.

📢 如果切换分支时，未提交修改的内容没有冲突，是可以成功切换的，未提交修改会被带过去。

  指令 

  描述 

git stash

把未提交内容隐藏起来，包括未暂存、已暂存。 等以后恢复现场后继续工作

git stash list

查看所有被隐藏的内容列表

git stash pop

恢复被隐藏的内容，同时删除隐藏记录

git stash save “message”

同

git stash

，可以备注说明

message

git stash apply

恢复被隐藏的文件，但是隐藏记录不删除

git stash drop

删除隐藏记录

📢 当然这里先提交到本地也是可以的，只是提交不是一个完整的功能代码，而是残缺的一部分，影响也不大。

3.拣选提交 cherry-pick

当有一个紧急 Bug，在

dev

上修复完，我们需要把

dev

上的这个 Bug 修复所做的修改 “复制” 到

master

分支，但不想把整个

dev

合并过去。为了方便操作，Git 专门提供了一个

cherry-pick

命令，让我们能复制一个特定的提交到当前分支，而不管这个提交在哪个分支。

如上图，操作过程相当于将该提交导出为补丁文件，然后在当前

HEAD

上重放，形成无论内容还是提交说明都一致的提交。

• 希望把 dev 分支上的 v7 提交的内容合并到 master，但不需要其他的内容。
• 在 master 分支上执行指令 git cherry-pick v7，会产生一个新的 v7’ 提交，内容和 v7 相同。
• 同时更新 master、HEAD，以及工作区。

# 选择一个commit，合并进当前分支
$ git cherry-pick [commit]