HEAD 指向当前所在的分支,类似一个活动的指针,表示一个「引用」。例如当前在 develop 分支,HEAD 内容就是 ref: refs/heads/develop。
HEAD 既可以指向「当前分支」的最新 commit,也可以指向历史中的某一次 commit (「分离头指针」的情况)。归根结底,HEAD 指向的就是某个提交点。
当我们做分支切换时,HEAD 会跟着切换到对应分支。
我们代码库中的一个个 commit 可以看做一个个 cherry。同一个代码库中的 commit-id 往往是唯一的,当你在分支 B 上也需要在分支 A 上的提交内容时,就可以将它们 cherry-pick 过来(樱桃摘)!
仓库进行示例演示
feature-b 特性分支b,当前处于 a3f7c8b2,这里是为了测试的时候方便恢复
首先解决一个疑问,可能有同学会说,为何不采用 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演示
如果有冲突需要重新提交推送;没有冲突直接推送即可
参考链接
现有代码先藏起来,用的时候找再出来。
假设我们现在dev分支开发写了很多业务代码,这时生产环境master出现严重bug需要急需修复。我们一般会在master分支拉一个新分支进行修复,例如fix_001分支。但是这个时候,dev分支有我们已经写的半成品代码(不完整,没法提交)。这个时候我们可以把半成品代码暂存起来,等用的时候再找回来。