[解決済み】Git Cherry-pickとMergeのワークフロー

質問

私がレポのメンテナで、ある貢献者から変更を取り込みたいと仮定した場合、いくつかの可能なワークフローがあります。

1. I cherry-pick の各コミットをリモートから（順番に）実行します。この場合、git はそのコミットをリモートブランチとは無関係なものとして記録します。
2. I merge ブランチを変更し、すべての変更を取り込み、(必要なら) 新しい "conflict" コミットを追加します。
3. I merge リモートブランチの各コミットを個別に (また順番に) 処理することで、コンフリクトをひとつにまとめるのではなく、コミットごとに記録することができます。
4. 完全を期すには rebase (と同じ）。 cherry-pick というオプションがありますが、私の理解では、これは投稿者を混乱させる可能性があります。もしかしたら、選択肢1はなくなるかもしれませんね。

2と3の場合、1とは異なり、gitはコミットのブランチ履歴を記録します。

を使用することの長所と短所を教えてください。 cherry-pick または merge のメソッドを記述していますか？ 私の理解では、方法2が普通だと思いますが、大きなコミットを単一の "conflict"マージで解決するのは、最もクリーンな解決策ではないと感じます。

どのように解決するのですか？

両方 rebase (そして cherry-pick ) と merge は、それぞれメリットとデメリットがあります。 私は merge では、その両方を理解することが大切です。 (しかし、どちらも理解する価値があります。 答え というケースを列挙しています。 rebase が望ましいとされています)。

merge よりも優先されます。 cherry-pick と rebase という2つの理由からです。

1. ロバスト性 . コミットの SHA1 識別子は、それ自体を識別するだけでなく、次のような特徴もあります。 との関係で そのコミットより前に行われた他のすべてのコミット これは、あるSHA1におけるリポジトリの状態が、すべてのクローン間で同一であることを保証するものです。 誰かが同じ変更のように見えても、実はリポジトリを破損したり乗っ取ったりしている可能性は（理論上は）ありません。 個々の変更点を拾い上げれば、同じである可能性はありますが、保証はありません。 (二次的な問題として、チェリーピックされた新しいコミットは、他の誰かが同じコミットをチェリーピックした場合、履歴に残ってしまい、たとえ作業コピーが同一であっても余分なスペースを取ってしまいます)。
2. 使い勝手の良さ . を理解される傾向があります。 merge のワークフローはかなり簡単です。 rebase は、より高度なものとみなされる傾向があります。 両方を理解するのが一番ですが、バージョン管理の専門家になりたくない人（私の経験では、すごく優秀だけど余計な時間をかけたくない同僚がたくさんいます）は、マージだけの方が簡単です。

マージを多用したワークフローでも rebase と cherry-pick は、特定のケースではまだ有用である。

1. の欠点は merge は、履歴が乱雑になる。 rebase は、定期的に他の人の変更をマージした場合のように、一連の長いコミットが履歴に散乱するのを防ぎます。 実際、私が使っているときの主な目的はこれです。 あなたが望むものは 非常に を決して行わないことです。 rebase のコードを他のリポジトリと共有することができます。 一度コミットした内容は push リベースは、せいぜい上記で説明したような重複を引き起こす程度です。 最悪の場合、リポジトリが非常に混乱し、微妙なエラーを発見するのに長い時間がかかることになります。
2. cherry-pick は、基本的に破棄することに決めたトピックブランチから、小さな変更点の一部を抜き出すのに便利です。

1つの変更より多くの変更をマージする方がいいということについては、その方がずっとシンプルだからです。 チェンジセットが大量にあると、個々のチェンジセットをマージするのが非常に面倒になります。 git (そして Mercurial や Bazaar) のマージ処理は非常に優れています。 長いブランチでも、たいていの場合、マージに大きな問題は発生しないでしょう。 私は通常、すべてを一度にマージしますが、その際には もし 大量のコンフリクトが発生した場合は、バックアップをとって、マージを少しずつ再実行します。 その場合でも、大きな塊で行います。 実際の例として、3ヶ月分の変更をマージする同僚がいましたが、2万5千行のコードベースで9000ものコンフリクトが発生しました。 コンフリクトは直線的に蓄積されるものではないので、断片的に行うと はるかに コンフリクトは9000件以下です。 それでも大変な作業でしたが、一度に1コミットずつ行うのに比べれば大したことはありません。