Gitを知らないプログラマーにGitを教える際の導入

gistfile1.txt

この記事はGitの導入記事ではあるが、教育者目線で話を進める。もちろんこれからGitを始めたいという人も歓迎する。  
ここに書かれていることはGitの使い方ではなく、そもそもどうしてGitが必要なのかということと簡単な歴史の振り返りであり、導入である。

# もくじ

[:contents]

# はじめに

Gitを教える際は何よりも、バージョン管理システムの歴史を教えることが一番の近道のように思う。これはGitに限らず、プログラミング言語などを教えるときも同様だ。なぜそのシステムが必要なのか把握してもらい、それを実現するためにプログラマーがどんな道のりを歩んできたかを伝えることによって、そのシステムを深く理解してもらえる。（ような気がする）

# 導入

はじめは、バージョン管理システムとはどういうものかを聞かせる。  
「コンピュータで作成するファイルの作成、編集を管理するためのシステム。 ファイルの作成日付、変更日、変更点などをシステムで保管して、過去の状態や変更内容を見たり過去の状態に戻したりできる。」  
などという話だ。ここではこれ以上難しい話は止めておくべきで、ファイルの変更点が管理できるというイメージさえ掴んでもらえれば良い。

多少イメージを掴んでもらえれば、バージョン管理システムを使わない環境で発生するファイルの管理方法を教える。例えば、こういうやつだ。

- 仕様書
- 仕様書_最新
- 仕様書_旧
- 仕様書_新

実際はアンダーバーの後は日付が多いかもしれない。こういうファイル群は確かにバージョン管理ができているが、とても管理がやり辛い。こういう管理方法ではバージョンの番号を自分がつけないといけないし、複数人が修正した場合は手動で統合しなければならない。（教育者として受講者には、これがクソだということをはっきりと教えてやらなければならない）

ここでバージョン管理システムの話を始める。  
「ファイルに複数の変更がかかると整合性が保てなくなることもあるので、一人でも複数人でもソースコードを管理するのは基本的に辛い。そういう苦行を無くすため、バージョン管理システムは日々進化してきた。」  
ここであたかも銀の弾丸かのようにバージョン管理システムについて話すことで、アンダーバーでファイルを管理する方法はクソであり、Gitなどのバージョン管理システムが神であるという考えを受講者に植え付ける。（これは事実だ）

# 歴史

さて、バージョン管理システムが神だということを伝えたあとは、バージョン管理システムの歴史を順に語っていこう。いきなりGitを説明するより、大まかにでも、このシステムが生まれたころからの流れを説明したほうが理解しやすいはずだ。だいたいこのあたりを説明すれば十分だと思われる。

- RCS（ロックアンドモディファイ）
- CVS（エディットアンドマージ）
- svn（アトミック・コミット）
- git（分散バージョン管理）

このあたりの歴史を、ファイルとリポジトリの図などを交えながら説明すると効果的だろう。なぜGitが必要とされているのかは理解してくれたならば、ここからGitのローカルリポジトリ・リモートリポジトリ、そしてコミット、プッシュ、ブランチなどの話に繋げていくのが理想的ではないだろうか。  


## 1982年: RCS（ロックアンドモディファイ）  

これが初期のバージョン管理システムになる。  
編集するファイルにロックをかけて他のユーザが編集できないようにし、編集が完了したらコミットしてロックを解除する方式。編集する際にロックされるので1ファイルにつき最大1人までしか編集できないし、コミットされなければ永遠にそのファイルを他の人が編集することができない。（この時点で、コミットとは「編集を確定してシステム上のファイルに反映させること」ということも教えておいたら良い）

## 1990年: CVS（エディットアンドマージ）  

エディットアンドマージ（コピー・マージ方式）では編集するファイルをシステムからローカルにコピーし、このコピーを編集する。編
集が完了したらシステム上のファイルと合体させる。元ファイルとの差分のみを取り込むマージ機能によって、複数人のユーザが同じファイルを編集できるようになった。

## 2000年: svn（アトミック・コミット）  

アトミック・コミットが誕生する。今までは1ファイルごとにコミットしなければいけなかったが、この機能によって複数のファイルを1度にコミットすることが可能になった。

## 2005年: git（分散バージョン管理）  

分散バージョン管理システムが誕生する。  
中央のシステムに繋がっていなくてもローカルでコミットが出来るようになり、ローカルでコミット、リポジトリへプッシュするスタイルが確立されていく。電波の無い場所でも細かい単位でコミットできるようになり、インターネットに接続した時にプッシュでリポジトリに反映すればよいなど、分散バージョン管理システムならではの便利な機能が複数含まれている。  
（gitではコミットの意味が今までと少し変わり、リモートへの反映ではなく、差分の作成となる。代わりにプッシュがリモートへの反映となった（正確には差分の作成ではないが、ここでは気にすることではない））


（休憩）