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

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

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

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

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

これをいくつかの安定レベルで継続できます。いくつかの大規模プロジェクトでは、next または master ブランチに統合するにはまだ準備ができていないブランチを統合した proposed または pu (proposed updates) ブランチも持っています。この考え方は、ブランチがさまざまな安定レベルにあるということです。より安定したレベルに達すると、それらはそれらの上のブランチにマージされます。繰り返しになりますが、複数の長期実行ブランチを持つことは必須ではありませんが、特に非常に大規模または複雑なプロジェクトを扱っている場合には、しばしば役立ちます。

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

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

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

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

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

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