序文
Gitとは、Linuxカーネルの開発者Linus Torvalds氏によって2005年に開発が始まった分散型バージョン管理システムである。公開後しばらくは、多くのオープンソースプロジェクトで利用されつつも、SubversionやCVSといった既存のバージョン管理システムほどには普及していなかった。しかし2008年のGitHubの公開により利用者が急増し、最も有名な分散型バージョン管理システムのひとつとなった。
Gitは「分散」という言葉が付くように、それまでのバージョン管理システムとは考え方や仕組みが異なる部分が多い。そのため、従来のバージョン管理システムと同じように利用していては、その真価を引き出せないだけではなく、別の問題が発生してしまうこともある。さらにワークフローや利用方法の自由度が高いため、定石といえるものがなかなか定着せず、使い方が難しいという印象を持たれがちだった。
そこで本書では、実際のプロジェクトにおいて、Gitをどのように利用するかについての指針を提案している。簡単なファイル管理から、複数人でのプロジェクト、そして大規模システム開発やオープンソースシステム開発、という3つのシチュエーションで、どのようにGitを使うのか、またどのような問題が起こり得るのかをストーリー仕立てで紹介している。さまざまな局面で利用できるワークフローを通じて、徐々にGitに慣れ親しんでもらうための構成となっている。さらにストーリーを補完するために、それぞれのGitのコマンドについての解説やGitの仕組み、周辺ツールや共有リポジトリの作成方法なども説明している。今まで知らなかったコマンドの使い方や構造を知ることで、さらに理解が深まると考えている。
Gitは、その構造やコマンドの多さなどで、一見して複雑に感じてしまうことがある。本書のストーリーを通じて基本的なワークフローを知ることで、Gitを深く理解し、日常業務やオープンソースプロジェクトでGitを利用できるようになっていただければ幸いである。
なお本書の執筆にあたっては多くの方にご協力いただいた。濱野純さん、本庄弘典さん、大波誠さん、小室文さん、鵜飼文敏さん、吉井卓さん、松鵜琢人さん、佐々木庸平さん、山本竜さん、阿部崇さん、桑野章弘さん、並河祐貴さん、船ヶ山慶さんには草稿をレビューしていただいた。彼らのレビューがなければ本書の内容はここまで達しなかっただろう。武藤健志さんとオーム社開発局の方々には、編集者の視点から多くの助言をいただいた。そしてもちろん、濱野純さんをはじめGitの開発者の皆様、また本書を書くための時間を与えてくれた家族に、心から感謝を捧げたい。
2011年10月
著者一同
著者について
岩松信洋（いわまつのぶひろ）
SuperH Linux Projectを中心に活動。U-Boot ProjectのSHポートメンテナをする傍ら、Debian Projectにも貢献し、2010年からDebian Projectオフィシャルデベロッパー。Debian JP Project会長（2009年）、同副会長（2006.2008年、2010年）。2010年度日本OSS奨励賞受賞。好きなGitコマンドはgit resetとgit rebase -i。
上川純一（うえかわじゅんいち）
Debian GNU/Linux上で日々開発をしている。2001年からDebian Projectのオフィシャルデベロッパー。Debian JP Project会長（2006.2008年）。好きなGitコマンドはgit blameとgit rebase -i。
まえだこうへい
2008年からDebian JP Projectに参加。自称兼業主夫。Debian JP Project会長（2011年）。著書・Webサイトへの寄稿に、『KVM徹底入門』（翔泳社）、『知って見るみるKVM』『ゆったリラックス！ CouchDBがあるところ』（@IT）がある。好きなGitコマンドはgit log。
小川伸一郎（おがわしんいちろう）
Ruby on Railsで携帯向けWebサービスを開発・運営するエンジニア。RubyやDebianなどさまざまなコミュニティに顔を出している。普段はEmacsとmagit.elを駆使して開発している。jpmobileの開発者でtermtterのコミッタ。好きなGitコマンドはgit cherry-pick。
著者略歴 (「BOOK著者紹介情報」より)
岩松/信洋
SuperH Linux Projectを中心に活動。U‐Boot ProjectのSHポートメンテナをする傍ら、Debian Projectにも貢献し、2010年からDebian Projectオフィシャルデベロッパー。Debian JP Project会長(2009年)、同副会長(2006‐2008年、2010年)。2010年度日本OSS奨励賞受賞
上川/純一
Debian GNU/Linux上で日々開発をしている。2001年からDebian Projectのオフィシャルデベロッパー。Debian JP Project会長(2006‐2008年)
まえだ/こうへい
2008年からDebian JP Projectに参加。Debian JP Project会長(2011年)
小川/伸一郎
Ruby on Railsで携帯向けWebサービスを開発・運営するエンジニア。RubyやDebianなどさまざまなコミュニティに顔を出している。jpmobileの開発者でtermtterのコミッタ(本データはこの書籍が刊行された当時に掲載されていたものです)
About this Title
第5章
複数人のプロジェクトでGitを利用する
Subversionなどの集中型バージョン管理システムを利用する場合と、分散型バージョン管理システムであるGitを利用する場合とで大きく異なるのが、複数人で開発するプロジェクトでのワークフローである。本章では、ネットワーク越しに複数のリポジトリがある点や、中央リポジトリの扱いに注意を払いながら、大まかなワークフローを紹介する。
なお本章では、Ruby*1のWebアプリケーションフレームワークである、Ruby on Rails*2（以下Rails）を用いたプロジェクトを題材にする。Gitのホスティングサービスで有名なGitHub*3がRailsで制作されていることや、またRailsそのものもGitHubで公開されている*4ことから、Gitとの関連性が高いと思われるためだ。ただし基本的なワークフローは、他の言語やフレームワークでも大きくは変わらない。Railsを知らない読者は、大まかな流れに注目して読み進めてほしい。
5.1 SubversionからGitへ
信洋はRailsアプリケーション開発を主業務とするソフトウェア開発会社に勤務している。これまでソースコード管理はSubversionで行っていた。管理されているベースになるソースコードからプロジェクトごとにブランチを作成し、開発を行っていた。開発やちょっとしたテストにブランチを作成すると、リポジトリがブランチで溢れかえってしまい、見通しが悪く管理に手間がかかるようになってしまった。そのため開発用にブランチを作成しないことも多く、そのまま間違ってコミットしてしまうというケースさえもあった。また、変更が大きくなることでマージ時のコンフリクト解消に手間がかかるケースもあり、別のバージョン管理システムへの移行が検討されていた。そこで、信洋はかねてより気になっていた、分散型バージョン管理システムであるGitの導入を推進することにした。
ワークフローの整理
最初に現状のワークフローと開発環境に対する要件を整理することから始めた。まずはソースコードを管理するリポジトリが必要となる。開発自体は開発メンバーそれぞれのコンピュータ上で行うことができるが、開発中の機能をマネージャや顧客が確認しやすいようにテストサーバが必要となる。さらに最終的な確認をするために、本番サーバに近い環境であるステージングサーバも必要となり、またそれぞれのサーバにリポジトリからソースコードをアップロード（デプロイ）できなければならない。これらをまとめると、開発環境として必要な要件は次のようになる。
.ソースコードを管理するリポジトリが必要
.開発自体は開発メンバーのコンピュータ上で行う
.顧客が確認できるサーバが必要
.各サーバにデプロイできなければならない
プロジェクト開始から納品までの大まかなワークフローとしては、次のようになる。
1.プロジェクトの開始と開発メンバーの決定
2.リポジトリやサーバなどの環境設定
3.開発と確認を繰り返す
4.マネージャと顧客の確認
5.納品してプロジェクト完了
このワークフローの中で、3.の開発についてはメンバーそれぞれが独立して機能を開発することが想定されるので、リポジトリにメンバー専用の領域が必要となる。またサーバにデプロイする過程で、サーバから直接アクセスできるところにリポジトリが必要となるため、メンバーのコンピュータ上に開発しているソースコードがある状況ではデプロイできない可能性がある。チームの人数が少ないため、リポジトリには専任の管理者を配置せずに運用することになっていた。これらを考慮して信洋は、プロジェクトでGitを使う際の要件を以下のようにまとめた。
.サーバからアクセスできるようにネットワーク上にリポジトリ（リモートリポジトリ）が必要
.テストサーバやステージングサーバにデプロイするために、そのリポジトリ上にブランチ（リモートブランチ）が必要
.そのためそのブランチがあるリポジトリには、開発メンバーが書き込み可能でなければならない
.ただしリポジトリの専任の管理者は特に配置せず、開発メンバーの誰かが兼務するなど、運用でカバーできるようにする
Gitの提案
これらを踏まえて信洋は図5.1のようなリポジトリ構成を提案した。ネットワーク上にGitリポジトリ（リモートリポジトリ）を用意し、そこにメンバーそれぞれ専用のブランチを作成して開発を行う。リポジトリには特に書き込み制限は設けずに、masterブランチへの統合（マージ）については各自で行う。マージの方法や内容については、直接口頭で適宜交渉して運用でカバーするという方法だ。
図5.1:信洋が提案したGitリポジトリ構成案
メンバーで議論したところ、要件は満たしていることが確認できた。そこでGitに詳しい純一にレビューしてもらったところ、図5.2のようなGitを生かした構成にすれば、さらに良くなるのではないかと提案してもらった。この構成の特長と解決できる問題点を列挙すると、次のようになる。
.開発メンバーは各自のリモートリポジトリのみ書き込み可能
.中央リポジトリは特定のメンバーか管理者のみ操作ができる
.各メンバーがリモートブランチを持てるので、サーバにデプロイ可能
.各メンバー同士でブランチを参照できるので、お互いの開発進捗を確認しやすい
.開発結果の確認のためのデプロイに必要な、リモートリポジトリを個人で持つため、リモートリポジトリがブランチで溢れかえる問題がなくなる
.中央リポジトリには管理者しかコミットできないため、誤って中央リポジトリにコミットする問題も回避できる
さらにGitであれば、コンフリクトも解消しやすくなることが想定されるなど*5、多くの問題を解決できそうなことが分かった。メンバーにこの構成を提案したところ、Gitを使うことが了承された。信洋は次に始まる新プロジェクトから実戦投入することにした。
図5.2: 純一が提案した階層構造のGitリポジトリ構成案
