HEAD 的理解
-
HEAD 指向当前所在的分支,类似一个活动的指针,表示一个「引用」。例如当前在 develop 分支,HEAD 内容就是 ref: refs/heads/develop。
-
HEAD 既可以指向「当前分支」的最新 commit,也可以指向历史中的某一次 commit (「分离头指针」的情况)。归根结底,HEAD 指向的就是某个提交点。
-
当我们做分支切换时,HEAD 会跟着切换到对应分支。
cherry-pick 的理解
我们代码库中的一个个 commit 可以看做一个个 cherry。同一个代码库中的 commit-id 往往是唯一的,当你在分支 B 上也需要在分支 A 上的提交内容时,就可以将它们 cherry-pick 过来(樱桃摘)!
仓库进行示例演示
- 代码库有三个分支:master、feature-a、feature-b
- master 分支处于 60b9dae0
- feature-a基于 master 分支创建后,进行了三次提交,commit-id 分别是:
- 1699fefcafb5323691b1bde9f72c1425eadc985b
- 30d26c8c3a47653a075da36c81081ad334b7ce11
- f24a02738142cb97be5d9cd9b379baf4c810ea00
feature-b 特性分支b,当前处于 a3f7c8b2,这里是为了测试的时候方便恢复
从 feature-a 分支选择 2 个提交合入 feature-b
首先解决一个疑问,可能有同学会说,为何不采用 merge进行分支的合并呢?
因为,并不是每个场景都是可以进行分支的合并的。比如,这两个分支就是不同的发布分支,一个是版本 1.0.0 的分支,一个是版本 2.0.0 的分支,这两个版本分支是需要独立保存的,将它们进行合并就不合适。这时候有一个 bug 是它俩都有的,需要修复。使用 cherry-pick 就可以仅仅将你在一个分支上修复的内容筛选出来,另一个分支上也修该相关文件解决 bug!
即:优选合并
看🌰:我现在需要将我在feature-a 分支上的两次提交 1699fefc(第一次提交) 和 30d26c8c (第三次提交)改动的内容也在 feature-b 上进行修改提交:
命令
# 切换到 feature-b 分支
git checkout feature-b
# 挑选 commit
git cherry-pick 1699fefc 30d26c8c
idea演示
- 选中featrue-a第一次提交记录右键点击Cherry-Pick(如图)
- 点击Cherry-Pick后,会把featrue-a第一次提交记录同步到featrue-b工作区中
- 选择特定文件
- 解决冲突推送
- git log 可以看出featrue-b多出2次提交记录
注意
如果有冲突需要重新提交推送;没有冲突直接推送即可
Stash 暂存区理解
现有代码先藏起来,用的时候找再出来。
假设我们现在dev分支开发写了很多业务代码,这时生产环境master出现严重bug需要急需修复。我们一般会在master分支拉一个新分支进行修复,例如fix_001分支。但是这个时候,dev分支有我们已经写的半成品代码(不完整,没法提交)。这个时候我们可以把半成品代码暂存起来,等用的时候再找回来。
- featrue-a分支代码图示
- 创建Stash
- 创建Stash后,修改的代码还原到上次提交状态
- 修改好bug后,可以恢复
- 还原后的代码
线上回滚强推
- idea图示操作
- 点击确认
- 点击还原
- 选择强推