workflows.asc

ブランチでの作業の流れ

ブランチとマージの基本操作はわかりましたが、ではそれを実際にどう使えばいいのでしょう? このセクションでは、気軽にブランチを切れることでどういった作業ができるようになるのかを説明します。 みなさんのふだんの開発サイクルにうまく取り込めるかどうかの判断材料としてください。

長期稼働用ブランチ

Git では簡単に三方向のマージができるので、あるブランチから別のブランチへのマージを長期間にわたって繰り返すのも簡単なことです。 つまり、複数のブランチを常にオープンさせておいて、それぞれ開発サイクルにおける別の場面用に使うということもできます。 定期的にブランチ間でのマージを行うことが可能です。

Git 開発者の多くはこの考え方にもとづいた作業の流れを採用しています。 つまり、完全に安定したコードのみを master ブランチに置き、いつでもリリースできる状態にしているのです。 それ以外に並行して develop や next といった名前のブランチを持ち、安定性をテストするためにそこを使用します。 常に安定している必要はありませんが、安定した状態になったらそれを master にマージすることになります。 また、時にはトピックブランチ (先ほどの例の iss53 ブランチのような短期間のブランチ) を作成し、すべてのテストに通ることやバグが発生していないことを確認することもあります。

実際のところ今話している内容は、一連のコミットの中のどの部分をポインタが指しているかということです。 安定版のブランチはコミット履歴上の奥深くにあり、最前線のブランチは履歴上の先端にいます。

Figure 1. 安定版と開発版のブランチの線形表示

各ブランチを作業用のサイロと考えることもできます。 一連のコミットが完全にテストを通るようになった時点で、より安定したサイロに移動するのです。

Figure 2. 安定版と開発版のブランチの ``サイロ'' 表示

同じようなことを、安定性のレベルを何段階かにして行うこともできます。 大規模なプロジェクトでは、proposed あるいは pu (proposed updates) といったブランチを用意して、next ブランチあるいは master ブランチに投入する前にそこでいったんブランチを統合するというようにしています。 安定性のレベルに応じて何段階かのブランチを作成し、安定性が一段階上がった時点で上位レベルのブランチにマージしていくという考え方です。 念のために言いますが、このように複数のブランチを常時稼働させることは必須ではありません。 しかし、巨大なプロジェクトや複雑なプロジェクトに関わっている場合は便利なことでしょう。

トピックブランチ

一方、トピックブランチはプロジェクトの規模にかかわらず便利なものです。 トピックブランチとは、短期間だけ使うブランチのことで、何か特定の機能やそれに関連する作業を行うために作成します。 これは、今までの VCS では実現不可能に等しいことでした。 ブランチを作成したりマージしたりという作業が非常に手間のかかることだったからです。 Git では、ブランチを作成して作業をし、マージしてからブランチを削除するという流れを一日に何度も繰り返すことも珍しくありません。

先ほどのセクションで作成した iss53 ブランチや hotfix ブランチが、このトピックブランチにあたります。 ブランチ上で数回コミットし、それをメインブランチにマージしたらすぐに削除しましたね。 この方法を使えば、コンテキストの切り替えを手早く完全に行うことができます。 それぞれの作業が別のサイロに分離されており、そのブランチ内の変更は特定のトピックに関するものだけなのですから、コードレビューなどの作業が容易になります。 一定の間ブランチで保持し続けた変更は、マージできるようになった時点で (ブランチを作成した順や作業した順に関係なく) すぐにマージしていきます。

次のような例を考えてみましょう。 まず (master で) 何らかの作業をし、問題対応のために (iss91 に) ブランチを移動し、そこでなにがしかの作業を行い、「あ、こっちのほうがよかったかも」と気づいたので新たにブランチを作成 (iss91v2) して思いついたことをそこで試し、いったん master ブランチに戻って作業を続け、うまくいくかどうかわからないちょっとしたアイデアを試すために新たなブランチ (dumbidea ブランチ) を切りました。 この時点で、コミットの歴史はこのようになります。

Figure 3. 複数のトピックブランチ

最終的に、問題を解決するための方法としては二番目 (iss91v2) のほうがよさげだとわかりました。 また、ちょっとした思いつきで試してみた dumbidea ブランチが意外とよさげで、これはみんなに公開すべきだと判断しました。 最初の iss91 ブランチは放棄してしまい (コミット C5 と C6 の内容は失われます)、他のふたつのブランチをマージしました。 この時点で、歴史はこのようになっています。

Figure 4. dumbidea と iss91v2 をマージした後の歴史

Git プロジェクトで考えられるさまざまなワークフローについて、 ch05-distributed-git.asc でより詳しく扱います。 次のプロジェクトで、どんな方針でブランチを作っていくかを決めるまでに、まずはこの章を確認しておきましょう。

ここで重要なのは、これまで作業してきたブランチが完全にローカル環境に閉じていたということです。 ブランチを作ったりマージしたりといった作業は、すべてみなさんの Git リポジトリ内で完結しており、サーバーとのやりとりは発生していません。