共计 2447 个字符,预计需要花费 7 分钟才能阅读完成。
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 中的分支策略
- 基于 Pull Request 实现更好的合作
- 合并抵触
- Rebase vs Merge
- 交互式 Rebase
- Git 中的 Cherry-pick 提交(本文)
- 用 Reflog 复原失落的提交
在看实例之前,先正告一下: 不要对 cherry-pick 太过兴奋。你的次要指标应该是在分支级别工作,git merge
和 git rebase
都是为次构建的。cherry pick 只是为了非凡场合,而不是为了代替 merge 和 rebase。
将提交移到另一个分支
咱们通过一个实在的场景来解释什么时候 cherry pick 才是正确的。假如咱们向 master
分支提交了一些本打算用于 feature/newsletter
的内容。当初怎么办?须要打电话给团队成员或老板来解释这个“谬误”吗?
上面的截图显示了这个问题,以及在 master
分支上意外提交的26bf1b48
。
或者,如果在终端输出git log
,能够在命令行看到这一状况:
$ git log
commit 26bf1b4808ba9783e4fabb19ec81e7a4c8160194 (HEAD -> master)
Author: Tobias Günther
Date: Fri Oct 5 09:58:03 2018 +0200
Newsletter signup page
能够看到,ID 为 26bf1b48
的提交最终合并到了 master
中,但其实应该提交到分支 feature/newsletter
中。咱们须要抉择特定的提交并将其移到正确的分支。首先切换分支,而后抉择提交:
$ git checkout feature/newsletter
Switched to branch 'feature/newsletter'
$ git status
On branch feature/newsletter
nothing to commit, working tree clean
$ git cherry-pick 26bf1b48
[feature/newsletter 7fb55d0] Newsletter signup page
Author: Tobias Günther <tg@fournova.com>
Date: Fri Oct 5 09:58:03 2018 +0200
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 signup.html
再次运行 git log
,能够在feature/newsletter
分支上看到新的提交:
$ git log
commit 7fb55d06a8e70fdce46921a8a3d3a9de7f7fb8d7 (HEAD -> feature/newsletter)
Author: Tobias Günther <tg@fournova.com>
Date: Fri Oct 5 09:58:03 2018 +0200
Newsletter signup page
这背地产生了什么?Git 在 feature/newsletter
分支上创立了一个具备雷同更改的提交正本以及雷同的提交信息。然而,这是一个有着新 ID 的全新提交。那么最后的提交呢?
清理其余分支
如果查看 master
分支,依然能够看到“谬误的”提交。这意味着 cherry pick 不会从原来的分支“挪动”被选中的提交,而只是创立一个正本,不会影响原始文件。
当初,为了清理和撤销提交,能够应用git reset
。
$ git checkout master
Switched to branch 'master'
$ git reset --hard HEAD~1
HEAD is now at 776f8ca Change about title and delete error page
就像什么都没产生过一样。
如果应用像 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
本文由 mdnice 多平台公布