一、GitFlow 理论
1.1 GitFlow 是什么？
GitFlow 是一种基于 Git 的分支管理模型（Branching Model） ，由 Vincent Driessen 提出，用来规范多人协作、版本发布、紧急修复等场景下的 Git 使用方式。
一套"大家都按同一规则来建分支、合并、发版"的工作流程
1.2 GitFlow 解决什么问题？
在实际开发中，经常会遇到这些痛点：
- 多人同时开发，分支乱、合并冲突多
- 正在开发新功能时，线上突然要紧急修 Bug
- 不知道当前代码是「开发中」还是「可发布」
- 发版后想回溯某个版本，找不到对应代码
GitFlow 的目标就是：让开发、测试、发布、维护都"有章可循"
1.3 GitFlow 的核心分支（重点）
GitFlow 定义了 5 种常见分支角色 ，其中 2 个长期分支 + 3 个临时分支。
master ------ 主分支
- 只存放已发布到生产环境的代码
- 每一次合并到 master，通常都会打一个 tag（版本号）
- 不允许直接在 master 上开发
shell
v1.0.0
v1.1.0develop ------ 开发分支
- 日常开发的"集成分支"
- 所有新功能最终都会合并到这里
- 不直接上线
📌 可以理解为：
"下一版本正在开发中的代码"
feature/* ------ 功能分支
- 从
develop拉出 - 用来开发单个功能
- 功能完成后合并回
develop - 合并后删除
📌 示例：
shell
feature/login
feature/order-pay👉 你日常写代码，90% 都在 feature 分支
release/* ------ 发布分支
- 从
develop拉出 - 用于 发版前的测试、Bug 修复、版本号调整
- 不再加新功能
- 完成后：
- 合并到
master - 同时回合并到
develop - 删除 release 分支
- 合并到
📌 示例：
shell
release/1.2.0hotfix/* ------ 热修复分支
- 从
master拉出 - 用于 线上紧急 Bug 修复
- 修完后：
- 合并到
master - 同时合并回
develop - 删除 hotfix 分支
📌 示例：
shell
hotfix/fix-null-pointer一句话总结：
- feature → develop → release → master
- 紧急问题：master → hotfix → master + develop
二、GitFlow 实操
dev 分支初始化
存在一个 master 分支
新建 dev 分支
开发人员克隆项目到本地 IDEA
feature 分支新建
产品经理新建
开发人员新建
feature 分支多线并行开发后提交
好处：其他分支是不受影响的
featureA 分支上修改代码，并提交到 gitee 看效果
可以看到featureB 分支没有任何改动
featureA 完成需求后合并到 dev 分支
将 dev 分支检出到本地
将刚才本地完成的featureA 分支功能合并到 dev 分支
本地 dev 分支 push 到远程 dev 分支
新需求完成后删除本地 featureA 分支，远程可删可不删
release 分支-发布前
运维或者测试新建 release 分支，以 dev 分支作为起点
打开 idea git pull 同步分支，然后将release-0.1.0 分支从 remote 检出到 local
- 一般而言，发布新版本或多或少会在 release 分支上改改配置/IP/密码/页面等小动作，作为发布准备工作
- 修改完成后，add->commit->push 到远程仓库
release 分支-发布中
release-0.1.0 分支内容合并到 master 分支
打个 tag
创建发行版
release 分支-发布后
release-0.1.0 分支内容合并进 dev 分支
全部发布完成后可以考虑删除 release 分支
hotfix 分支修复 BUG 合并 master 分支
切换到 master 分支，在 master 分支上新建hotfix-0.1.0 分支
add->commit->push 到远程仓库
bug 修复完成后需要将hotfix 分支合并进 master 分支
- 切换到 master 分支
- merge 合并hotfix 分支
- pull 推送到远程仓库
tag 打个自增标签作为修复 bug 版本
hotfix 分支修复 BUG 合并 dev 分支
bug 修复完成后需要将hotfix 分支合并进 dev 分支
- 切换到 dev 分支
- dev 合并 hotfix 分支
- pull 推送到远程仓库
操作完成后可以考虑删除hotfix-0.1.0 分支
三、高阶
1、版本回退、撤销、重置
情况 1
代码有改动，无 add、无 commit、无 push
情况 2
代码有改动，有 add、无 commit、无 push
情况 3
代码有改动，有 add、有 commit、无 push
情况 4
代码有改动，有 add、有 commit、有 push
- 本次 push 作废
只是撤销本地，远程还有需要在 push 一下提交远程撤销刚才的提交
2、git stash 之临时存储柜
想象一下你在写作业（代码），突然老师叫你去帮忙搬个东西。这个时候你的作业还没写完，桌上堆了一堆草稿纸和半成品，但又不能就这么放着不管，因为别人可能要用这个桌子。怎么办呢？
git stash就像是一个临时的抽屉，你可以把桌面上所有的东西（包括那些没完成的工作）都快速地收起来放进这个抽屉里，然后桌面就干净了，你可以放心地去做别的事情（比如切换到另一个任务或分支）。等你回来的时候，只需要打开这个抽屉，就能把之前收起来的东西再拿出来继续工作。具体来说，在 Git 中使用
git stash命令可以把当前工作区中未提交的修改保存起来，这样你就可以切换分支或者做其他操作而不用担心丢失这些修改。当你需要恢复这些修改时，可以使用git stash apply或git stash pop来取回它们。这就像把东西从抽屉里重新拿出来放到桌子上一样。
3、git cherry-pick
git cherry-pick是 Git 中的一个命令，它的作用是将某一个或几个特定的提交（commit）从一个分支复制到当前所在的分支。这就好比你有一本画册，里面有很多页不同的图画，你想把其中一页特别喜欢的图画单独拿出来放到另一本画册里去，而不需要整本都搬过去。举个例子来说，假设你在开发一个新的功能时，在
feature-branch分支上做了一些修改，并且已经提交了这些更改。但突然发现其中一个修复了一个紧急bug的提交也适用于主分支main。这时，如果你不想把整个feature-branch的所有更改都合并到main上，而是只想把这个特定的修复应用到main上，就可以使用git cherry-pick来实现这一点。具体操作步骤如下：
- 首先切换到你想要应用该提交的目标分支，比如
main。- 使用
git log查看历史提交记录，找到那个需要被"摘取"的提交的哈希值（一串由字母和数字组成的字符串）。- 然后运行
git cherry-pick <commit-hash>命令，其中<commit-hash>就是你刚刚找到的那个提交的哈希值。- Git 会尝试将这个提交的内容应用到当前分支上。如果一切顺利的话，现在你的
main分支就包含了那个特定的bug修复了。
总之，git cherry-pick提供了一种灵活的方式来选择性地迁移代码变更，非常适合处理那些只希望在特定上下文中应用的改动。
4、git merge（合并）VS git rebase（变基）
fetch VS pull
| 命令 | 作用 | 是否修改工作区 |
|---|---|---|
| git fetch | 只下载远程的最新信息，更新远程跟踪分支 | 不修改 |
| git pull | 下载远程信息并合并到当前分支 | 可能修改 |
简单来说：fetch 让你知道代码发生了什么变化，pull 让你的代码跟远程保持一致
养成先 fetch 检查，然后决定是否 merge（合并）的习惯
merge VS rebase
Git Merge
- 作用 ：当你有两个分支（比如主分支main和一个特性分支feature），并且你想要把特性分支的更改合并到主分支时，使用
git merge。- 结果：它会在主分支上创建一个新的"合并提交"（merge commit），这个提交包含了两个分支的所有改动。这样，你的历史记录里会显示出两个分支是如何合在一起的。
- 优点：保留了每个分支的历史记录，可以很清楚地看到哪些改动是哪个分支引入的。
- 缺点：项目的历史记录可能会变得比较复杂，特别是频繁合并的情况下。
Git Rebase
- 作用 ：同样是将一个分支的更改应用到另一个分支上，但方法不同。
git rebase会把你的特性分支里的每一个提交都重新创建在主分支的最新提交之上。- 结果：看起来就像你在主分支的最新状态上直接做了这些改动一样，不会产生额外的合并提交。
- 优点：使项目的历史记录更加线性和整洁，更容易理解。
- 缺点：修改了提交历史，如果这些提交已经被推送到远程仓库并被其他人拉取过，那么这样做可能会导致一些问题。
总结
- 如果你希望保持清晰的历史记录，并且不介意多出来的合并提交，就用
git merge。- 如果你喜欢简洁的历史记录，而且确定你的本地更改还没有被其他人依赖，那么可以选择
git rebase。