ガジェット通信

見たことのないものを見に行こう

「Googleがブランチを切らない開発をしている」ってホントなの?

DATE:
  • ガジェット通信を≫

Git? SVN? バージョン管理ツールのあれこれ

バージョン管理システムは大きく分けて、分散型のバージョン管理システム(DVCS)と集中型のバージョン管理システム(CVS)に分類できます。

Gitは分散型のバージョン管理ツールの一つです。

SVNやVSSなどの集中型のバージョン管理システムとは違い、中央サーバーのトラブルに依存せず開発ができるというメリットがあります。

Gitにおける管理の流れ

GitではSVNなどの集中型とは違い、簡単にブランチを切ることができます。

ブランチを切って開発をすることのメリットと言えば、チームで開発を行う時に他のエンジニアへ影響を与えずに・影響を受けずに開発ができるという点でしょう。

例えばA, B, C, D, Eの5人のチームで新しいSNSの開発をするとしましょう。

Aさんは新規登録とログイン機能の開発をしよう。Bさんはお気に入りの機能を、Cさんは画像を投稿できる機能を、Dさんはフォロー・フォロワーの機能、Eさんは他ユーザーの投稿への返信機能を開発するとしましょう。

このときそれぞれ大元となるmasterブランチから個々のブランチ(registration branch, favorite branchなど)を切って各開発作業に入ります。

ブランチを切ると、さまざまなメリットがあります。ワークフローは以下のようになります。

A〜Eさんはそれぞれ手元のローカルレポジトリで作業を行うことができるので、他の開発者を気にする必要はない
自身の担当の開発が完了すれば、それをリモートレポジトリにpush
他の開発者にも確認してほしいという場合などPull Requestを送る
問題がなければ、各開発者の手元のレポジトリにマージ(統合)してもらう
全ての開発作業がmasterブランチにマージされたら、デプロイして完了

大規模な開発になればなるほど、それぞれの作業領域が競合するなどのリスクは増していきます。開発中の重大なトラブルを防ぐために、ブランチ戦略は有向と言われています。

ブランチを切らない現場もある

バージョン管理ツールの中でも、とても使いやすく近年使用者がグングン上昇しているGit。

簡単にブランチを切ってスピーディーな開発ができるメリットがありますが、中にはGitなどを使用せず、ブランチを切らない開発を行う企業もあるようです。

それがなんと……Google!(タイトルで予想できたよバカ、などのご意見は受け付けません。)

2013年に行われたGATC (Google Test Automation Conference) にてAri Shamashがスピーチ行いました。

そこでは、Googleは様々なプロジェクトを一つのレポジトリで管理しており、ブランチを切らない運用をしていると話しています。

この理由としてAri Shamashは、「各開発で使用する多くのライブラリに関して、管理する必要がないというメリットがある」と述べています。

ライブラリのアップデートが行われた際に、バージョンが統一されていないと問題が生じる可能性がありますが、それを防ぐためにこのような管理方法を行っているのだとか。

確かに一理ありますが、普段ブランチを切った運用している方や、「ブランチ戦略導入のために開発環境の大手術をした」という方からすると、信じがたいことかもしれませんね。

しかし、全てのアプリケーションの開発においてこのやり方が使われているということはないようで、Google Chromeなど一部の開発にはブランチが切られています。

ブランチを切らない運用 デメリットは他にある?

ブランチを切らない開発をしている企業は他にもあり、それにはマージの衝突問題が関係あります。前述の例のようにA〜Eさんが同時に作業を行っている場合を考えましょう。

前述した通り、ブランチを切る開発には、同一ファイルであっても、別のブランチでコードを書いている間は衝突しないという利点があります。

しかし、同じ部分を修正していれば、後でやらなくてはならないタスクが発生します。

どちらのコードを採用するかの議論
バグが起こらないよう統合編集

仮にこの段階で判断を誤ると、思わぬバグが生じる可能性があります。

このようなデメリットからブランチを使わないという考えを持つチーム・企業も少なくありません。

ブランチを切らない開発では、フラグをフル活用する

ではブランチを使わない開発において、何か修正が必要な場合や新機能を追加する必要がある場合、どのようにして行っているんでしょうか?

その場合は、フラグを使って管理することが多いようです。つまり、機能に対して条件による制限をかけながら、直接masterに書いていくのです。

これにより新機能の開発がまだ完了していなくても、ユーザーはその機能を通過することなく、今までの機能を障害なく利用することができます。

またテストを行う際も、あるユーザーにだけ新機能を試せるように書くこともでき、これにより実験やテストを簡単に行うことができます。

仮に開発が完了し新機能をリリースできるという段階に入ったら、フラグを外すなどすれば即座に利用できるというわけです。

masterで作業を全て行うため、ブランチのマージする際の衝突問題は起こりません。

もちろんこの方法を採用するならば、フラグの管理に関しては、混乱をきたさないようなルールを綿密に設計しておく必要があります。

メリット・デメリットを押させてチームに合った開発を

ブランチを切った運用にもメリット・デメリットがあります。

Gitを使ったブランチ運用が主流になりつつありますが、デメリットも吟味しあなたの会社・チームに合った選択をとりましょう。

カテゴリー : デジタル・IT タグ :
CodeIQ MAGAZINEの記事一覧をみる ▶
  • 誤字を発見した方はこちらからご連絡ください。
  • ガジェット通信編集部への情報提供はこちらから
  • 記事内の筆者見解は明示のない限りガジェット通信を代表するものではありません。

TOP