3.4 Gitブランチ - ブランチのワークフロー

Gitはシンプルな3ウェイマージを使用するため、あるブランチから別のブランチへ長期間にわたって複数回マージするのは一般的に簡単です。これは、開発サイクルの異なる段階で使用するために、常に開いている複数のブランチを持つことができることを意味します。それらのいくつかを定期的に他のブランチにマージできます。

多くのGit開発者は、このアプローチを採用したワークフローを持っています。例えば、完全に安定したコードのみをmasterブランチに保持し、場合によってはリリースされた、またはリリースされる予定のコードのみを保持します。彼らは、作業用または安定性テスト用にdevelopまたはnextという別の並行ブランチを持っています。これは必ずしも常に安定しているわけではありませんが、安定した状態になるといつでもmasterにマージできます。これは、トピックブランチ（以前のiss53ブランチのような短命なブランチ）が準備できたときに取り込み、すべてのテストに合格し、バグを導入しないことを確認するために使用されます。

実際には、作成しているコミットのラインをポインタが上に移動していくことについて話しています。安定したブランチはコミット履歴の下の方にあり、最先端のブランチは履歴の上の方にあります。

これらを、コミットのセットが完全にテストされたときに、より安定したサイロに移行する作業サイロとして考える方が一般的に簡単です。

この作業を複数の安定性レベルで続けることができます。一部のより大規模なプロジェクトでは、nextまたはmasterブランチに組み込む準備ができていない統合されたブランチを持つproposedまたはpu（提案された更新）ブランチもあります。アイデアとしては、ブランチがさまざまな安定性レベルにあり、より安定したレベルに達したときに、その上位のブランチにマージされるというものです。繰り返しになりますが、複数の長期間稼働するブランチを持つことは必須ではありませんが、特に非常に大規模または複雑なプロジェクトを扱っている場合には、しばしば役立ちます。

しかし、トピックブランチはどんな規模のプロジェクトでも役立ちます。トピックブランチとは、単一の特定の機能や関連する作業のために作成して使用する、短命のブランチです。これは、ブランチの作成とマージが一般的に非常にコストがかかるため、これまでVCSで経験したことがないかもしれません。しかしGitでは、1日に数回ブランチを作成、作業、マージ、削除するのが一般的です。

このことは、前回のセクションで作成したiss53ブランチとhotfixブランチで確認しました。それらに数回のコミットを行い、メインブランチにマージした直後にそれらを削除しました。この手法により、迅速かつ完全にコンテキストを切り替えることができます。作業がそのトピックに関連するすべての変更が分離されたサイロに分割されているため、コードレビューなどで何が起こったかを把握しやすくなります。変更を数分、数日、数か月間そこに保持し、作成または作業された順序に関係なく、準備ができたときにマージすることができます。

masterで作業を行い、ある問題（iss91）のためにブランチを切り、しばらく作業し、同じことに対処する別の方法を試すために2番目のブランチ（iss91v2）を切り、masterブランチに戻ってしばらく作業し、その後、良いアイデアかどうかわからない作業（dumbideaブランチ）を行うためにブランチを切る例を考えてみましょう。コミット履歴は次のようになります。

さて、あなたの問題に対する2番目の解決策（iss91v2）が最も気に入ったとしましょう。そして、dumbideaブランチを同僚に見せたところ、それが素晴らしいアイデアだと判明しました。元のiss91ブランチを破棄し（コミットC5とC6を失います）、他の2つをマージすることができます。すると、履歴は次のようになります。

分散Gitでは、Gitプロジェクトで可能なさまざまなワークフローについてさらに詳しく説明しますので、次のプロジェクトでどのブランチスキームを使用するかを決定する前に、必ずその章を読んでください。

これらすべてを行う際に覚えておくべき重要なことは、これらのブランチが完全にローカルであるということです。ブランチとマージを行う場合、すべてはあなたのGitリポジトリ内でのみ行われ、サーバーとの通信はありません。