当前位置:   article > 正文

Git进阶系列 | 7. Git中的Cherry-pick提交_git cherry

git cherry

Git是最流行的代码版本控制系统,这一系列文章介绍了一些Git的高阶使用方式,从而帮助我们可以更好的利用Git的能力。本系列一共8篇文章,这是第7篇。原文:Cherry-Picking Commits in Git[1]

本系列的第5部分中,讨论了rebase和merge。虽然git mergegit rebase之间有一些不同,但这两个命令的目标是相同的: 将一个分支的更改集成到另一个分支。

今天我们来看看git cherry-pick,理解它是怎样允许我们将任何分支中被选中的、单独的提交集成到当前的HEAD分支中。这与git mergegit rebase有很大的区别,两者都只能集成来自指定分支的所有新提交。

那么为什么要从一个分支中只选择一个提交集成到另一个分支呢?当然会有不同的原因,但其中一个特别的原因是撤消变更。假设我们不小心在错误的分支上做了一个提交,使用cherry-pick处理就不会有什么大问题。我们可以切换到正确的分支,然后cherry-pick对于的提交。

Git进阶系列:

  1. 创建完美的提交
  2. Git中的分支策略
  3. 基于Pull Request实现更好的协作
  4. 合并冲突
  5. Rebase vs Merge
  6. 交互式Rebase
  7. Git中的Cherry-pick提交(本文)
  8. 用Reflog恢复丢失的提交

在看实例之前,先警告一下: 不要对cherry-pick太过兴奋。你的主要目标应该是在分支级别工作,git mergegit rebase都是为次构建的。cherry pick只是为了特殊场合,而不是为了代替merge和rebase。

将提交移到另一个分支
alt

我们通过一个真实的场景来解释什么时候cherry pick才是正确的。假设我们向master分支提交了一些本打算用于feature/newsletter的内容。现在怎么办?需要打电话给团队成员或老板来解释这个“错误”吗?

下面的截图显示了这个问题,以及在master分支上意外提交的26bf1b48

alt

或者,如果在终端输入git log,可以在命令行看到这一情况:

$ git log
commit 26bf1b4808ba9783e4fabb19ec81e7a4c8160194 (HEAD -> master)
Author: Tobias Günther
Date:   Fri Oct 5 09:58:03 2018 +0200

    Newsletter signup page
  • 1

可以看到,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
  • 1

再次运行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
  • 1

这背后发生了什么?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
  • 1

就像什么都没发生过一样。

如果使用像Tower这样的GUI应用,整个过程是这样的:

alt
用于特殊情况的工具,而不是日常的集成

只要可以使用传统的merge或rebase,就应该这样做。Cherry pick应该只在git mergegit 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 -

本文由 mdnice 多平台发布

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/你好赵伟/article/detail/516884
推荐阅读
相关标签
  

闽ICP备14008679号