ブランチを使用したソフトウェア開発

お久しぶりになってしまいました。
私事でいろいろと環境の変化があったのですが、このブログもコツコツ続けていこうと思います。

さて、本日はブランチを使用したソフトウェア開発について触れたいと思います。

以前、メール堂々と「Brunch」と書いていたのを同僚に気付かれ、恥ずかしい思いをした思い出があります。
今回は、「遅い朝食(Brunch)」ではなく、「枝(Branch)」のほうの話題です。

ブランチとは

私は、現在gitを使用してAndroidのアプリ開発を行っています。
gitに関しては以前の記事で少し触れています。

Dropboxとgitを使ったソースコード管理 - 週末プログラマーのチラシの裏

gitのようなバージョン管理ツールを使用していく上で、欠かせないのがブランチの存在です。
ブランチとは、その名の通り、枝を意味しています。
下の図は、よく見るようなブランチの概念図ですが、わかりやすいので作ってみました。

枝(branch)は、この場合、Masterという幹(trunk)から派生しています。

ブランチ名について

上記のブランチ図の中で、各ブランチは、ブランチ名の通り下記のような目的でブランチされています。

• calendar　カレンダーの実装を行う目的で作成されたブランチ
• alarm　　 アラームの実装を行う目的で作成されたブランチ
• database　データベースの実装を行う目的で作成されたブランチ

ここで使用されている名前は、主に実装対象の機能名などをつけています。

また、それぞれブランチ名にtopics/、tests/という名称がつけられていますが、この名称は、共同開発者とのルールの取り決めを行って決めています。
私たちの作成したルールでは、下記のようにシーン別にわけることにしています。

• topics/　機能実装を行うブランチ
• tests/　 お試しで実装を行ってみるためのブランチ

この後ろに、実装する機能名などをブランチ名としてつけることで、ブランチを作成した目的がある程度ブランチ名から理解ができる形になっています。

ブランチを活用する目的

ブランチを作成する目的ですが、例えば、上記のブランチ図にあるalarm機能、database機能、calendar機能を作成するときに、Master上ですべての機能実装を続けていくことにはリスクが生じます。
ある機能が要因で、開発対象物が動かなくなり、すべての機能の開発が停止してしまうというような事態が生じるかもしれませんし、複数人で同時に開発を行っている環境であれば、なおさらそのリスクが発生する確率が高まります。
こういったリスクを回避するために、ブランチを分けて開発することは、とても有効な手段となります。

各ブランチで開発を行い、実装が終了すると、ブランチをMasterへマージするという作業を行います。
この作業によって、Masterというtrunk(幹)に機能を入れていきます。
これを繰り返し、Masterに対してマージを重ねていくことで、機能が実装されていくことになります。

ブランチの運用ルール

私たちは下記のような簡単なルールを作成して、ブランチを使用した開発を行っています。

• 機能実装はtopics、テスト実装はtestsとする
• ブランチ名は直感的にわかりやすいものでOK
• 機能実装担当は各ブランチでテストを実行後、Masterにマージして再度テストをする
• 他の実装者がMasterにて動作確認を行い、問題なければ実装完了とする

こういった簡単なルールを作って活動することで、Masterブランチの品質確保や、不具合の早期発生を行うことができます。

今回はブランチの概念について記しましたが、次回はもう少しブランチについて掘り下げてみたいと思います。