Gitが、おもしろいほどわかる基本の使い方33
［Chapter1-01］Gitを使ったバージョン管理
チームで開発を行う上で、もはや欠かせない存在となったGit。でも、Gitを利用したことがない方、バージョン管理がよくわからない方は、Git が何をするものなのかもよくわからないでしょう。まずはGit によるバージョン管理の大まかなイメージをつかんでおきましょう。
2015年6月17日／TEXT：大串 肇
■誰がいつ、どのファイルの何を変更したかを管理
ある開発プロジェクトをチームで行っている現場。「おーい、このファイル誰か更新した？」「あ、それボクです。」「え、どこ変えたの？」「えーとそれは……何行目だったけな…… 」「1カ所だけか？」「いや、何カ所か。あれ、メモっといたんだけど、えーとそのメモをどこのフォルダに入れたかと……。」「あ、。誰だよ、ファイル上書きしちゃったやつ！？」「あ、それ私。」「おれの書いたところが元に戻ってんじゃん！」というわけであっという間に1日過ぎてしまった……ではお話になりませんね【図1】【図2】 。それにしてもこれだけいろいろなソフトが開発されているのですから、どこかにこういうことを全部管理してくれる便利なシステムはないものか。それがGit などの「バージョン管理システム」（Version Control System =VCS）です。
バージョン管理システムを導入していないプロジェクトの作業は、具体的に次のような危険を抱えています。ひとつは最新バージョンのファイルがどれかわからなくなるという問題です。プロジェクトにかかわる複数のメンバーが、複数のファイル、あるいは同じファイルを頻繁に書き直すために、ファイルの最新バージョンを把握するのが難しくなってきます。また、誰かが誤って上書きして、ほかのメンバーの変更を消してしまうような問題も発生します。ふたつ目は状態を元に戻せないということです。１世代前のバージョンでプロジェクトを進めようとなった場合に、誰もその状態に戻すことができません。また、何かの間違いで必要なファイルを削除してしまうと、それを戻す術がありません。こういった問題を解決できるツールがバージョン管理システムです。
■Gitによるバージョン管理の利点
Gitによるバージョン管理では、管理されたプロジェクトにおいて、いつ、誰が、どのファイルのどの箇所を、どういった目的で作成、変更、削除したかという履歴を残し、共有することができます。たとえば、最新のファイルとは、履歴の最も新しいファイルということになります。過去の状態を確認したり、その時点に復元したりすることもできます【図3】 。誤ってファイルを削除してしまった場合でも、直前の履歴にファイルを戻すことで、削除したファイルを復元することが可能です。
■Gitにおける作業の流れ
Gitがバージョン管理下におく場所を「リポジトリ」と呼びます。リポジトリには、「ローカルリポジトリ」と「リモートリポジトリ」の2種類がありますが、この説明はP.017で行います。ここではGitが管理するリポジトリという場所があると覚えてください。ユーザーが変更の履歴を記録する作業を「コミット」（commit）と呼びます。コミットは時系列のつながりを持っており、順々に記録されるので、コミットを過去にさかのぼることができ、ファイルをコミットの単位で戻すことができます。コミットには必ず「コミットメッセージ」（→P.030）というコメントをつける必要があります。誰にもわかりやすいコミットメッセージをつけることで、履歴がよりわかりやすくなります【図4】。Gitを利用した作業は、基本的に「修正→コミット」の繰り返しです。ユーザーはコミットメッセージを参考に、コミット時のファイルの状態を確認できます。
■作業の流れを分岐するブランチ
また、Gitには、「ブランチ」（branch）と呼ばれる履歴を枝分かれさせて記録する機能があります。たとえば、メインの開発をマスターブランチとして、それとは別にサブ的な機能を分けて開発を進める、あるいはバグフィックスを切り分けて行うというような場合に、ブランチを分けて開発を進めることができます。ブランチはいくつでも作ることができます。ブランチによって枝分かれした履歴は、ほかのブランチの影響を受けることはなく、ブランチごとに作業を進められます。
さらに、枝分かれしたブランチは「マージ」（merge）と呼ばれるブランチ同士を結合する機能によって、ひとつにまとめることが可能です【図5】 。元となるブランチから作業のブランチに枝分かれし、作業が完了したら、元のブランチにマージして、ひとつにまとめることも可能です。
■分散型と集中型の違い
バージョン管理システムの主な種類として「集中型」と「分散型」があります。Git は分散型のバージョン管理システムです。集中型のバージョン管理システムで有名なものにはSVN（Subversion: サブバージョン）があります。
集中型ではリポジトリはひとつであり、サーバ上に中央リポジトリが設置されます。利用者はそれに対してチェックアウトとコミットを行うことで、開発を進めていきます。このため、最新の情報を取得するにも、何か作業を行ったあとにコミットを行うときにも、必ず中央サーバに接続する必要があります。また、万が一中央リポジトリが破損した場合は、復旧が難しくなる恐れがあります【図6】 。
分散型では、それぞれの端末ごとにローカルのリポジトリが作成されます【図7】 。集中型がひとつの中央リポジトリで管理されるのに対し、複数のリポジトリが作成されるので、分散型と呼ばれます。自分の端末に作成したローカルリポジトリに対してはいつでも変更の登録（コミット）が可能なので、リモートリポジトリにプッシュしたり、リモートリポジトリからプルしたりする作業を除けば、オフラインでも作業が可能です。また、複数のリポジトリが作成されることで、どこかのリポジトリが破損した場合にも、比較的容易に復旧することが可能です。
 【図6】集中型のバージョン管理システム |
 【図7】分散型のバージョン管理システム |
【BOOKS紹介】バージョン管理システム「Git」の入門書。はじめて使う方でも業務に取り入れやすいよう、「これだけは覚えておきたい機能」に絞り込んで解説しました。SourceTree（GUIツール）とホスティングサービス・Bitbucketを用いた解説内容になっており、初心者の方でもGitやSourceTreeを活用する状況をイメージしやすいよう、イラストや図、実際のツール画面を豊富に掲載。実制作や業務の中に手軽にGitを取り入れ、生産性を向上したいという方に最適の1冊です。
●書籍ページ：http://www.mdn.co.jp/di/book/3214203010/
●Amazon：http://www.amazon.co.jp/exec/obidos/ASIN/4844365010/mdndi-22/
