（マージする代わりに）チェリーピッキングコミットをマスターにコミットするのは良い考えですか？
バックグラウンド
仕事では、新しいワークフローを見つけようとしました。現在 git-flow をかなり厳密にフォローしています。リリースブランチはありません。十分にテストされていると感じたら、開発を直接マスターにマージします。修正プログラムがある場合、開発とマスターの両方に個別にマージします。
私たちが話してきたアプローチの1つは、開発をマスターにマージする代わりに、開発のマスターへのコミットをチェリーピックすることです。いくつかのチェリーピックの後、私たちはそれを配備し、それが私たちのリリースです。あるいは、開発からリリースブランチ（マスターに基づく）を選択し、マスターにマージすることもできます。
最初はこれに反対しました。歴史を平らにするからです。そして、--no-ffオプション。つまり、必要に応じて機能全体を元に戻すことができます。これも失われます。
それ以外は、これが悪い考えになる理由を本当に考えることはできません。同時に、このアプローチには何のメリットもありません。しかし、私は10年未満の専門的経験を持つ中堅レベルのエンジニアです。ですから、私はこれについて人々の経験や考えを聞くことに本当に興味があります。
質問
マージする代わりにチェリーピッキングにメリットはありますか？また、このアプローチを従来のマージに使用することで失うものはありますか？
チェリーピッキングコミットは、他の履歴のマージが望ましくない複数のブランチで特定の変更が必要な場合に役立ちます。これはマージ以外の特定のワークフローです。2つのブランチの履歴を組み合わせると、必要なコミット数が増えるためです。
関係するブランチに関係なく、常にチェリーピッキングはバージョン管理の目的に反します。履歴のマージが望ましいシステムで履歴を分岐させ、複数の人からの変更を簡単に組み込むことができます。常にチェリーピッキングがマスターに発展することは、明確な利点や目標がない反パターンです。
これは、人々がマージを恐れているように聞こえます。チェリーピッキングコミットもマージされますが、そのブランチの結果の履歴は、履歴が結合されたことを認識しません。履歴を読みやすくするのではなく、すでに質問に含まれている理由自体が原因で読みにくくなります。マージされた履歴は、特に人々がマージまたはプッシュする前に自分の作業を適切にリベースする場合、読みやすく、時間を遡ることが容易になります。
読みやすくなるだけでなく、履歴を共有することで、同じマージの競合を何度も解決する必要がなくなります。たとえば、25行目のfoo.jsに変更を加えたところ、この変更はマスターにありましたが、開発されていません。開発中のfoo.jsの25行目に別の変更を加えます。チェリーがマスターからコミットを選択すると、手動で解決する必要があるマージ競合が発生します。時間が経つにつれ、開発からマスターへのコミットを選択する時だと判断しました。何だと思う？ foo.jsの25行目のマージの競合を再び解決できます。変更が最初に行われた理由を覚えていますか？ 2週間でfoo.jsに誰も触れていなくても、適切な変更が2回正しく適用されますか？
ブランチをマージするとき、gitはfoo.jsに競合する変更が加えられたという事実を追跡し、競合をどのように解決したかを記憶するため、再度行う必要はありません。
すべてのチェリーピックは、ブランチから到達できなくなったコミットのガベージコレクターを作成する必要があった時点まで履歴を保持することについて、バージョンコントロールシステムの履歴を失う機会です（ gitを参照） gc または git Prune ）。
通常、developという名前のブランチが1つあります。これは、機能ブランチのブランチから分岐することを目的としています。 ときどきブランチにマージします。多くの場合、以下で説明するようにブランチを本番環境にマージした後でのみです。
完成した機能ブランチは、本番ブランチの「リリース候補」ブランチにマージされ、そこで徹底的にテストされます。次に、リリース候補のブランチがデプロイされたブランチにマージされます。
マージされるすべてのものは、常に「完全なブランチ」です。
2つのメイントランクは互いに並行して実行されます。