Git 进阶系列 | 7. Git 中的 Cherry-pick 提交
Git 是最流行的代码版本控制系统,这一系列文章介绍了一些 Git 的高阶使用方式,从而帮助我们可以更好的利用 Git 的能力。本系列一共 8 篇文章,这是第 7 篇。原文:Cherry-Picking Commits in Git[1]
在本系列的第5部分中,讨论了 rebase 和 merge。虽然git merge
和git rebase
之间有一些不同,但这两个命令的目标是相同的: 将一个分支的更改集成到另一个分支。
今天我们来看看git cherry-pick
,理解它是怎样允许我们将任何分支中被选中的、单独的提交集成到当前的HEAD
分支中。这与git merge
或git rebase
有很大的区别,两者都只能集成来自指定分支的所有新提交。
那么为什么要从一个分支中只选择一个提交集成到另一个分支呢?当然会有不同的原因,但其中一个特别的原因是撤消变更。假设我们不小心在错误的分支上做了一个提交,使用 cherry-pick 处理就不会有什么大问题。我们可以切换到正确的分支,然后 cherry-pick 对于的提交。
Git 进阶系列:
Git 中的 Cherry-pick 提交(本文)
用 Reflog 恢复丢失的提交
在看实例之前,先警告一下: 不要对 cherry-pick 太过兴奋。你的主要目标应该是在分支级别工作,git merge
和git rebase
都是为次构建的。cherry pick 只是为了特殊场合,而不是为了代替 merge 和 rebase。
将提交移到另一个分支
我们通过一个真实的场景来解释什么时候 cherry pick 才是正确的。假设我们向master
分支提交了一些本打算用于feature/newsletter
的内容。现在怎么办?需要打电话给团队成员或老板来解释这个“错误”吗?
下面的截图显示了这个问题,以及在master
分支上意外提交的26bf1b48
。
或者,如果在终端输入git log
,可以在命令行看到这一情况:
可以看到,ID 为26bf1b48
的提交最终合并到了master
中,但其实应该提交到分支feature/newsletter
中。我们需要选择特定的提交并将其移到正确的分支。首先切换分支,然后选择提交:
再次运行git log
,可以在feature/newsletter
分支上看到新的提交:
这背后发生了什么?Git 在feature/newsletter
分支上创建了一个具有相同更改的提交副本以及相同的提交信息。然而,这是一个有着新 ID 的全新提交。那么最初的提交呢?
清理其他分支
如果检查master
分支,仍然可以看到“错误的”提交。这意味着 cherry pick 不会从原来的分支“移动”被选中的提交,而只是创建一个副本,不会影响原始文件。
现在,为了清理和撤销提交,可以使用git reset
。
就像什么都没发生过一样。
如果使用像 Tower 这样的 GUI 应用,整个过程是这样的:
用于特殊情况的工具,而不是日常的集成
只要可以使用传统的 merge 或 rebase,就应该这样做。Cherry pick 应该只在git merge
或git rebase
没用的情况下才用,比方说想要从一个分支把某个提交移到另一个。记住,git cherry-pick
创建了“重复”的提交,应该在之后进行清理。
如果想更深入了解高级 Git 工具,可以免费查看“Advanced Git Kit[3]”: 这是关于分支策略、交互式 Rebase、Reflog、子模块等主题的短视频集合。
References:
[1] Cherry-Picking Commits in Git: https://css-tricks.com/cherry-picking-commits-in-git/
你好,我是俞凡,在 Motorola 做过研发,现在在 Mavenir 做技术工作,对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣,平时喜欢阅读、思考,相信持续学习、终身成长,欢迎一起交流学习。
微信公众号:DeepNoMind
- END -
版权声明: 本文为 InfoQ 作者【俞凡】的原创文章。
原文链接:【http://xie.infoq.cn/article/c137cd94268cfe4e189aa2394】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论