Web制作者のためのGit入門 第1回 Gitでできること
Web制作に必要なHTML、CSS、JavaScriptなどのソースコードのバージョンを管理するためのシステムGitの解説をします。第1回目はGitでできることを紹介し、大まかなイメージをつかんでもらいたいと思います。
Gitとか、GitHubとか、聞いたことありますか？
Git（ギット）、使ってますか？
Gitという名前は、最近はかなり知れ渡っている印象があるので、よく知らないよという方も、言葉くらいならば聞いたことがあるのではないでしょうか。
GitとGitHubを混同している方もたまに見かけます。GitとGitHubは同じものではないんです。まずは、このあたりから簡単に解説していきましょう。
Gitは簡単にざっくりいうと、ファイルの共有をしたりソースコードの履歴やバックアップを管理するために使われるシステムの名称です。
プロジェクトとして登録したフォルダ以下のファイル群を監視し記録してくれます。そのデータを複数人で共有する場合、サーバーを介してやりとりします。
そのサーバーも自分で用意するとなると、Git用のサーバーとして使えるように設定したりしなければならず、ちょっと面倒です。
GitHubは、その共有のためのサーバースペースを貸してくれるサービスです。ユーザーは、アカウントを作るだけで利用することができます。また、共有されるコードがオープンソースであれば無料で使うことができます。GitHubはこのようなGitのためのサーバー機能に加え、Wikiやタスク管理的な機能もついていて、SNS的に使えるようになっているのです。
Gitそのものが流行ったということもありますが、このソースコードをSNS的にユーザー間でやりとりできる点で、GitHubは人気があり、よく知られるサービスとなりました。
本シリーズでは、Git自体がそれはどんなものかという詳しい解説と、インストールから実際に使ってみるところまでを解説します。サーバーにはGitHubを使います。
Gitはちょっと聞いたことあるけど、まだ使う気にはなれないという人の大半は、あの例の「黒い画面」から、呪文みたいなコマンドを叩かなくてはならないと、敬遠しているのかもしれません。でも、実は「黒い画面」を使わなくてもGitは使えちゃうんです。このシリーズでは、黒い画面をほとんど使わずに解説するので安心してください。
開発時に起こりうる本当にあった怖い話
さて、Gitの本格的な説明に移る前に、Gitを使わなかった場合に起こりうるミスや問題点をみていきましょう。
Gitはソースコードを管理して共有もできるシステムだと前述しました。しかし、ファイル共有したいだけであれば、手軽に使えるDropboxなんかが有名です。
そういったツールを使わないにしても、開発用サーバーを用意してそこにアップしたり、zipでまとめてメールやFTPで送受信したりすることで、共有自体は可能です。
ソースコードの履歴にしても、コメントを残せばよいですし、バックアップもまめに手動でとればいい話です。圧縮ファイルやファイルの名前に日付を含めるというよくあるパターンです。
Gitなんて小難しいものを使わなくても、共有はできるし、履歴は残せるし、問題ない。むしろGitを使う学習コストが問題だ、と思うこともあるでしょう。
ただそのような連携・管理をしていると、次のような問題に出くわしたことがあるはずです。
背筋も凍る怖い話：みんなで作業編
- 自分が編集したページを他の人も同時に編集していて、どちらか片方の作業が消されてしまった。
- どこかを誰かが変更したために、自分の作業範囲で不具合が起きてしまったが、誰のどの部分の変更が原因かわからない。
- プロジェクトのディレクトリ内の全ファイルを対象に置換を行いたいが、他に編集中の人がいるので、みんなが編集をやめる時間まで待たなければならない。
- サーバーの不具合や人為的ミスにより、サーバー上の最新データ一式が、おかしな状態になってしまった。
- おかしな状態ならまだいいが、最新データ一式が全部消えてしまった。
面倒なことこの上ないですね。「あーもう！」とか言いながら、貧乏揺すりが止まらないことでしょう。
これらは主に複数人でファイル共有していると起こるケースですが、ひとりで開発している場合でも、次のようなことがあるはずです。
背筋も凍る怖い話：ひとり作業編
- バックアップをとらずに全ファイル置換してしまって、置換前の状態に戻せなくなった。
- バックアップをとっていたが、どんな作業をしていた時点のものなのかわからない。
- index.html.bkなどのゴミファイルの山になってしまって、本番環境にもあげてしまったり……。
- 画像書き出し時などに間違えて必要な別のファイルを上書きして消してしまった。
どうです？ けっこうやりがちですよね？
Gitを使うと、このような問題が起きるのを防ぐことができたり、万が一問題が起きても解決方法が残されています。
Gitでできること
Gitと同じようなことができても、Gitでなければいろんな問題に出くわしがちです。ではなぜ、Gitを使うとこれらの問題を解決できるのでしょう。
Gitでできることはどんなことなのか、もう少し詳しくみていきましょう。
同期するだけでなく、ファイルの中身まで管理
たとえば、同期と履歴を残すということを考えると、Dropboxも似たようなことをしてくれます。指定したフォルダの中を監視し、自動で同期してくれた上で、各ファイルごとのバックアップもとってくれます。けれどDropboxは、ファイル内のどこを変更したかまでは見ていません。
一方、Gitは、ファイル内の何行目の何文字目を変えたのかまで記録してくれます。Gitはソースコードの管理に特化したシステムなのです。
複数人の変更箇所をまとめて反映
たとえば、複数人が同時に同じファイルを変更した場合、Dropboxは両者の変更のどちらのファイルを正とすればよいかわからなくなってしまいます。
Gitはファイルの中身まで管理しているので、こういった場合も自動で解決してくれます。両者が同じファイルのどことどこを変更したのか見比べ、お互いの変更を反映した最新の状態にしてくれるのです*。
*注：編集の競合
「もし複数人が、同じ箇所に異なる編集をしたらどうなるだろう？」という疑問がわく方もいるかもしれません。もちろんGitはそのような状況も想定内です。詳しくは次回以降、解説していきます。
手動で履歴を記録、変更内容は自動で監視
Dropboxはファイルを所定のフォルダに保存すると、自動で同期・バックアップを行ってくれますが、Gitは手動です。
自分の任意のタイミングで、ひと作業ごとに、その作業ではどのファイルと、どのファイルの、どの部分を変更したのかローカル環境に保存していきます。
すごく面倒な感じがしますが、どのファイルを変更したかや、そのファイルのどの部分がどのように変わったのかは、Gitが自動で監視してくれています。
ですので、ユーザーはひとまとまりとしたい作業に、あとから見てわかりやすいようにタイトルをつけます。そのタイトルのひとまとまりの作業には、自動的に全部の変更点が記録されてしまうわけでなく、どの変更点を含めるかも任意に決めることができます。
このひとまとまりの作業の記録のことを、「コミット」といいます。
作業の一区切りごとに細かくどんどんコミットを残していきます。
このコミットは後からいつでも、すべてのコミットの一覧と詳細を参照することができます。さらに、プロジェクトをあるコミット時点の状態に瞬時に復元することができます。
GitHubでのjQueryのコミット一覧。コミット内容の概要（変更箇所や、バグフィックスの内容など）・コミットしたユーザー・日時・コミットの固有番号などが時系列に並ぶ。
一覧からひとつのコミットを選択すると、その詳細が表示できる。src/support.jsの68行目が変更され、trueが追記されたことがわかりやすく表示されている。
コミットは手動でサーバーにアップ
実はGitは、ファイルデータそのものを共有するのではなく、このファイルの変更などが時系列に記録されているコミットのデータをやりとりすることで、ファイルの情報を共有します。
コミットを保存したらコミットのデータをサーバーにアップします。これも任意のタイミングで行うので、ひとコミットごとにアップしてもいいし、いくつかのコミットをまとめてアップしてもOKです。
もっと言えば、いつまでもアップしないで、ローカルだけにコミットのデータを残しておくこともできます。ローカルにあるだけなので、もちろん他の開発者と共有することはできませんが、それでも十分に恩恵を受けられます。これについては、次回以降で詳しく解説していきます。
Dropboxのように自動で同期されるのは楽ちんではありますが、それゆえに弊害もあります。例えば、誤ってプロジェクトのフォルダをまるっと移動してしまったりすることはたまにありませんか？ そうすると、同期しているすべてのユーザーのPCでも、それが同期されてしまうのです。
Gitは手動だからこそ、そういった場合は同期しなければいいし、そもそもコミットしなければ記録されません。元に戻すときも、前回のコミットの状態をすぐ復元できます。
Gitでできることをざっと概観しましたが、次回以降、よく使う基本的な機能を、改めて詳しく説明していきます。ここでは、Gitができることを大まかに頭に入れてもらえればと思います。
さまざまなバージョン管理システム
ここまで「Gitは〜」とか「Gitなら〜」と解説してきましたが、なにもこれらの機能はGitの専売特許ではありません。
Gitのようなシステムを総称して「バージョン管理システム（VCS：Version Control System）」といい、他にもこのようなシステムはいくつか存在します。
Git以外で有名なものには、「Subversion（SVN）」などがあります。このSubversionは、Gitより古くから存在しており、今も現場で使われています。
SubversionもGitとほぼ同じことができますが、一番大きな違いは、コミットをどこに保存するかです。
Gitは、各PCのローカル環境にコミットを保存し、さきほど述べたように任意のタイミングで、手動でサーバーにアップします。ですので、オフラインの状態でも、ローカルにあるコミットはいつでも確認できるし、その状態に復元することもできます。ひとりで使うだけなら、サーバーがなくても使えるのです。
Subversionはコミットはローカルには残さず、必ずサーバーに残します。そのため、コミット履歴を確認したいときも、ある時点に戻したい時も、まずサーバーに接続する必要があります。
さらに、サーバーにしかコミットの情報がないので、サーバー自体のデータが壊れてしまうと大変です。ですので、サーバー自体のバックアップが必須です。
その点Gitは、同期したタイミングでコミットの履歴を、各開発者のPCのローカル環境に同期して残します。
ですので、サーバーのデータが壊れてしまっても、どこかのPCのローカルにはデータが残っており、そこから復元可能です。作業者が増えるごとに、作業者の数だけバックアップをとっているようなものです。
この違いから、Subversionのようにサーバーにコミットを保存するものを「集中型バージョン管理システム」、Gitのように各PCのローカル環境にコミットを保存するものを「分散型バージョン管理システム（DVCS：Distributed Version Control System）」と呼びます。
コミットのデータはサーバーにしか存在しないので、必ずサーバーへのアクセスが必要になる。サーバー自体のデータが壊れてしまうと、コミットのデータが全滅してしまうので、サーバーのバックアップが必須。
各PCのローカル環境にそれぞれのコミットのデータを持つので、履歴の確認などは手元のデータを参照し、同期する場合のみサーバーにアクセスする。サーバーへのアクセスは必ず必要なわけではない。
この分散型であることも、最近Gitが人気の理由のひとつです。
今回はGit（バージョン管理システム）を使わない場合の問題点と、Gitができること、バージョン管理システムの概要について解説しました。次回はGitのインストールやひとつひとつの機能の詳細を解説します。