複数のブランチのGit "動的マージ"
私は機能ブランチモデルで作業します。ブランチは準備ができたときにマスターにマージされます。より大きなテスト（多くの重いハードウェアを含む私の作業分野に固有）の前に、いくつかの機能ブランチ（個別にシミュレーションを使用してテスト）が1つの「テスト」ブランチにマージされます。
実際のテストの前に、「テスト」ブランチがシミュレーションを使用して再度テストされます。このテスト中に、個々のブランチが一緒に動作する方法が原因で問題が発生した場合（またはこれまでに見られなかった他のバグが発生した場合）、個々の機能ブランチを修正できますが、「テスト」ブランチがマージされました。
現時点では、私は通常、テストブランチ（マージコミット）を削除し、それぞれの機能ブランチに修正を加えてから、関連するすべてのブランチを「テスト」ブランチに再度マージします。これは少し面倒です。もちろん、小さなスクリプトなどを作成することもできますが、私の状況では、さまざまな機能ブランチがすべてマージされた「テスト」ブランチを持つ複数のリポジトリがあり、それらすべてのスクリプトを記述しています...より良い解決策を探したい。
私の質問：ある種の「動的」マージを行う方法はありますか？マージされた機能ブランチにコミットを追加すると、「テスト」ブランチマージは、マージされたかのようにそのコミットで更新されますそのコミットはすでに機能ブランチにあります。
アイデアが明確であることを願っています。そうでない場合は、明確にできるようにお知らせください。
Gitはこれに対して特に優れたサポートを提供していません。概念的な問題は、各Gitコミットがプロジェクトの状態を表すのであって、差分ではないことです。 2つのブランチをマージするとは、2つのブランチのプロジェクト状態の違いを結合することです。通常、Gitはどちらのブランチからも競合しない変更を適用するため、これは簡単です。ただし、機能ブランチにコミットを追加して再度マージする場合、最初のマージとほぼ同じくらい難しく、同じ競合の多くを再度解決する必要がある可能性があります。 git-rerereをローカルで有効にして、以前のマージから記録されたマージ競合解決を再利用できますが、
rerereのもう1つのアプリケーションは、Gitプロジェクト自体がしばしば行うように、進化するトピックブランチの束をテスト可能なヘッドにマージする場合があります。テストが失敗した場合は、再度競合を解決する必要なく、テストを失敗させたトピックブランチなしでマージを巻き戻してやり直すことができます。Rerere機能を有効にするには、次の構成設定を実行するだけです。
_$ git config --global rerere.enabled true_– Git Book /Pro Git 2nd ed。スコット・チャコン、ベン・ストラウブ。
機能ブランチが必要な理由と、テストブランチが表すものを検討してください。テストブランチがリリース候補のようなものになる場合、機能ブランチへの追加の変更をコミットすることには（そしてその後再度マージする必要がある）価値は限られています。代わりに、変更をホットフィックスとしてテストブランチに直接コミットすることを検討してください。テストブランチがリリースの基礎ではない場合、特にマージの競合が異なる方法で解決される可能性があるため、リリースしているシステムとは異なるシステムをテストしていることに注意してください。
また、機能ブランチからテストブランチに、またはその逆に、修正をチェリーピックまたはリベースすることもできます。これは別の履歴の上にコミットの変更を複製します。競合が発生する可能性がありますが、通常は完全なマージよりも制限されます。
マージもリベースもマージコミットを自動更新できません。マージコミットを修正したり、2つのマージコミットを押しつぶしたりすることは原則として可能ですが、これは比較的難しい作業です。最も簡単な方法は、最初にマージ後に必要なプロジェクト状態に到達してコミットし、次にこの状態を生成する新しい履歴を記録することです。テストブランチをマージ前にリセットし、すべてのブランチのタコマージを開始しますが、_--no-commit_マージし、次にgit-checkoutを使用して作業ツリーを目的のプロジェクト状態に復元し、マージとして結果をコミットします。
Gitでマージの競合を回避する最良の方法は、長時間実行されるブランチを回避することです。私はこれが常に可能であるとは限らないことを理解していますが、機能を早期に統合すると（おそらく機能切り替えでそれらを保護することにより）競合が発生し、早期かつ一度だけ解決されます。同様に、多くの既存のコードを変更せずに新しい機能を追加できるアーキテクチャは、競合を回避します。つまり、複雑さを分岐モデルからコード自体にシフトします。