如何進(jìn)行cherry-pick的分析

如何進(jìn)行cherry-pick的分析，相信很多沒有經(jīng)驗(yàn)的人對(duì)此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個(gè)問題。

盡管Kubernetes擁有眾多分支，但社區(qū)主要圍繞在master分支進(jìn)行開發(fā)。即便其他分支存在bug，通常也是先在master分支進(jìn)行修復(fù)，然后再cherry-pick到其他分支。

軟件開發(fā)不可避免的會(huì)出現(xiàn)bug，所以經(jīng)常需要從master同步一些補(bǔ)丁到其他仍在維護(hù)的分支。而同步的手段可以有多種：

• 手動(dòng)提交PR到其他分支；

• 自動(dòng)提交PR到其他分支；

一般來說，自動(dòng)提交的方式更普遍，它能把某個(gè)master已合入的PR自動(dòng)cherry-pick到你指定的分支上，而手動(dòng)提交只有在極少數(shù)情況下才會(huì)使用。

自動(dòng)cherry-pick

使用Kubernetes倉庫中hack/cherry_pick_pull.sh腳本可以把一個(gè)合入到master分支的PR同步到其他分支。它可以幫你自動(dòng)完成提交PR的所有過程。

前提條件

使用hack/cherry_pick_pull.sh自動(dòng)同步需要滿足一定的前提條件：

• 你必須已經(jīng)簽署了CLA聲明，這也是每個(gè)貢獻(xiàn)者必須要簽署的內(nèi)容；

• 針對(duì)master的PR已經(jīng)被合入；

• 你的Github帳號(hào)中已經(jīng)fork了Kubernetes倉庫，并且你本地的shell中已經(jīng)clone了此fork倉庫；

• 你本的倉庫中必須添加的遠(yuǎn)端倉庫名為upstream(通過命令 git remote add upstream https://github.com/kubernetes/kubernetes.git)；

• 在你環(huán)境變量中添加了export GITHUB_USER=<GitHub ID>；

• 已安裝了hub命令行工具；

如果你已經(jīng)參與過代碼貢獻(xiàn)，那么這些要求一般都會(huì)自動(dòng)滿足，除了最后兩個(gè)。

hub命令行工具為GitHub官方提供的工具，用于從命令行操作GitHub。而環(huán)境變量中需要添加GITHUB_USER正是因?yàn)閔ub命令行工具會(huì)使用。如果你還沒有安裝，可以使用命令go get github.com/github/hub安裝它。

如何自動(dòng)cherry-pick

比如，需要將master上的PR #85444 同步到分支 release-1.17，在前面條件都具備的情況下，只需要使用如下命令：

hack/cherry_pick_pull.sh upstream/release-1.17 85444

注意：此腳本會(huì)自動(dòng)創(chuàng)建PR，不要輕易嘗試，除非你真的需要這么做。

腳本執(zhí)行過程中會(huì)有大量信息輸出，可以了解到具體執(zhí)行過程：

[root@ecs-d8b6 kubernetes]# hack/cherry_pick_pull.sh upstream/release-1.17 85444
+++ Updating remotes...
Fetching upstream
remote: Enumerating objects: 34, done.
remote: Counting objects: 100% (34/34), done.
remote: Total 48 (delta 34), reused 34 (delta 34), pack-reused 14
Unpacking objects: 100% (48/48), done.
From https://github.com/kubernetes/kubernetes
   d87c921a516..1f913b45820  master       -> upstream/master
   c0f31a4ef63..5c651b7bd5f  release-1.16 -> upstream/release-1.16
   486425533b6..27babd49b95  release-1.17 -> upstream/release-1.17
 * [new tag]                 v1.17.0-rc.1 -> v1.17.0-rc.1
Fetching origin
+++ Creating local branch automated-cherry-pick-of-#85444-upstream-release-1.17-1574748271
Branch 'automated-cherry-pick-of-#85444-upstream-release-1.17-1574748271' set up to track remote branch 'release-1.17' from 'upstream'.
Switched to a new branch 'automated-cherry-pick-of-#85444-upstream-release-1.17-1574748271'
+++ Downloading patch to /tmp/85444.patch (in case you need to do this again)

+++ About to attempt cherry pick of PR. To reattempt:
  $ git am -3 /tmp/85444.patch

Applying: Provided a mechanism to re-register hidden metrics.

+++ I'm about to do the following to push to GitHub (and I'm assuming origin is your personal fork):

  git push origin automated-cherry-pick-of-#85444-upstream-release-1.17-1574748271:automated-cherry-pick-of-#85444-upstream-release-1.17

+++ Proceed (anything but 'y' aborts the cherry-pick)? [y/n] y
Enumerating objects: 19, done.
Counting objects: 100% (19/19), done.
Delta compression using up to 4 threads
Compressing objects: 100% (10/10), done.
Writing objects: 100% (10/10), 2.19 KiB | 1.09 MiB/s, done.
Total 10 (delta 8), reused 0 (delta 0)
remote: Resolving deltas: 100% (8/8), completed with 8 local objects.
remote: 
remote: Create a pull request for 'automated-cherry-pick-of-#85444-upstream-release-1.17' on GitHub by visiting:
remote:      https://github.com/RainbowMango/kubernetes/pull/new/automated-cherry-pick-of-%2385444-upstream-release-1.17
remote: 
To https://github.com/RainbowMango/kubernetes.git
 * [new branch]              automated-cherry-pick-of-#85444-upstream-release-1.17-1574748271 -> automated-cherry-pick-of-#85444-upstream-release-1.17

+++ Creating a pull request on GitHub at RainbowMango:automated-cherry-pick-of-#85444-upstream-release-1.17
https://github.com/kubernetes/kubernetes/pull/85627

+++ Returning you to the master branch and cleaning up.

實(shí)際上該腳本實(shí)際上模擬了手工操作:

• 創(chuàng)建一個(gè)本地分支，比如automated-cherry-pick-of-#85444-upstream-release-1.17;

• 通過hub工具獲取PR的commit信息（可能有多個(gè)commit）；

• 將upstream/master中相關(guān)的commit cherry-pick 到本地分支中；

• 將本地分支推送到遠(yuǎn)端（origin）;

• 使用GitHub的接口提交PR；

手動(dòng)cherry-pick

手動(dòng)cherry-pick一般不常發(fā)生，因?yàn)榇蠖鄶?shù)情況下自動(dòng)cherry-pick都可以勝任。只有在沖突比較大時(shí)，需要手工處理沖突時(shí)才會(huì)手動(dòng)cherry-pick。

手動(dòng)chery-pick，需要處理沖突，處理完成后提交PR的過程與向master提交完全一致，這里不再贅述。

提交到release分支的PR審核過程與提交到master分支的略有不同，提交到release分支的PR除了需要相關(guān)領(lǐng)域的approver批準(zhǔn)以外，還需要release manager批準(zhǔn)才可以合入。

提交到release分支的PR，自動(dòng)會(huì)被添加上do-not-merge/cherry-pick-not-approved標(biāo)簽，只有release manager批準(zhǔn)后才會(huì)去除該標(biāo)簽，然后CI才會(huì)合入該P(yáng)R。

看完上述內(nèi)容，你們掌握如何進(jìn)行cherry-pick的分析的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！