1 GitFlow概述
GitFlow是一种流行的Git分支管理策略，主要用于软件开发过程中的版本控制和协作。它通过定义清晰的分支结构和工作流程，帮助开发团队更高效地管理代码的开发、测试和发布
GitFlow团队协作对应开发流程/提交规范
常见常用高阶Git命令是否清楚
2 Git常用命令
2.1 Git三个区间
3 GitFlow理论
3.1 GitFlow是什么
GitFlow是一种非常经典的分支管理和发布模型
它特别适合管理有固定发布周期、需要并行开发多个功能以及需要长期维护多个版本的项目。
3.2 GitFlow能干嘛
核心思想：
GitFlow的核心是利用严格的分支模型，为不同的开发任务分配独立的分支，使得开发过程更加结构化、井井有条。
它定义了主要分支和辅助分支并规定了它们之间的交互方式。它是一个非常强大和系统的流程，特别适合有固定发布计划、版本维护需求明确的中大型项目，在选择提交工作流时，应根据团队规模和项目特点来决定是否采用。
3.3 主要分支
3.3.1 五大分支总体概述
① 主分支（master/main）
② 开发分支（develop）
③ 功能分支（feature/*）
feature有道翻译：特点，特征。
④ 发布分支（release/*）
⑤ 热修复分支（hotfix/*）
3.3.2 细说五大分支
3.3.2.1 包含两个贯穿整个项目生命周期的主要分支：
① 主分支（master/main）
② 开发分支（develop）
3.3.2.2 辅助/临时分支
以下3个分支是为了完成特定任务而创建的，任务完成后会被合并并删除
③ 功能分支（feature/*）
feature有道翻译：特点，特征。
④ 发布分支（release/*）
⑤ 热修复分支（hotfix/*）
4 GitFlow实操
4.1 GitFlow操作流程（标准版）
①
②
③
4.2 GitFlow开发流程和提交规范（实战版）
4.2.1 实战案例，步骤详解
4.2.2 gitee远程仓库初始化
1 必定有一个master分支（公司主管已经弄好，现成的）
2 以master分支为起点的dev开发分支
3 入职公司gitee上待下载到本地的工作项目
4.2.3 新员工入职开工
4.2.3.1 检出项目到新员工本地IDEA开发环境
在自己本地IDEA专属开发目录下执行（工具版本）
启动IDEA工具打开上一步clone下来的项目并进入命令终端模式，再用 git pull
① 进入终端命令窗口再用git pull检查下
② 看看分支情况
在自己本地IDEA专属开发目录下执行（命令行版本）
操作也差不多，使用右键 Git Bash Here
4.2.3.2 开发新需求，日常操作
4.2.3.2.1 理论-新开发
4.2.3.2.2 gitee上新建开发某个需求的featureA分支以dev作为分支起点
产品经理建 或 开发人员建 都OK
产品经理建立分支：自顶向下。在远程库建好分支后，开发人员本地拉取
开发人员建立分支：自底向上。在本地建好分支后，推送到远程库
4.2.3.2.3 分支具体细节名称和规范
4.2.3.2.4 feature新需求分支建立完毕
4.2.3.2.5 打开idea用git pull同步下
4.2.3.2.6 将featureA分支从remote检出到local
4.2.3.2.7 在本地featureA上开发编码
add
commit -m
push
4.2.3.2.8 gitee上查看本地feature提交到远程feature情况
4.2.3.2.9 featureA上开发完成的需求要合并进dev分支上
理论-开发完后合并
将dev分支检出到本地
将你在本地feature上完成的功能合并到本地dev分支
本地dev分支push到远程dev分支
4.2.3.2.10 全部开发完成后可以考虑删除featureA分支（可选非必要）
删除本地
git branch -d featureA/featureA_20251212_xxx需求
删除远程
git push origin --delete featureA/featureA_20251212_xxx需求
4.2.3.3 需求开发后，需要发布一个版本（Release）
理论-发布前
Gitee上新建发布分支release-0.1.0以dev作为分支起点
打开idea用git pull同步下
将release-0.1.0分支从remote检出到local
一般而言，发布新版本或多或少会在release分支上改改
配置/IP/密码/小bug/页面等小改动，作为发布准备工作：
add
commit
push
理论-发布中
release-0.1.0分支内容合并进master分支
git checkout master
git merge --no-ff release-0.1.0
git push origin master
打个tag（master上需要打tag）
git tag -a v0.1.0 master
git push --tags
远程仓库标签情况
创建发行版
理论-发布后
release-0.1.0分支内容合并进dev分支
git checkout dev
git merge --no-ff release-0.1.0
git push origin dev
全部发布完成后可以考虑删除release分支
删除本地
删除远程
4.2.3.4 需求发开中，生产报Bug需要处理
理论-生产bug
从master分支作为起点，创建hotfix分支
git checkout -b hotfix-0.1.0 master
修bug
add
commit
git push origin hotfix-0.1.0
远程仓库看看
bug修复完成后需要将hotfix分支合并进master分支
git checkout master
git merge --no-ff hotfix-0.1.0
git push origin master
tag打个自增标签作为修复bug版
git tag -a v0.1.0fix master
git push --tags
远程仓库标签情况
最后，需要将hotfix分支合并进dev分支
git checkout dev
git merge --no-ff hotfix-0.1.0
git push origin dev
全部发布完成后可以考虑删除hotfix-0.1.0分支
删除本地 git branch -d hotfix-0.1.0
删除远程 git push origin --delete hotfix-0.1.0
5 GitFlow小总结
5.1 常用流程一般性总结
5.1.1 feature_新功能开发流程
5.1.2 release_版本发布流程
5.1.3 hotfix_紧急热修复流程
5.2 优点
结构清晰：每个分支职责明确，易于理解和管理
并行开发：支持多个功能并行开发，互不干扰
发布管理：release分支使发布过程变得清晰、可控
紧急响应：hotfix分支提供了快速修复生产问题的通道，不影响正常开发流程
5.3 缺点
流程复杂：对于小型团队或简单项目来说过于繁重
历史不清晰：由于大量的合并提交，Git提交历史会显得比较混乱。
学习成本：新团队成员需要时间熟悉整个流程
5.4 礼貌提醒
不是大厂/中厂就别用
总而言之，GitFlow是一个非常强大的代码分支管理体系，特别适合有固定发布计划、版本并行开发且维护需求明确的中大型项目。在选择工作流时，应根据团队规模和项目特点来决定。
6 Git高阶命令
Git三个区间
通用操作
6.1 版本回退/撤销/重置（CheckOut - Revert - Reset）
6.1.1 情况1：有改动，无add无commit无push
通俗点讲，就是某个被git追踪的文件修改了变成蓝色了，但是没有add，没有commit，没有push。通过 命令 git checkout -- 文件名 ，或者点击Rollback进行回退，变回黑色文件
6.1.2 情况2：有改动有add，无commit无push
git reset的三种模式：
git reset --soft <commit>
git reset --mixed <commit>（默认模式）
git reset --hard <commit>
小总结
也可以直接使用IDEA图形界面的Rollback
6.1.3 情况3：有改动有add有commit，无push
6.1.4 情况4：有改动有add有commit有push★
本次push作废，重新来
6.1.4.1 图形
6.1.4.2 命令
git revert --no-edit 提交流水号
6.1.4.3 再反转
6.1.5 小总结
6.1.5.1 Revert VS Reset
记住这个黄金法则：对私有分支用reset，对公共历史用revert
6.1.5.2 判断是否在历史记录留痕★★★★★
工作区：本地磁盘中存放代码的具体的目录
暂存区：在工作区中写了代码后，需要让git追踪到，让git知道你有这么个代码文件。因此需要使用git add 将工作区的代码添加到暂存区
本地库：
工作区和暂存区的代码，都可以无痕删除。一旦commit提交本地库后，本次提交就生成了历史版本，留痕了。
一旦提交commit，就生成了提交对象，成为项目历史的一部分。这是绝对无法"无痕删除"的。
6.2 git stash之临时存储柜★
1 存储柜是"栈"结构（先进后出）：
可以多次使用git stash，每次都会讲修改推入栈顶
使用git stash list可以查看存储柜里所有的"包裹"
使用git stash pop stash@{n}可以取出指定的包裹（n是编号）
2 取出的两种方式：
git stash pop：取出栈顶的包裹，同时从存储柜中删除它。（就像从柜子里拿出东西后扔掉包装）
git stash apply：取出栈顶的包裹，但包裹仍留在存储柜中。（就像复制了一份）
3 存储的内容：
默认值存储已跟踪文件的修改（即之前被git add过的文件的新修改）
如果要包含未跟踪的文件（新创建的文件），需要用git stash -u
如果要包含被忽略的文件，用git stash -a
6.2.1 git stash
一句话：把当前工作现场"储藏"起来，等以后恢复现场后继续工作
6.2.2 需求说明
6.2.3 案例步骤v2
1 比如feature分支上正在开发，代码写了一半，突然生产报bug，收到报障
2 当前代码是半成品，不方便提交，要把当前工作现场"储藏"起来，等以后恢复现场后继续工作，用git stash，工作区放心地创建分支来修复bug
3 按照master为基线新建bug分支
4 在hotfix分支上修复完bug
5 修复完成后，切换到master分支并完成合并，最后删除刚才的bug分支
6 回到之前的工作现场，工作区是干净的，刚才的工作现场存到哪里去了？用git stash list查看
7 需要恢复一下，有两个办法
① 用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除
git stash apply：取出栈顶的包裹，但包裹仍留在存储柜中。（就像复制了一份）
② 用git stash pop，恢复的同时把stash内容也删了
git stash pop：取出栈顶的包裹，同时从存储柜中删除它。（就像从柜子里拿出东西后扔掉包装）
6.2.4 工作流程小总结
假设你正在某个分支上工作：
正在编码时，街道一个紧急Bug任务。
存储当前工作
切换分支去修复bug
回到功能分支并恢复工作
继续之前的工作
6.3 git cherry-pick
能干吗？
撤回已经push的error代码+不浪费自己本地劳动成果
6.3.1 问题
已经push到远程库了，发现一部分代码OK，一部分代码不合适，需要酌情处理，存在误提交
本地先Revert恢复，但是远程库还存在，需要本地push让远程也OK
本地
远程还有
但是remote仓库还是不合适代码，需要本地push，两者保持一致
到此步骤，远程误提交需要酌情处理的已经完成，外患已除，内忧？
那部分正确的代码怎么办？重写一篇或者外部粘贴？
我们需要：
既要把远程库的误操作干掉，又要把本地正确的劳动成果保留，不能被删除
6.3.2 cherry步骤
6.3.2.1 Cherry-Pick
6.3.2.2 摘樱桃执行后
6.3.2.3 提交内容解除绑定（洗干净才能吃）
6.3.2.4 解绑后恢复到未commit状态
6.3.2.5 将当前代码暂存，Stash执行OK
6.3.2.6 新建devTemp临时分支并切换
6.3.2.7 切换到devTemp临时分支后UnStash
运用UnStash
执行Pop
恢复效果
保留正确的劳动成果，删除错误的隐患，处理后在本分支add-commit
6.3.2.8 切换回feature分支并把devTemp分支内容合并进来，再删除devTemp分支
6.3.2.9 success
6.4 git merge（合并）VS git rebase（变基）
6.4.1 fetch vs pull
git fetch
你可以把它理解为"检查更新"或"预览远程变化"
作用：从远程仓库下载最新的元数据和对象（如提交、分支、标签），但不会修改你本地的工作目录或当前分支，仅仅是安全地查看远程变化情况
git pull
git pull = git fetch + git merge
作用：git pull 实际上是 git fetch + git merge 的组合。如果你直接pull，可能会立即遇到合并冲突。而先fetch，你可以先审查更改，再决定何时merge，流程更可控。
小总结
养成先fetch后，再检查，然后决定是否merge的习惯，是更安全、更专业的Git工作流
6.4.2 merge vs rebase
git merge（合并）
git rebase（变基）
小总结
git merge 和 git rebase都是用于整合不同分支代码的命令，但它们的方式和最终产生的项目历史记录有本质区别
6.4.3 案例
模拟两个开发先后提交到远程库，然后协作，模拟各种状况
6.4.3.1 正常流程（fetch→pull→push）
远程服务器上，另一位开发张三提交了代码，远程比我新，但我不知情
自己本地修改，add-commit，看分支信息提示你本地有改动，可以提交了
此时，直接push到远程，可以吗？
不能直接无脑粗暴的强推
正常操作
git fetch
结论
自然要找找不同，远程gitee/github服务器比我新了哪些东西 ？
本地feature分支和远程feature对比
根据差异结果，判定是否需要合并及解决冲突
git pull
合并
解决冲突
合并代码
git push
success
查看提交日志和远程库历史记录
6.4.3.2 直接粗暴push
远程服务器上张三同学先提交了，我本地修改提交
1 远程更新
2 本地更新，add-commit
本地我违规流程，直接粗暴push，不管不顾
Which One
本次我们先选择merge并处理冲突
再Push
本地+远程都OK
6.4.3.3 上面两次副作用
本地idea-log
远程gitee历史提交记录
结论
提交基线是弯曲的......
后续查找日志，都是充斥大量合并默认记录
6.4.3.4 git pull --rebase
远程服务器上，张三同学先提交了，我本地修改提交
1 远程更新
2 本地更新 add-commit
update project...
git pull --rebase
解决冲突
push到远程
查看基线
