GitFlow 分支管理模型详解与实战

📌 示例：

hotfix/fix-null-pointer 

一句话总结：

• feature → develop → release → master
• 紧急问题：master → hotfix → master + develop

GitFlow 实操

develop 分支初始化

存在一个 master 分支

新建 develop 分支

开发人员克隆项目到本地 IDEA

feature 分支新建

产品经理新建

开发人员新建

feature 分支多线并行开发后提交

好处：其他分支是不受影响的

featureA 分支上修改代码，并提交到远程仓库看效果

可以看到 featureB 分支没有任何改动

featureA 完成需求后合并到 develop 分支

将 develop 分支检出到本地

将刚才本地完成的 featureA 分支功能合并到 develop 分支

本地 develop 分支 push 到远程 develop 分支

新需求完成后删除本地 featureA 分支，远程可删可不删

release 分支 - 发布前

运维或者测试新建 release 分支，以 develop 分支作为起点

打开 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 分支内容合并进 develop 分支

全部发布完成后可以考虑删除 release 分支

hotfix 分支修复 BUG 合并 master 分支

切换到 master 分支，在 master 分支上新建 hotfix-0.1.0 分支

add->commit->push 到远程仓库

bug 修复完成后需要将 hotfix 分支合并进 master 分支切换到 master 分支 merge 合并 hotfix 分支 push 推送到远程仓库

tag 打个自增标签作为修复 bug 版本

hotfix 分支修复 BUG 合并 develop 分支

bug 修复完成后需要将 hotfix 分支合并进 develop 分支

• 切换到 develop 分支
• develop 合并 hotfix 分支
• push 推送到远程仓库

操作完成后可以考虑删除 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

简单来说：fetch 让你知道代码发生了什么变化，pull 让你的代码跟远程保持一致

养成先 fetch 检查，然后决定是否 merge（合并）的习惯

merge VS rebase

Git Merge作用：当你有两个分支（比如主分支 main 和一个特性分支 feature），并且你想要把特性分支的更改合并到主分支时，使用 git merge。结果：它会在主分支上创建一个新的'合并提交'（merge commit），这个提交包含了两个分支的所有改动。这样，你的历史记录里会显示出两个分支是如何合在一起的。优点：保留了每个分支的历史记录，可以很清楚地看到哪些改动是哪个分支引入的。缺点：项目的历史记录可能会变得比较复杂，特别是频繁合并的情况下。Git Rebase作用：同样是将一个分支的更改应用到另一个分支上，但方法不同。git rebase 会把你的特性分支里的每一个提交都重新创建在主分支的最新提交之上。结果：看起来就像你在主分支的最新状态上直接做了这些改动一样，不会产生额外的合并提交。优点：使项目的历史记录更加线性和整洁，更容易理解。缺点：修改了提交历史，如果这些提交已经被推送到远程仓库并被其他人拉取过，那么这样做可能会导致一些问题。总结如果你希望保持清晰的历史记录，并且不介意多出来的合并提交，就用 git merge。如果你喜欢简洁的历史记录，而且确定你的本地更改还没有被其他人依赖，那么可以选择 git rebase。