背景描述：有的時候基于一個master branch拉出一個獨立feature分支做開發時，兩條分支都在并行開發，如果master分支增加了某些功能，解決了某些關鍵bug，而獨立feature分支不需要所有的增加的commit，只需要某一筆的修復，此時首先想到的就是單獨cherry-pick該筆commit，然而后續如果再次將該feature merge回master，“奇怪”的現象發生了….

舉例說明：

git倉庫以ngnix代碼為例，不知道什么時候clone的代碼，分支還在unstable branch上。。。

• 以unstable分支為基礎checkout一個test1分支。
• 在unstable分支上提交一筆commit bb3200604fcd3cefe26fb23bd6747f5563f514ac
• 在test1 branch上cherry-pick該筆commit，commit id為9b97d6038a14e348f50a7b44f2a0a29af54aa820

• 回到unstable分支，merge test1 branch，出現下面的現象：

  

為什么感到”奇怪“

• 起初我的想法時merge合并后，不會出現merge commit，也只會存在同樣的一筆commit，這樣看起來會很清爽，而如果出現兩筆一模一樣的commit，看起來會很疑惑。雖然代碼沒有任何問題，而且如果在提交多筆commit后再merge，大部分人都不會主要到這個現象，所以應該很少人主要到這個“問題”。
• 由于個人多少對代碼有點潔癖，當發現這個現象時蠻奇怪的，為什么git不能智能記錄兩個branch cherry-pick的過程，在merge時只保留一個（最好是master branch上的）commit？（這點是完全可以做到的啊），不過事實就是目前的狀態了。

為什么會這樣？

• cherry-pick在Git中的處理應該只是將一個commit的修改重新add， commit，push到另一個branch上，并沒有記錄之間的關聯。
• 當merge時，認為另外一個branch只是做了完全相同的修改，并沒有沖突，所以完整的保留兩個branch上的commit。

后續如何處理

• 雖然以上的解釋很充分，原理上完全沒有問題，不過對于這樣的兩筆一模一樣的commit，感官上還是不爽的，所以我決定盡量不在需要merge回去的branch上cherry-pick父branch上的commit了。