GitFlow 分支管理模型的理论基础与实战操作。核心内容包括 master、develop、feature、release、hotfix 五种分支角色的定义与流转关系。通过图文步骤演示了从分支初始化、功能开发、发布准备到紧急修复的全流程。此外还涵盖了版本回退、git stash 临时存储、cherry-pick 选择性合并以及 merge 与 rebase 的区别对比，帮助开发者建立规范的协作流程。
GitFlow 是一种基于 Git 的分支管理模型（Branching Model），由 Vincent Driessen 提出，用来规范等场景下的 Git 使用方式。
一套'大家都按同一规则来建分支、合并、发版'的工作流程
在实际开发中，经常会遇到这些痛点：
GitFlow 的目标就是：让开发、测试、发布、维护都'有章可循'
GitFlow 定义了 5 种常见分支角色，其中 2 个长期分支 + 3 个临时分支。
v1.0.0 v1.1.0
📌 可以理解为：
'下一版本正在开发中的代码'
develop 拉出develop📌 示例：
feature/login feature/order-pay
👉 你日常写代码，90% 都在 feature 分支
develop 拉出masterdevelop📌 示例：
release/1.2.0
master 拉出masterdevelop📌 示例：
hotfix/fix-null-pointer
一句话总结：
存在一个 master 分支
新建 develop 分支
产品经理新建
开发人员新建
好处：其他分支是不受影响的
featureA 分支上修改代码，并提交到远程仓库看效果
可以看到 featureB 分支没有任何改动
将 develop 分支检出到本地
将刚才本地完成的 featureA 分支功能合并到 develop 分支
本地 develop 分支 push 到远程 develop 分支
新需求完成后删除本地 featureA 分支，远程可删可不删
运维或者测试新建 release 分支，以 develop 分支作为起点
打开 IDEA git pull 同步分支，然后将 release-0.1.0 分支从 remote 检出到 local
一般而言，发布新版本或多或少会在 release 分支上改改配置/IP/密码/页面等小动作，作为发布准备工作修改完成后，add->commit->push 到远程仓库
release-0.1.0 分支内容合并到 master 分支
打个 tag
创建发行版
release-0.1.0 分支内容合并进 develop 分支
全部发布完成后可以考虑删除 release 分支
切换到 master 分支，在 master 分支上新建 hotfix-0.1.0 分支
add->commit->push 到远程仓库
bug 修复完成后需要将 hotfix 分支合并进 master 分支切换到 master 分支 merge 合并 hotfix 分支 push 推送到远程仓库
tag 打个自增标签作为修复 bug 版本
bug 修复完成后需要将 hotfix 分支合并进 develop 分支
操作完成后可以考虑删除 hotfix-0.1.0 分支
代码有改动，无 add、无 commit、无 push
代码有改动，有 add、无 commit、无 push
代码有改动，有 add、有 commit、无 push
代码有改动，有 add、有 commit、有 push 本次 push 作废
只是撤销本地，远程还有需要在 push 一下提交远程撤销刚才的提交
想象一下你在写作业（代码），突然老师叫你去帮忙搬个东西。这个时候你的作业还没写完，桌上堆了一堆草稿纸和半成品，但又不能就这么放着不管，因为别人可能要用这个桌子。怎么办呢？
git stash就像是一个临时的抽屉，你可以把桌面上所有的东西（包括那些没完成的工作）都快速地收起来放进这个抽屉里，然后桌面就干净了，你可以放心地去做别的事情（比如切换到另一个任务或分支）。等你回来的时候，只需要打开这个抽屉，就能把之前收起来的东西再拿出来继续工作。
具体来说，在 Git 中使用git stash命令可以把当前工作区中未提交的修改保存起来，这样你就可以切换分支或者做其他操作而不用担心丢失这些修改。当你需要恢复这些修改时，可以使用git stash apply或git stash pop来取回它们。这就像把东西从抽屉里重新拿出来放到桌子上一样。
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提供了一种灵活的方式来选择性地迁移代码变更，非常适合处理那些只希望在特定上下文中应用的改动。
| 命令 | 作用 | 是否修改工作区 |
|---|---|---|
| git fetch | 只下载远程的最新信息，更新远程跟踪分支 | 不修改 |
| git pull | 下载远程信息并合并到当前分支 | 可能修改 |
简单来说：fetch 让你知道代码发生了什么变化，pull 让你的代码跟远程保持一致
养成先 fetch 检查，然后决定是否 merge（合并）的习惯
Git Merge作用：当你有两个分支（比如主分支 main 和一个特性分支 feature），并且你想要把特性分支的更改合并到主分支时，使用
git merge。结果：它会在主分支上创建一个新的'合并提交'（merge commit），这个提交包含了两个分支的所有改动。这样，你的历史记录里会显示出两个分支是如何合在一起的。优点：保留了每个分支的历史记录，可以很清楚地看到哪些改动是哪个分支引入的。缺点：项目的历史记录可能会变得比较复杂，特别是频繁合并的情况下。Git Rebase作用：同样是将一个分支的更改应用到另一个分支上，但方法不同。git rebase会把你的特性分支里的每一个提交都重新创建在主分支的最新提交之上。结果：看起来就像你在主分支的最新状态上直接做了这些改动一样，不会产生额外的合并提交。优点：使项目的历史记录更加线性和整洁，更容易理解。缺点：修改了提交历史，如果这些提交已经被推送到远程仓库并被其他人拉取过，那么这样做可能会导致一些问题。总结如果你希望保持清晰的历史记录，并且不介意多出来的合并提交，就用git merge。如果你喜欢简洁的历史记录，而且确定你的本地更改还没有被其他人依赖，那么可以选择git rebase。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML转Markdown 互为补充。 在线工具，Markdown转HTML在线工具，online
将 HTML 片段转为 GitHub Flavored Markdown，支持标题、列表、链接、代码块与表格等；浏览器内处理，可链接预填。 在线工具，HTML转Markdown在线工具，online
通过删除不必要的空白来缩小和压缩JSON。 在线工具，JSON 压缩在线工具，online
将JSON字符串修饰为友好的可读格式。 在线工具，JSON美化和格式化在线工具，online