Git cherry-pick二三事

前天在工做中踩了個cherry-pick的坑，因此抽時間寫個關於cherry-pick的用法記錄下。

簡介

在實際的開發工做中常常會遇到以下狀況：

圖中的abcdefgh表示不一樣的commmit節點， 在c節點時咱們創建出了2個不一樣的feature branch -- feature1和feature2來分別進行特性開發， 在工做中可能遇到，feature1分支開發裏須要使用到commit g中所提交的內容，實現以下的效果:

這時候就要用到cherry-pick的功能。換言之，cherry-pick的做用就是把某個特定的 commit 內容，應用到當前分支上。

基本用法

基本命令以下：

git cherry-pick <commitId>

這裏的commitId就好比上述場景裏的節點g對應的commit id，能夠在git log命令，或者使用gitlab頁面或者其餘git工具裏查到。

進階用法

cherry pick 一樣能夠pick多個commit

• 若是是要pick獨立的幾個commit，可使用以下命令：

git cherry-pick <commitId1>  <commitId2> <commitId3>

• 若是是須要pick兩個commit之間的全部的提交，則可使用以下命令

git cherry-pick <commitId m>..<commitId n> // pick m 到 n 之間的全部commit，不包括m，包括n
git cherry-pick <commitId m>^..<commitId n> // pick m 到 n 之間的全部commit，包含m，包括n

固然，這裏的m n必須是按照時間順序的， m必須在n以前提交。

注意事項

有必要提到的一個參數是 -n， 是--no-commit的縮寫。 默認狀況下git cherry-pick <commitId>命令會完成如下如下事情：

1. 將特定commit裏的改動運用到當前分支；
2. 在當前分支上當即作一次commit,commit message即commit id對應的那次commit。

第一點沒有疑問，可是第二點這個功能若是不注意（尤爲是習慣使用小烏龜，source tree之類的朋友）進行cherry-pick時，若是沒仔細看的話，在某些場景下很容易出問題，舉個例子：

對於某些項目組，項目的開發週期劃分比較清晰，代碼的提交階段分爲通常開發階段，迴歸測試fix階段等等，這種劃分會體如今commit message的前綴裏,假設規則以下：

1. 開發階段的全部commit message必須是DEV:xxxxx的形式，xxx是具體的提交內容；
2. 迴歸測試階段，全部commit message必須RT:xxx形式，xxx是具體的提交內容；

（這類規則在大型項目裏比較常見，能夠比較方便地作一些管理和統計，好比避免在迴歸階段作新功能開發等等），接下來就是重點了:

若是咱們在迴歸測試階段遇到一個bug須要fix，而且在fix過程發現有一些改動時能夠借用其餘分支在開發階段某次commit的內容。這時候很天然地，咱們會想到使用cherry-pick，可是這時候若是不使用 -n參數，就會致使把開發階段的commit message，提交到RT階段。（前車可鑑，但願你們不要像我同樣犯這種錯誤-_-） 因此很是建議每次使用 cherry-pick都帶上-n參數，即只保留文件改動,不作額外commit

小結

本文針對cherry-pick在實際工做的基本用法和一些注意事項進行一個簡單的介紹。一轉眼就年末了，但願你們工做順利，開開心心。

慣例：若是內容有錯誤的地方歡迎指出（以爲看着不理解不舒服想吐槽也徹底沒問題）；若是有幫助，歡迎點贊和收藏，轉載請徵得贊成後著明出處，若是有問題也歡迎私信交流，主頁有郵箱地址