チェリーピックの作業後にgitはどのようにマージされますか？

masterブランチがあるとしましょう。

次に、 newbranch

git checkout -b newbranch

そして、2つの新しいコミットを作成しnewbranchます：commit1とcommit2

次にマスターに切り替えて cherry-pick

git checkout master
git cherry-pick hash_of_commit1

gitk調べてみると、commit1とその厳選されたバージョンではハッシュが異なるため、厳密には2つの異なるコミットであることがわかります。

最後にマージnewbranchしmasterます：

git merge newbranch

同じハッシュを2回適用する必要があることを示しているため、ハッシュが異なる2つのコミットが問題なくマージされたことを確認してください。

gitはマージ中に実際にコミットの内容をスマートに分析し、変更を2回適用しないようにするか、これらのコミットが内部でリンクされているとマークされていると判断しますか？

短い答え

心配しないで、Gitが処理します。

長い答え

たとえばSVN ¹とは異なり、Gitはコミットをデルタ形式で保存しませんが、スナップショットベースの^2,3です。SVNは単純に、マージされた各コミットをパッチとして適用しようとしますが（説明したとおりの理由で失敗します）、Gitは通常、このシナリオを処理できます。

マージするとき、Gitは両方のHEADコミットのスナップショットを新しいスナップショットに結合しようとします。コードの一部またはファイルが両方のスナップショットで同一である場合（つまり、コミットが既に厳選されているため）、Gitはそれに触れません。

出典

¹ Subversionのスキップデルタ
² Gitの基本
³ Gitオブジェクトモデル

そのようなマージの後、あなたは歴史の中で厳選されたコミットを二度持つかもしれません。

これを防ぐための解決策は、複製（チェリーピック）コミットのブランチを推奨する記事から引用し、マージ前にリベースを使用します。

git cherry-pick後のgit merge：重複したコミットを回避する

マスターブランチとブランチbがあるとします。

   o---X   <-- master
    \
     b1---b2---b3---b4   <-- b

ここで、マスターのコミットb1とb3が緊急に必要ですが、bの残りのコミットは必要ありません。マスターブランチをチェックアウトし、cherry-pickでb1とb3をコミットします。

$ git checkout master
$ git cherry-pick "b1's SHA"
$ git cherry-pick "b3's SHA"

結果は次のようになります。

   o---X---b1'---b3'   <-- master
    \
     b1---b2---b3---b4   <-- b

マスターで別のコミットを実行すると、次のようになります。

   o---X---b1'---b3'---Y   <-- master
    \
     b1---b2---b3---b4   <-- b

ブランチbをマスターにマージする場合：

$ git merge b

次のようになります。

   o---X---b1'---b3'---Y--- M  <-- master
     \                     /
      b1----b2----b3----b4   <-- b

つまり、b1とb3によって導入された変更は履歴に2回表示されます。これを回避するには、マージの代わりにリベースできます。

$ git rebase master b

これは次のようになります：

   o---X---b1'---b3'---Y   <-- master
                        \
                         b2'---b4'   <-- b

最後に：

$ git checkout master
$ git merge b

私たちに与える：

   o---X---b1'---b3'---Y---b2'---b4'   <-- master, b

EDIT David Lemonのコメントが想定する修正