こんにちは。プログラマー小野です。

今このブログを読んでいるあなたはプログラマーですか？

私の記事はプログラミングの話をしないプログラマーのブログとして確立しつつあるので、非プログラマーの人の方が多いかもしれません。

WordやExcelで書類を作る作業がメインの人、デザイン業務でAdobeのソフトを使う人、プログラム開発でソースコードを扱う人、どんな業務であれPCを使っている以上何らかのファイルを扱う訳ですし『ファイル管理』は永遠につきまとう問題ですよね。

あるいは不注意でファイルを上書き、または削除してしまう事故を防ぐため、あるいは膨大な数のファイルの分類や整理整頓のため、あるいは複数人で情報を共有する必要性から、様々な理由で様々なノウハウが編み出されていますが、今回は『Git』を使ったファイル管理を紹介します。

「『ギット』って、聞いたことはあるけどイマイチよく分からない」であるとか「プログラミングする人が使うツールでしょ？」と思って、そっとこのページを閉じようとしたみなさん！

確かにGitはLinuxのシステム開発の為に生み出されたものであり、プログラムのソースコードの管理に利用されるケースが圧倒的に多いですが、使い方次第では対象がWordやExcelのドキュメントのような通常のファイル管理であっても十分過ぎるほど有用なんです。少しだけお付き合いください。

非プログラマー（マネージャーやディレクター、或いはデザイナーやHTMLコーダー等々）の方に向けて
全般的な（ソースコードだけに限らない）ファイル管理のためのバージョン管理システムを啓蒙できたらと思います。

まずは用語の定義から

バージョン管理システム（バージョンかんりシステム）とは、コンピュータ上で作成、編集されるファイルの変更履歴を管理するためのシステム。特にソフトウェア開発においてソースコードの管理に用いられることが多い。

概要

---

バージョン管理システムの最も基本的な機能は、ファイルの作成日時、変更日時、変更点などの履歴を保管することである。これにより、何度も変更を加えたファイルであっても、過去の状態や変更内容を確認したり、変更前の状態を復元することが容易になる。更に、多くのバージョン管理システムでは、複数の人間がファイルの編集に関わる状況を想定している。商業的なソフトウェア開発やオープンソースプロジェクトなどでは、複数の人間が複数のファイルを各々編集するため、それぞれのファイルの最新の状態が分からなくなったり、同一ファイルに対する変更が競合するなどの問題が生じやすいが、バージョン管理システムは、このような問題を解決する仕組みを提供する。ただし、バージョン管理システムを個人のファイル管理に使用することも可能であるし、ソフトウェアのソースコードだけでなく、設定ファイルや原稿の管理などにも使うことも可能である。

参照: Wikipedia 「バージョン管理システム」

「個人のファイル管理に使用することもできるし、対象はソフトウェアのソースコードだけに限らない」という旨の記述が心強いですね。

この言葉自体は単なるジャンル名なので、バージョン管理システムというカテゴリーの下に具体的な実装が無数に存在します。

今回はGitを取り上げますが「Subversion（サブバージョン）」、「Mercurial（マーキュリアル）」なんかも有名ですね。

「Git」とは？

git（ギット）は、プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システムである。Linuxカーネルのソースコード管理に用いるためにリーナス・トーバルズによって開発され、それ以降ほかの多くのプロジェクトで採用されている。Linuxカーネルのような巨大プロジェクトにも対応できるように、動作速度に重点が置かれている。現在のメンテナンスは濱野純 (Junio C Hamano) が担当している。
gitでは、各ユーザのワーキングディレクトリに、全履歴を含んだリポジトリの完全な複製が作られる。したがって、ネットワークにアクセスできないなどの理由で中心リポジトリにアクセスできない環境でも、履歴の調査や変更の記録といったほとんどの作業を行うことができる。これが「分散型」と呼ばれる理由である。

参照: Wikipedia 「Git」

Wikiだけ読んでも「？？？」ですが、

• プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システムである
• オープンソースのソフトウェアである
• Windows、Mac、Linuxなど、各プラットフォームに対応している

という辺りだけ押さえればとりあえずOKです。

GitHubとは？

このキャラクターのロゴ見たことありませんか？「Octocat」といいます。

GitHub（ギットハブ）はソフトウェア開発プロジェクトのための共有ウェブサービスであり、Gitバージョン管理システムを使用する。 Ruby on RailsおよびErlangで記述されており、GitHub社によって保守されている。 主な開発者はChris Wanstrath、PJ Hyett、Tom Preston-Wernerである。 GitHub商用プランおよびオープンソースプロジェクト向けの無料アカウントを提供している。 2009年のユーザー調査によると、GitHubは最もポピュラーなGitホスティングサイトとなった。

参照: Wikipedia 「GitHub」

後述しますが、Gitでは「リポジトリ」と呼ばれるデータベースにソースコードなどの変更履歴を記録します。
リポジトリを自分のPC内に作って、自分一人だけでファイル管理に利用する使い方もできますが、同じプロジェクトのチームメンバーと共有する場合には例えば社内サーバーのような共通してアクセスできる場所にリポジトリを作る必要があります。

GitHubの基本的なサービスはGitリポジトリのホスティングであり、（もちろん自前でインターネット上にリポジトリを用意することは可能です）これを利用することでインターネットを介して『何処からでも / 誰とでも』バージョン管理されたファイル群を共有することができる「OSSホスティングサービス」の一種ということになります。

参照: Wikipedia 「OSSホスティングサービスの比較」

ここでは「Git イコール GitHub」ではなく、「あくまでGitHubはGitを利用するためのサービスの内の選択肢のひとつ」ということを押さえましょう。

ファイルをバージョン管理できて、そのリポジトリにインターネット経由でアクセスできるという点に於いては、どのサービスにも差は無いんですが、GitHubが群抜きで知名度が高いのはリポジトリのホスティング以外にもSNS的な側面を持っており、世界規模でユーザーを抱えているためです。

例えばTwitterみたいに気になるユーザーをフォローしたり、Facebookで言うところの「いいね」的なリアクションをしたり、時には公開されているソースコードの間違いを見ず知らずの人が指摘してくれたり、等々、、、
GitHubでホスティングして公開したリポジトリ（のソースコード）を媒介として、世界中の開発者と（常人にとっては激マニアックな）交流をすることができ、世のオープンソースプロジェクトの普及と発展の大きな推進力になってきたんですね。

一方で社内プロジェクトや個人的なちょっとしたプログラムのリポジトリをGitHubに置いて全世界に向けて公開されてしまっては困ります。
こういった場合に各サービスで差異が出てくるんですが、GitHubの場合は有料プランに切り替えればリポジトリを非公開（限定公開）で作成することができるようになります。

別のサービスでは例えばBitbucketであれば、5ユーザーまでで共有する限定公開リポジトリであれば無課金で作成できます。（6ユーザー以上での利用から有料）

本記事ではこれらのリポジトリのホスティングサービスは利用せず、社内サーバーやVPSに自前でリポジトリを配置する前提で話を進めます。

Gitでファイル管理をしてみる

それでは架空のプロジェクトで実際の運用のされ方を見てみましょう。

（例）WEB制作の案件で、プロジェクトのチームメンバーはマネージャー、ディレクター、デザイナー、コーダーの4人です。

なお、操作はすべてMacのターミナルでGitコマンドを打つ前提で記述しますが、実際にはGitクライアントと呼ばれるアプリケーションで代替可能ですので安心してください。ただ、コマンド（命令）の類は頻出するGit用語なので「そういうおまじないがあるんだなー」程度に何となくでも覚えておくと吉です。

リボジトリを配置する

先ず、何はなくともリポジトリ（中心リポジトリ、リモートリポジトリと呼ばれます）が必要ですので、社内サーバーまたはVPSにリポジトリを配置します。（ここは社内のエンジニアの方が用意してくれるハズですので割愛）

メンバーそれぞれが自分のPCにリモートリポジトリを複製（git clone）します。複製されたリポジトリはローカルリポジトリと呼ばれます。

ちなみに「リモートリポジトリ」の中身はバージョン管理しているファイルそのものではなく、変更履歴を記録したデータの塊であり、クローンした時点で初めてファイルとして復元されます。

新規追加する

プロジェクトはまだ始まったばかりなので、この時点では何のファイルも存在しません。
まずディレクターが今回の案件の見積書を追加します。

手順としてはローカルリポジトリへの変更履歴の記録（git commit）と、ローカルリポジトリの変更内容のリモートリポジトリへの反映（git push）という2段階に分かれています。

これでリモートリポジトリには「見積書.pdf というファイルが新規追加された」という履歴が記録されたことになります。

この時点から、他のメンバーのPCにも見積書が共有されることになりますが、そのためには各PCでリモートリポジトリの最新状態（自分以外のメンバーによって加えられた変更の差分）をローカルに反映させる必要があります。（git pull）

マネージャーはディレクターに「見積書を見たいから添付して送って」とお願いする代わりにプルを行えば自分のPCに見積書が同期される訳です。

バージョンを更新する

翌日ディレクターはお客様と打ち合わせを行い、作成するWEBサイトの要件を取りまとめてきました。

想定していた作業ボリュームを上回ったので、見積りは再作成しました。

今回は再作成した見積書で前回の 見積書.pdf を上書きすると共に WEBサイト要件.txt を新たに追加してコミット、およびプッシュします。

以前のバージョンを確認する

マネージャーはプルを行って最新の見積書を同期しましたが、以前の金額が幾らだったのか確認したくなってしまいました。

見積書.pdf は上書き保存されているので、ディレクターのPCにも、同期後のマネージャーのPCにも以前の見積書は存在しません。

通常のファイル共有であればこれで手詰まりなので、代替案として「ファイル名に日付や連番を付けて以前のファイルを消さずに残す」といった対策が取られたりしますよね。

バージョン管理されたファイルは「何のファイルが、何時、誰によって、どの状態から、どの状態に変更された（あるいは新規追加、削除された）」といった完全な履歴を保持しているので、「見積書.pdf を昨日時点の状態に戻す」といった操作が可能です。（もちろん、その後で最新の状態に復元することもできます）

デザインデータやコーディングデータもファイル管理

その後プロジェクトは進行し、デザイナーがPSDファイルでWEBサイトのデザインを進めています。

デザイナーは作業の区切りが付くごとにPSDファイルをコミットしてプッシュするので、ディレクターとコーダーは自PCにプルして同期すれば常に最新の状態のデザインを確認できます。

デザインのOKが出たのでHTMLのコーディングが始まりました。

コーダーもデザインを確認しつつ、HTMLやスタイルシートのファイルを編集し、都度コミットしてプッシュして作業を進めて行きます。

PDFやPSDといったファイルは「バイナリデータ」と呼ばれる「0」と「1」の組み合わせでできたデータの塊としてのファイルですが、コーダーが取り扱うファイルはHTMLのソースコードやスタイルシートなど、基本的に文字ベースのテキストファイルです。

テキストファイルをバージョン管理した場合には、行単位、文字単位で変更を履歴に残すことができます。

「昨日までは問題無く表示できてたのに、今日作業してるうちに崩れてしまった」なんて時に、記憶を頼りに思い出すよりは変更の差分だけを当たった方が原因究明が圧倒的に早いですよね。

もちろんHTMLのソースやディレクトリの一式はデザイナーにも共有されるので、画像ファイルの書き出しや差し替えだけはコーダーではなくデザイナーが担当する、といった共同作業も可能です。

復元する

後日WEBサイトは無事完成し、納品も済みました。

プロジェクトは完了したので、各メンバーはもうローカルリポジトリは削除して構いません。

もし半年後に修正を依頼されたとしてもサーバーにリモートリポジトリさえ残っていれば再度クローンすることで最後にコミットされた時点の作業環境をすぐに復元することができ、すぐに対応できる訳です。
（見積書や請求書のようなドキュメントを参照したい場合も同様ですね）

まとめ

いかがでしたか？

具体的な操作に関してはターミナルでコマンドを打つのか、SourceTreeやGitHub DesktopのようなGUIツールを導入するかで変わってくるので端折りましたが、何となく「Gitだと、こんなことができるんだー」とポジティブな印象を持ってもらえれば本記事の意義は達成出来たと思います。

次回は具体的なGitコマンドの説明とツールの紹介、そしてバージョン管理システムの鬼門「コンクリフト（競合）」について触れたいと思います。