私自身gitを初めて触るにあたって、サルでもわかるgit入門というサイトには非常にお世話になった。あのサイトは極めて分かりやすく書かれているし、丁寧だ。しかし、私はサル未満の存在だったらしく当時はいまいちよく分からなかったので、こうしてさらに噛み砕いたgit入門を書くことにした。私自身、まだgitのことはよく分かっていないので、色々と間違っていたら申し訳ない。
この記事の対象
この記事を書いた意図
- 世間に溢れるgit入門は「早速gitを触ってみよう！」系が多かったので、こうした概念説明だけをしっかりやる入門があっても良いかなと思った。
- 私自身の知識の整理。
注意
- 執筆者自身もgit初心者なので間違っている点もあると思います。コメント欄などで指摘していただけると、私の理解も深まるのでとてもありがたいです。
- この記事は、「gitとは何か」「どんなときに使うのか」「git関連の言葉の意味は何か」などの説明が主なので、この記事を読んだからといってgitが使えるようになるわけではありません。もし実用的なgit入門をお望みでしたら、この後にリンクで貼る参考サイトを当たられると良いと思います。
- 初心者にも分かるようにできるだけ平易な表現を用いたため、一厳密さに欠けた表現、冗長な表現があるかもしれません。
参考にしたサイト様
では、早速gitの世界に飛び込んでみましょう。
１．で、gitって何なの？
私もよく分からない。分からないけど、そのことを嘆いていても仕方が無いのでとりあえず、偉大なるWikipedia先生に聞いてみよう。
Wikipediaによると、gitとは、
プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システムである
と、まあ、これを読んで分かる人間はそもそもこの記事を読まないと思うので、もっと噛み砕いて説明していく。
まず、文言を解釈してみよう。
Wikipedia大先生によると、gitというのは「バージョン」を「管理」する「システム」であるらしい。「管理」と「システム」は一般名詞として分かると思う。問題は、「バージョン」だ。バージョンというのは、日本語で言うと「版」だ。第１版とか、第２版とか。で、当然、版が変わるとその中身が変わるはずだ（例えば、辞書だったら第１版と第１０版では収録している言葉も変わる）。逆に言えば、バージョンが分かれば、そのブツがいつ作られたか、中身がどうなっているのか、他のバージョンとはどう違うのか、が分かる。また、「分散型」というのは「みんなで」程度の意味だ。
ここで、再びWikipediaの引用文に立ち戻ると、gitというのは、「プログラムのソースコードなどの」「バージョン管理システム」らしい。
待て待て。「変更履歴を記録・追跡するための」という文言はどうした。これは要するに「バージョンの変化に伴って加えられた変更の履歴を記録・追跡するための」という意味だ。
要約
これまでの解釈を全て合わせると、gitとは、「プログラムのソースコードなどのバージョンの変化に伴って加えられた変更の履歴を記録・追跡するための、みんなでバージョンを管理するシステム」ということになる。長い。長いが、噛み砕くとこうなる。
ここまでは面倒な定義の解釈をしてきたが、「gitって、プログラムのソースコードの変更履歴を管理するものなんだな」程度に思ってくれればいい。次の章からは具体的にどういうことなのかについて話そう。
２．で、gitっていつ使うの？
gitは何か、という問いに答えるにあたってこの問いに答えることは欠かせない。
プログラムのソースコードを書いていると、一気に全てのコードを書き上げることはそんなにない。書いては修正しを繰り返すはずだ。この作業が一人で、しかも一つのファイルでやっているならいいだろう。間違えたときのためにバックアップをとりたければ、編集する前にファイルをコピーしておけばいい。もし、ソースのどの部分をいつ編集したかを履歴に残しておきたければ、面倒だがメモを残しておけばいい。
だが、二人以上で一つのソースを編集していたらどうだろうか。両方が同時にソースの同じ場所を書き換えてしまったために、先に書き換えた人の変更が消えてしまった経験は無いだろうか。また、二人で更新していると、誰が、いつ、どこを更新したのか分からなくなるし、管理も大変になる。ましてや、普通のプロジェクトはもっと大人数で管理するので、それを人力で全て不都合なく遂行するのはそれこそ超能力の類だろう。
それに、バックアップをとることを考えよう。数万行のソースファイルを数十個も、変更のたびにバックアップをとっていたらいくらHDD容量があっても足りないし、また毎回コピーするのも手間だ。とても人のする作業ではない。
ということで、次の結論に至るわけだ。
「人力が無理ならプログラムにやらせればいいじゃないか！」
そう、それをやってくれるのがgitだ。
要約
つまり、gitは主に複数人で共通のファイル（主にプログラムのソースコード）を編集する際に利用される。
３．で、gitって何やってくれるの？
お待たせした。この章でようやく具体的にgitとは何かを説明する。
gitは、バージョンを管理するシステムだというのは繰り返し記した通りだ。では具体的にどうファイル（たち）のバージョンを管理するのだろうか？
最初に概観を見よう。gitのやってくれることは「ファイルの変更履歴の管理」だ。これによって、上述したバックアップの問題も解決する。
詳しく見て行こう。
コミットというもの
gitは、ファイルの変更履歴を記録しておくことでバージョン管理をする。どのファイルが、誰によって、いつ、どのように、変更されたかというのを記録・管理してくれるのである。この記録の一つ一つをコミットという。おお、なんかgitっぽい言葉が出てきたぞ。しかし、恐れることなかれ。コミットというのは要するにただの「ファイルの変更履歴」だ。「Aさんが、水曜日の5時に、program.cというファイルの、3行目を、こういう風に変更しました」ということが書いてあるだけだ。では、コミットはどうやって作るか。これは、ファイルの変更をした後にgitに「コミットを作って！」と伝えれば、後はgitが勝手に生成してくれる。つまり、自分で「誰が、いつ…」などと書く必要は一切ない。そしてややこしいのだが、このコミットという記録を残す操作それ自体もコミットと呼ぶ。
コミットの嬉しいことは２つある。
- 変更履歴だけを記録するので、バックアップの際にファイル全体をコピーしておく必要がなく、全体のファイル容量が少なくて済む。
- コミットに書かれた変更履歴を見るだけで、誰がいつどこをどのように変更したか分かるので、それを元にファイルの状態（バージョン）を更新できる。
１．については、変更履歴を全て記録しているので、「やべ、なんか変えたら動かなくなった！」ってときも、その履歴を辿れば動くときの状態に戻せる（要するに、バックアップをとっているのと同じこと）。
２．のファイルの更新についてはgitが勝手にやってくれるので、我々がコミットとにらめっこしながら「ええっと、ここはこう更新されてて、その後にこの人がまた更新したから…」などと悩む必要は無い！ 素晴らしい！
※厳密には、全く同じ箇所を別の人が同時に変更してどちらもコミットを作ると衝突（コンフリクト）というものが起きて、人力で解決しなければならなくなることもあるが、これは今は気にしなくて良い。
リポジトリというもの
コミットがどういうものか、何となく分かっただろうか。さて、当然コミットそれ自体はファイルの１種なのでどこかに保存しておかなくてはならない。gitにおいて、管理の対象であるファイル（ソースコードなど）やコミットを保存しておく場所をリポジトリ （日本語で、倉庫・貯蔵庫）という。要するにgitで管理されたフォルダのようなものだ。そして、当然これらのファイルは自分のPCだけにあっても仕方がなく、みんながアクセスできるところにもなくてはいけない。自分のPCにあるリポジトリをローカルリポジトリ（以下、ローカル）、みんながアクセスできるオンライン上（実際はどこかのサーバの上）にあるリポジトリをリモートリポジトリ（以下、リモート）という。巷でよく耳にするgitHubというのは、このリモートリポジトリを提供してくれるサービスのことだ。ローカルリポジトリは自分の作業スペース、リモートリポジトリは共有の作業スペース、と解釈してもらって構わない。
ローカルにあるソースファイルに変更を加えてコミットすると、ローカルにコミット（変更履歴）が作成される。ここで注意すべきは、この時点ではまだリモートにはこのコミットがコピーされていないということだ。他の人がそのコミットを見られるようにするためには、ローカル上のコミットをリモートにコピーする必要がある。この作業をプッシュという。プッシュすると、ローカルでのコミットがリモートにも反映される。そして、このタイミングで初めてリモートにあるソースファイルにも変更が反映される。つまり、ローカルリポジトリでどれだけソースを変えてコミットしても、プッシュするまではリモートリポジトリには反映されない。
さて、これでローカルでの変更をリモートに反映させることができた。では、リモートで生じた変更は即座に各人のローカルのファイルに反映されるのだろうか。いや、それでは困る。もし自分がファイルを編集している最中に、他の人のプッシュによって自分の書いているファイルが目の前で書き換わったら、それこそ作業にならない。ということで、プッシュのときと同様に、リモートの変更をローカルに反映させる操作も、好きなタイミングで行うことが出来る。このリモートからローカルへの反映を、プルという。プッシュ（押す）の反対でプル（引く）だ。これにより、他の誰かがリモートに上げたコミットを元に、自分のローカル上のファイルを更新することができる。
以上に見たように、コミット、プッシュ、プルを好きなタイミングで各自がすることで、自分の作業は他人に邪魔されず、自分の作業で他人を邪魔することなく、オンライン上でファイルの変更履歴を上手く管理できる。
要約
- 変更履歴を記録したものをコミットといい、コミットを作る操作もコミットという。
- ファイルやコミットの保管場所をリポジトリといい、リポジトリには、個々のＰＣ上にあるローカルリポジトリと、オンライン上にあるリモートリポジトリがある。
- ローカル上の変更をした後はコミットを作り、それをリモートにプッシュすることで初めてリモート上にもコミットがコピーされる。
- リモート上の変更をローカルに取り込みたいときは、プルをする。
長くなってしまったが、以上の概念さえ分かればgitはほとんど怖くない（はずだ）。
４．で、gitってどう使うの？
具体的な使い方については本サイトでは詳しく説明しない。下記のリンク先を参考にすると、あまり困難なくgitが導入できると思う。
ここでは、実際にgitを使った際に戸惑うかもしれない概念について軽く説明したい。
ブランチというもの
プロジェクトを開発していると、１つのプログラムの機能Aと機能Bをそれぞれ同時に開発したいときがよくある。そんなときに、機能Aと機能Bを同じ場所で互いに更新をしていると訳がわからなくなったり、機能Aが不完全なまま機能Bを更新したせいで動かなくなる、なんてことも起きかねない。それを解決してくれるのがブランチという概念である。ブランチは日本語に直すと「枝」であり、その名前の通りバージョン管理に複数の枝分かれを作ることができる。前述の機能AとBについて考えるなら、「機能Aを作るブランチ」と「機能Bを作るブランチ」を切り分けると、それぞれのコミット内容は独立してブランチごとに管理されるため、お互いに混ざり合うことが無い。これについてはサルでも分かるgit入門に分かりやすい図が載っているので引用させてもらいたい。
上の図のように複数の機能を同時に開発し、機能が完成したり一段落ついたところで一つに合わせる（これをマージという）ことで、並行して色々なものが開発できる。
これらのブランチの作り方は簡単だ。gitに「ブランチを作りたい！」と言えば、好きなノード（ファイルたちの更新状態）から、ブランチを生やすことができる。そして、最も本流となるブランチをmasterブランチという。（いや、最も本流なんだから枝じゃなくて幹だろ、とか思うかもしれないがそういうものなので許して欲しい。）
そして、たくさんあるブランチの中で、自分が今いるブランチを変えることをチェックアウトという。例えば、「masterブランチにチェックアウトする！」とgitに伝えれば、masterブランチに移動することができる。ここで大切なのが、プッシュ先は特に指定しなければ現在自分のいるブランチになるということだ。これは極めて自然なことで、他のブランチと更新履歴がごちゃ混ぜにならないようにブランチを分けているので、自分は他人を邪魔せず、自分も他人から邪魔されずを実現できる。
要約
- 更新履歴の流れの枝をブランチといい、一番メインのブランチをmasterブランチという。
- 現在いるブランチを変更するにはチェックアウトする。
- プッシュ先は、基本的には自分が今いるブランチになる。
５．まとめ
さて、ここまでgitについて簡単に説明してきたつもりだが、どうだっただろうか。私自身、初めて記事を書いたことに加え、git初心者なので至らない点も多々あったと思う。他の色々なページを読み進めるに当たって、この記事がgitの理解の一助になれば幸いである。
また、何か問題のある点や、間違っている点などがあれば指摘して頂けると嬉しい。
それでは、よいgitライフを。
追記：誰か僕にgitを教えてください。
