特定の機能が実験段階から安定段階へと移行するにつれて、ソフトウェアの対応するブランチ間を「卒業」します。git.git は以下の統合ブランチを使用します

わずかに異なる方法で使用される4番目の公式ブランチがあります

4つのブランチはそれぞれ、通常、その上位のブランチの直接の子孫です。

概念的には、機能は不安定なブランチ（通常は next または seen）で導入され、十分安定していると見なされると、次のリリースに向けて master に「卒業」します。

上記で議論した「下位ブランチへの卒業」は、実際に下位ブランチへマージすることで行うことはできません。なぜなら、それでは不安定なブランチのすべての変更が安定版にマージされてしまうからです。したがって、以下のようになります

これにより、修正のフローが非常に制御されます。たとえば、master に適用した修正が maint でも必要であることがわかった場合、それを下位ブランチへチェリーピック（git-cherry-pick[1] を使用して）する必要があります。これは数回発生しますが、非常に頻繁に行わない限り心配することはありません。

些細ではない機能は、実装にいくつかのパッチを必要とし、そのライフサイクル中にさらなるバグ修正や改善が行われる可能性があります。

統合ブランチにすべてを直接コミットすると、多くの問題が生じます。問題のあるコミットは元に戻すことができないため、1つずつリバートする必要があります。これは混乱した履歴を作成し、変更グループの一部をリバートし忘れた場合にさらなるエラーの可能性を生み出します。並行して作業すると変更が混ざり合い、さらなる混乱を引き起こします。

「トピックブランチ」の使用はこれらの問題を解決します。この名前は非常に分かりやすいですが、上記の「上位ブランチへのマージ」ルールから来る注意点があります

多くのことを非常に自然に行うことができます

最後の点が他の2点と矛盾することに注意してください。つまり、すでに他の場所にマージされたトピックはリベースすべきではありません。git-rebase[1] の「RECOVERING FROM UPSTREAM REBASE」セクションを参照してください。

「習慣的に」（実際的な理由もなく定期的に）統合ブランチを自分のトピックにマージすること、ひいては定期的にアップストリームの何かをダウンストリームの何かにマージすることは、推奨されません。

そうでなければ、マージされたトピックは突然、単一の（十分に分離された）変更以上のものを含むことになります。結果として生じる多くの小さなマージは、履歴をひどく乱雑にします。後でファイルの履歴を調査する人は、そのマージが開発中のトピックに影響を与えたかどうかを調べなければなりません。アップストリームが意図せず「より安定した」ブランチにマージされることさえありえます。その他諸々。

前の段落に従った場合、現在多くの小さなトピックブランチがあり、それらがどのように相互作用するのか時々疑問に思うでしょう。もしかしたら、それらをマージした結果が機能しないかもしれません？しかし、一方で、そのようなマージは簡単には元に戻せないので、どこか「安定した」場所にマージすることは避けたいです。

もちろん、解決策は元に戻せるマージを行うことです。つまり、使い捨てブランチにマージするのです。

このブランチがテスト後すぐに削除されることを（非常に）明確にすれば、このブランチを公開することもできます。例えば、テスターにそれを使って作業する機会を与えたり、他の開発者に進行中の作業が互換性があるかどうかを確認する機会を与えたりするためです。git.git には、seen と呼ばれるそのような公式の使い捨て統合ブランチがあります。

上記で議論したマージアプローチを使用していると仮定すると、プロジェクトをリリースする際に、追加のブランチ管理作業を行う必要があります。

機能リリースは master ブランチから作成されます。なぜなら、master は次の機能リリースに含まれるべきコミットを追跡しているからです。

master ブランチは maint のスーパーセットであるべきです。この条件が満たされない場合、maint には master に含まれていないコミットが含まれていることになります。したがって、それらのコミットで表される修正は、機能リリースには含まれません。

master が実際に maint のスーパーセットであることを検証するには、git log を使用します。

このコマンドはコミットをリストアップすべきではありません。そうでない場合は、master をチェックアウトし、maint をそれにマージしてください。

これで機能リリースの作成に進むことができます。master の先端にリリースバージョンを示すタグを適用します。

新しいタグを公開Gitサーバーにプッシュする必要があります（以下の「分散ワークフロー」を参照）。これにより、あなたのプロジェクトを追跡している他の人々にタグが利用可能になります。このプッシュは、リリースtarボールの構築や整形済みドキュメントページの作成など、リリース関連の項目を実行するためのpost-updateフックをトリガーすることもあります。

同様に、メンテナンスリリースの場合、maint がリリースされるコミットを追跡しています。したがって、上記の手順では、master ではなく maint にタグを付けてプッシュするだけです。

機能リリース後、メンテナンスブランチを管理する必要があります。

まず、最近の機能リリース以前に行われた機能リリースのメンテナンス修正を引き続きリリースしたい場合は、その以前のリリース用のコミットを追跡するための別のブランチを作成する必要があります。

これを行うには、現在のメンテナンスブランチを、以前のリリースバージョン番号（例：X.Y.Zが現在のリリースである場合、maint-X.Y.(Z-1)）で名前を付けた別のブランチにコピーします。

maint ブランチは、現在のリリースに対するメンテナンス修正を追跡できるように、新しくリリースされたコードにファストフォワードされる必要があります。

マージがファストフォワードではないために失敗した場合、maint 上のいくつかの修正が機能リリースで漏れていた可能性があります。前のセクションで説明したようにブランチの内容が検証されていれば、これは発生しません。

機能リリース後、統合ブランチ next は、オプションで巻き戻され、next 上に残っているトピックを使用して master の先端から再構築される場合があります。

これを行う利点は、next の履歴がクリーンになることです。例えば、next にマージされた一部のトピックは、当初は有望に見えたものの、後に望ましくない、または時期尚早であることが判明したかもしれません。そのような場合、そのトピックは next からリバートされますが、一度マージされてリバートされたという事実は履歴に残ります。next を再作成することで、そのようなトピックの別の「転生」にクリーンな状態から再試行する機会を与え、機能リリースはそうするのに履歴上良い節目となります。

これを行った場合、next が巻き戻され、再構築されたことを示す公開アナウンスを行うべきです。

seen も同様に巻き戻しと再構築のプロセスに従うことができます。seen は上記のように使い捨てブランチであるため、公開アナウンスは不要です。

マージワークフローは、アップストリームとダウンストリーム間でブランチをコピーすることで機能します。アップストリームは貢献を公式履歴にマージでき、ダウンストリームは公式履歴に基づいて作業を行います。

これには主に3つのツールが使用できます

最後の点に注意してください。リモートブランチを実際にマージしたい場合を除き、git pull を使用しないでください。

変更を公開するのは簡単です

メールなどの他の手段で人々に伝える必要があります。（Gitは、このタスクを簡素化するために、整形済みのプルリクエストをアップストリームのメンテナに送信するための git-request-pull[1] を提供しています。）

統合ブランチの最新コピーを取得したいだけであれば、最新の状態を維持するのも簡単です。

その後、先に説明したように、安定したリモートからトピックブランチをフォークするだけです。

メンテナで、他の人のトピックブランチを統合ブランチにマージしたい場合、通常、メールでそのためのリクエストが送られてきます。そのようなリクエストは次のようになります。

その場合、git pull はフェッチとマージを一度に実行できます。以下の通りです。

時折、メンテナがダウンストリームから変更をプルしようとすると、マージコンフリクトが発生することがあります。この場合、メンテナはダウンストリームにマージとコンフリクトの解決を依頼できます（おそらく彼らの方が解決方法をよく知っているでしょう）。これは、ダウンストリームがアップストリームからマージすべき稀なケースの一つです。

メールの形式で変更をアップストリームに送信する貢献者である場合、通常通りトピックブランチを使用すべきです（上記を参照）。その後、対応するメールを生成するために git-format-patch[1] を使用してください（メンテナの作業を容易にするため、手動でのフォーマットよりも強く推奨されます）。

詳細な使用方法については、git-format-patch[1] および git-send-email[1] のマニュアルページを参照してください。

メンテナからパッチが現在のアップストリームに適用できなくなったと伝えられた場合、トピックをリベースする必要があります（マージは、マージをformat-patchできないため使用できません）。

その後、リベース中にコンフリクトを修正できます。おそらく、あなたはメール以外でトピックを公開していないため、それをリベースすることは問題ありません。

そのようなパッチシリーズを受け取った場合（メンテナとして、またはそれが送信されたメーリングリストの読者として）、メールをファイルに保存し、新しいトピックブランチを作成し、git am を使用してコミットをインポートします。

注目すべき機能の一つは、コンフリクトが発生した場合に役立つスリーウェイマージです。git am -3 は、パッチに含まれるインデックス情報を使用してマージベースを特定します。その他のオプションについては、git-am[1] を参照してください。