■Git事始め！
Gitというのは簡単に説明すると、作業の履歴の殆どを覚えていてくれて、たとえファイルを消してしまったとしても、もとに戻せるようなバックアップ機能としても使える、バージョン管理ツールだ。フォルダをまるごとコピーして年月日を付けて管理するとか、USBメモリにいれておくとか、そういったバックアップ方法もあるだろうが、何より手間がかかるし、一人の管理者が担当しなければ、とたんにバージョンが破綻してしまう。
それをシステム的に防ぐことは重要だ。そのためにバージョン管理ツールが必要になる。
バージョン管理ツールというのは、例えばプロジェクトが、いつの間にか不具合が混入したまま進んでしまっていたりした場合、予め然るべき処理をしておけば、おそらく問題無いであろう履歴までさかのぼり、その状態と現在の状態を良い塩梅に合致させ、プロジェクトを破綻させること無く突き進む事ができるという、最高のツールでもある。
その中でもここ数年熱いのがGitだ。俺も使ってる。
Git以外使いたくない！と思わせるほどのツールだ。
開発者だけでなく、経理、総務、営業の人でもGitを使えば、アホみたいなファイル管理なんかしなくて済む。
そりゃDropbox使うよりは多少複雑だろうけど、編集、追加、コミットの３つさえ行っておけば、すぐにぶっ壊れるExcelファイルなんかを複数人数で扱っても大安心だ。ぜひお試しあれ。
■なんて読む！？
ところで読み方だけど、Gitと書いてギット、というのが一般的だ。ただし人によってはジットという人もいるようだけど、JIT（Just In Time）コンパイラという別のテクノロジーもあるので、できればギットと発音しようじゃないか。
■今までとどう違う！？
俺自身、SVNというバージョン管理をずっと使っていたんだけど、とにかく面倒くさいというか、こういう時にはこれができるYO！とあるくせに、実際にやるとコンフリクト（過去のファイル内容と現在のファイルの内容同士が衝突）が起き、いちいち手で直すなど頻発していた。ブランチという、プロジェクトを枝分かれさせる機能もあるんだけど、ブランチしたら戻さないといけない。もとの幹（トランク）にマージ（合併）させる必要があるが、とにかくこの時点でのコンフリクトが多い。
なので、ブランチはだんだん切らなくなってくる。単純に、ただのバージョン管理システムとしてではなく、バックアップツールとしてしか使わなくなる。
そして全フォルダ内に.svnという隠し属性のフォルダが作られてしまうので、SVN監視下からソースコードを抜く場合、エクスポートという作業が必要になる。そしてそれを理解してない人にsvnで管理させると、この.svnフォルダも含んだ状態でサーバにアップしてしまうとか、本当に勘弁して欲しい余計な消耗が生まれることになるんだよね。
svnは良いツールだけど、Gitにはかなわないでしょ。
Gitではむしろブランチを切りまくるのが主流だ。『だ』というか、そうらしい。
実際に俺も何度もブランチ切りまくってるが、本体である幹（Gitの場合はトランクではなくマスターブランチと言う。以後マスターと表記）にマージする際、コンフリクトがまず起きない。起きないというのは言いすぎかもしれないけど、本当にほっとんど起きない。そういうアーキテクチャで作られているんだと思う。つまりブランチを切りまくれる。
ブランチというとsvnユーザとしては『えぇ～面倒くさいなぁ』というイメージしかなかったんだけど、Gitでのブランチは『ちょっとスタバでアイスヴェンティチャイラテ買ってくるわ～500円だからワンコインでむしろ楽だべ！』的な、イージー感覚でサクサク行けるという、優れたテクノロジだと思ってる。
■その他のメリット
そしてコミット（バージョン管理システムに作業履歴を覚えてもらう作業）先も、自分専用（ローカルリポジトリ）とプロジェクト共通（リモートリポジトリ）の2箇所ある。そのため、ブランチ切った先でテストしたら大失敗したとしても、ローカルリポジトリであれば誰にも知られること無く、プロジェクトに何ら影響を与えずに、作業を消し去ることも可能だ。つまり個々のプログラマが、自分が試したいことを他人に影響せずにその場で（ローカルリポジトリならネットワーク環境はいらないから電車内でも開発可能）試すことができるという、本当によくできたツールに仕上がってる。ブランチでうまく行ったらマスターにマージすれば良い。
■じゃぁGitやろうぜ！
さて、そんなGitだけど、実はひとつの目的を果たすために、無数の方法があるんだ。そう、コマンドにオプションをつけることにより、毎回やってる作業を省略（自動で実行してくれるから自分はやらなくて良いという意味で）してくれたり、別の代名詞的キーワードを使ったりして、とにかく人それぞれやり方が違ったりしてるのが現状ではないだろうか。軽くGoogleで検索してみると、同じ目的のための、多くの別の手段が沢山ヒットすると思う。どれか一つに決めて、それを自己流にするのもいいとは思うんだけど、どうせなら、なぜそういうやり方をするのか、というところまで掘り下げて見たいとは思う。
基本的に『AをBしたらCになった！』だけ書いてある記事は、このブログのテーマでもあるけど『ノイズ記事』という扱いをしてるんだよ。そういった、『技術ブログとしてはただのノイズ』でしかない記事がかなり多い（俺の記事もたまに間違えてるし、偉そうなこと言えないけど）。
高飛車な言い方で恐縮だけど、個人的には、まるでTwitterへの投稿みたいに数行しかない記事を堂々と掲載するのは、検索するときに無駄な時間かけることになるので、ちょっと勘弁してほしいとは思ってるんだよね。悪いんだけどさ。
ま、検索するときに俺は『-はてな』ってキーワードを入れてるけどね。
もちろん俺のこのブログがノイズではないというわけじゃないんだけど、少なくとも『AをBしてCになったのはDだから！』までは、最低掘り下げたいとは思ってるんだ。
俺の備忘録としてのブログだけど、俺は俺自信がオープンソースだと思ってるので、役に立つ情報はみんなでシェアしようじゃんか、というのもある。
※コメント蘭を非表示にしてるので、俺と読者がコミュニケーションまるで取れないけどさ、そもそも消した理由は、教えて君が『できません！』とか書いてくるので、うざいから消した。それにブログにコメントっていらないって昔から思ってるんだよね。
閑話休題。
というわけで、まずはしっかり教科書通りにコマンドを進めてみようと思う。要するにおさらいだ。
ただ注意がある。
あくまで『おさらい』なので、進め方は教科書通りじゃないよ。というのも、実際に教科書通りにすすめてると内容が膨大になる。だから、実作業で使う順になるように順序はある程度入れ替えてみた。ブランチの説明の前にサブモジュールの説明をするのは、そういう意味ね。
それから作業はWindowsで行うことを前提としているよ。
Macな人はMac的に脳内で置き換えて読んでね。
ただ、基本的にGUIのメニューは使わず、コマンドラインで行うので、特にLinuxとかMacだと大きくかけ離れた作業になる、ということはないはず。
※Git覚えられない人は一度TortoiseGitを消すべき（最初はGit for Windowsだけで十分）
というわけで、次回から実際の作業に入ります。
みんなのために、そしてもちろん俺のためにも、頑張って書くよ。
よろしくどうぞ。
facebook
twitter
google+
fb share