Gitって何？便利なGitのメリットまとめ

近年、プログラマーやデザイナーが、「Git」※を使う機会が、とても増えました。

Gitを使うことが前提の仕事場も多く、Gitがわからないと、仕事を始めることがままならないこともあります。

そもそもGitとは、いったい何なのでしょうか？

※Gitの読み方は「ギット」や「ジット」とばらつきがあります。本書では「ギット」で統一します。

Gitは、ひとことでいえば、「さまざまなファイルを、まとめて管理するためのツール」です。

ファイルを管理する領域のことを「リポジトリ（repository）」と言います。日本語で言えば、貯蔵庫です。リポジトリを操作するには、「Gitクライアント」というソフトを使います。

つまり、「Gitを使う」ということは、「Gitクライアントというソフトを使って、リポジトリという貯蔵庫のなかにファイルを保存したり、取り出したりすること」に過ぎません。リポジトリは、好きなだけ作ることができます。用途別に、それぞれ作るのが一般的です。たとえば、「開発案件A」「開発案件B」など、プロジェクトごとにリポジトリを作って、そのプロジェクトに関するファイルをひとまとめにして管理します（図1-1-1）。

Gitを使う理由は、主に次の3つのメリットがあるからです。

この3つのメリットについて、それぞれ見ていきましょう。

第一のメリットは、更新履歴を管理できることです。

リポジトリに対して、ファイルの保存や変更、削除などのファイル操作をすると、その履 歴が、すべて記録されます。その記録を元に、いつ誰が、どのファイルを、どのように修正したのかを確認したり、一部の変更操作を取り消したりすることができるのです（図1-12）

システム開発の現場では、プログラムに修正を加えたときに、うまく動かなくなってしまうことは、よくあります。

Gitを使っていれば前の状態との違いがわかるので、どの変更によって、動かなくなってしまったのかが突き止めやすくなります。

履歴を確認して、「ある時点」と「ある時点」とで生じているファイルの違いのことを「差分（diff）」と言い、差分を確認する操作を「差分をとる」と表現します。

またデザインを変更したときに、「前のデザインのほうが良かった」ということも、よくあります。そうしたときでもGitを使っていれば、簡単な操作で、前の状態に戻せます。

過去の時点に遡るだけでなく、遡ったあとで、また戻ってくることもできます。たとえば、以前の状態はどうであったのかを確認したあと、いまの状態に戻るというような、タイムトラベルも可能です。

また過去に遡って、変更された箇所の一部だけを適用することもできます。たとえば、ある時点で、「Aという変更」と「Bという変更」の2つの変更を加えたとき、「Bの変更は破棄して、Aの変更だけを反映させる」という操作もできます。

第二のメリットは、チームの共同作業がしやすいことです。

リポジトリをサーバーに置けば、プログラマーやデザイナーなど、システム開発に携わる人たちみんなが、このリポジトリで管理されているファイルを操作できます。つまり、リポジトリを使った共同作業ができるようになります（図1-1-3）

ファイルサーバーやFTPなどでファイル共有するのと似ていますが、誰がどのようなファイルを書き換えたのかを確認したり、上書きを防いだりできるメリットがあります。

リポジトリのファイルを操作すると、操作履歴が残ります。ですから、「誰が、いつ、どのファイルを編集したのか」がわかります。

そして、もし、その変更が適切でない場合には、操作履歴を遡って、変更を取り消すこともできます。たとえば、誰かがうっかり間違えた場所を修正したり、ファイルを削除したりしても、すぐに元に戻せるのです。

Gitでは、ファイルの違いを、差分として確認できます。

たとえば、1つの同じファイルをプログラマーとデザイナーのそれぞれが編集し、その変更をリポジトリに保存しようとしているとします。いままでのファイルサーバーやFTPなどによる方法だと、後から書き込んだほうが上書きしてしまいます。

しかしGitでは、プログラマーの変更箇所とデザイナーの変更箇所を、うまく取り混ぜて、リポジトリに保存できます。この操作を「マージ（merge）」と言います（図1-1-4）。

こうしたことができるのは、Gitは更新履歴から差分をとれるからです。マージは、「プログラマーの変更結果とリポジトリ上のファイル」「デザイナーの変更結果とリポジトリ上のファイル」を比較し、その差分をリポジトリ上に反映することで実現しています。

ただし、こうしたそれぞれのユーザーの変更が、いつでもうまく反映できるとは限りません。

たとえば、それぞれのユーザーが、ファイルの同じ箇所を変更している場合には、どちらの変更を活かせばよいのかの判断がつかないためエラーとなり、リポジトリに保存できません。こうした状態を「競合（コンフリクト）」と言います。（図1-1-5）。

実は、Gitの使い方で一番難しいのは、この競合です。なぜなら競合が発生すると、それを解決するまでは、リポジトリへの保存ができなくなってしまうからです。

「競合が発生する理由」「発生したときに、どのような操作をして解決するのか」は、本書の大きなテーマのひとつです。

第三のメリットは、異なる保存場所をまとめて管理して、切り替えられることです。

システム開発の現場では、「開発」「テスト」「本番」など、いくつかの工程があります。

プログラマーやデザイナーが作ったものは、ある程度、動くようになったところで、テスト段階に入ります。テスト中に、新しい機能や修正が加えられるとテストのやり直しになってしまいますから、テスト中はファイルを変更しないようにします。そしてテストが終わったら、それを本番環境で動かす納品物とします（図1-1-6）。

こうした「開発」「テスト」「本番」の流れをとる場合、それぞれを、別の場所で管理する必要があります。つまり、「開発で使うファイル群を管理する場所」「テストで使うファイル群を管理する場所」「本番で使うファイル群を管理する場所」というように、それぞれの保存場所が必要です。

Gitでは、リポジトリに対して、こうした別々の保存場所を用意することができます。これを「ブランチ（branch）」と言います（図1-1-7）。

どのブランチに対するファイル操作をするのかは、簡単に切り替えられます。また、それぞれのブランチに含まれているファイルの違い（差分）を確認したり、一部だけを、別のブランチ（保存場所）に反映したりすることもできます。実際そうすることで、たとえば開発中の機能の全部ではなく、一部の機能だけをテストのブランチに適用するということができ、完成したところからテストしていくことができるようになります。

これまで説明してきたように、Gitを使うメリットは大きく3つありますが、チームでの共同作業がしやすいのが最大のメリットです。

もしGitを使わなければ、ファイルを編集する際には、誰かが編集中でないかを確認し、編集してよいかを尋ね、それから編集をはじめて保存するというような、「編集の際の声がけ」をしなければなりません。

それに対してGitを使えば、操作履歴が保存されるので、間違って誰かの変更を上書きしてしまってもすぐに戻せます。

そもそも誰かの変更を上書きしてしまう恐れがあるときは、競合というエラーになります。ですから、編集の際の声がけは必要ありません。各自が好きなタイミングでファイルを編集して、それをリポジトリに戻すだけでよいのです。Gitで作業すれば、全員の編集結果がリポジトリ上に1つにまとめられていきます。

最近は、リモートオフィスなど、チームのメンバーが顔を合わせずに、好きな場所で好きな時間に仕事する機会が増えてきました。こうした、各自が異なる場所、異なる時間に仕事するような環境では声がけするのが難しいですから、もはやGitは欠かせません。Gitを使えば、すべての記録が残りますから、チームのメンバーがどの程度のペースで仕事を進めているのかもわかります。

本書では主に、チーム開発でGitを使う場面を想定しますが、サーバーにリポジトリを置かずに、自分一人だけでGitを使うこともできます。

Gitを使えば、保存前のファイルに戻したいとか、間違って消したファイルを戻したい、前回の保存と今回の保存とで、どこを変更したのかを確認したいなどの操作ができるようになりますから、一人だけで使う場合でも、そのメリットは大きいです。

Gitの用途は、システム開発にとどまりません。履歴を確認できると推敲しやすいという理由から、ドキュメントの執筆の際に、Gitを使っている人もいます。