本系列包含:
Git Flow(Git 工作流程)是指软件项目中的一种 Git 分支管理模型,经过了大量的实践和优化,被认为是现代敏捷软件开发和 DevOps(开发、技术运营和质量保障三者的交集)的最佳实践。
✅ 主分支:master
,稳定版本代码分支,对外可以随时编译发布的分支,不允许直接 Push 代码,只能请求合并(pull request
),且只接受 hotfix
、release
分支的代码合并。
✅ 热修复分支:hotfix
,针对线上紧急问题、Bug 修复的代码分支,修复完后合并到主分支、开发分支。
hotfix
分支,从 master
更新代码;dev
分支,在本地 Git 中操作即可;master
分支。
✅ 发版分支:release
,版本发布分支,用于迭代版本发布。迭代开发完成后,合并 dev
代码到 release
,在 release
分支上编译发布版本,以及修改 Bug(定时同步 Bug 修改到 dev
分支)。测试完成后,此版本可以作为发版使用,然后把稳定的代码 Push 到 master
分支,并打上版本标签。
✅ 开发分支:dev
,开发版本分支,针对迭代任务开发的分支,日常开发原则上都在此分支上面,迭代完成后合并到 release
分支,开发、发版两不误。
✅ 其他开发分支:dev-xxx
,开发人员可以针对模块自己创建本地分支,开发完成后合并到 dev
开发分支,然后删除本地分支。
当你正在 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
# 比较一下,什么都没有,一切都没有发生过!
$ git diff
# 去其他分支修改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 |
删除隐藏记录 |
当然这里先提交到本地也是可以的,只是提交不是一个完整的功能代码,而是残缺的一部分,影响也不大。
当有一个紧急 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]