見出し画像

git を丁寧に伝える - git 伝承者への道 - 第1回 ~Git とはなんぞや編~

はじめに

第1回の今回は、Git のイメージを描いてもらいたいので、git を使っていない架空の現場を紹介します。


いきなり結論

Git とは…

Git は VCS のひとつです(`・ω・´)キリッ

いや、え?って感じだと思うんで、まず VSC について簡単に。

VSC とは…

VCS とは、
バージョン管理システム(Version Control System)
のことです。

なんて言われましても…
だと思うんですが、"バージョンを管理するために使うもの"くらいのイメージはできたと思うんで、今はそれで充分です。安心してください。ちゃんと説明します。


Git は分散 VCS

VCS のひとつである git の特徴は分散 VCS であること。

( ゚д゚)
(つд⊂)ゴシゴシ
(;゚д゚)
(つд⊂)ゴシゴシ
(;゚ Д゚) …?!

となったそこのあなた。そう、あなたです。
大丈夫。安心してください。
できるだけゆっくり、できるだけ丁寧に説明します。
だから今はわからなくても全然 OK です。


VCS の無い世界

ここまでを読んで (´・ω・`)ショボーン となりましたよね?
ここで嫌になるのはもったいないので、その「ワケノワカラナイコト」をこれから丁寧に説明していきます。

まず VCS をイメージしてもらいたいので、VCS を使ってないとどうなっちゃうのかを見てみましょう。

導入

僕は吹けば飛ぶような小さな小さな会社で開発エンジニアとして働いています。
発注元がわからないくらいの下請けだから、案件はいつも小さな小さな小さな小さなプロジェクト。少人数です。
少人数すぎて git のコストが高くなることを理由に NAS の共有フォルダでソース管理をしています。マジかよ。

ある日

さぁ!今日も元気に出勤です。
さぁ!今日も元気に作業開始です!
今日も元気だ!煙草が不味い!

僕が帰ってからの変更を僕のローカル環境に反映するところから作業します。全ソースを NAS の共有ディレクトリから PC の作業ディレクトリに上書きコピーして

  • 上位会社が書いたドキュメントを読んで

  • ドキュメントに沿うロジックをソースに実現して

  • がーっとビルドして

  • ちまちまと動作を確認する

この繰り返し。

うわぁ… IT エンジニア、つまんなそう…

と思ったあなた。
これがですね、思った通りに動いた瞬間とかが楽しいんですよ。

おっと…そうこうしていたらもう定時です。
ここまでの成果物を丸ごと NAS の共有ディレクトリに上書きコピーして作業終了です。
充実感を味わいながら帰宅後に遊ぶ Last Oasis について思案しながら帰宅です。

翌日

さぁ!今日も元気に出勤です。
さぁ!今日も元気に作業開始です!
今日も元気だ!煙草が不味い!

出勤したらなんか騒いでいます。
冷蔵庫のプリンを誰かが勝手に食べたとかと思ったら、そうじゃないらしい。うん、プリン食べられたくないなら、せめて名前くらいは書いておいてほしい。

ともかく、なんかわかんないけど動かなくなったとか言ってて、上位会社からクレームとのこと。

うわぁぁぁ…

自分より上位の存在からのクレームに心臓がバックバクになりながら全員で調査します。
なんかわかんないけど動かなくなってたなんてソース。調べても原因なんかわかるわけもなく。それでも全員で強力して、愛と勇気と希望のチカラで原因を見つけ出しました。

原因は、僕が昨日編集したファイルでした。(てへぺろ

他メンバーもそのファイルを編集していたことを知らずに、豪快に上書きで成果物を反映したことで動作不良が発生したことがわかりました。もう見てらんない。
全員で各々の PC にあるファイルをベースにチマチマと修復と変更箇所の統合を行いました。
でも対象ファイル数が多く、その作業は深夜にまで及びます。涙が出ちゃう。だって IT エンジニアだもん。
夜が明けようと空が鈍く輝き始めた頃、ようやくシステムをテストできる状態になりました。長い夜が明けました。


問題点は何か?

このような出来事は、共有フォルダーで成果物を管理する限り規模の大小はあれど、ほぼ確実に発生します。
その原因を考えてみましょう。

1.作業対象ファイルの取得

共有フォルダーから対象ファイルを取得する際の問題を見てみると…

(1) それって本当に最新なの?
共有フォルダーでは、他の開発メンバーも常に変更が可能。
つまり、「最新」と思っているものが実は「最新ではない」という可能性が否定できないわけです。

(2) 特定のバージョンを取得できない
共有フォルダーでは、常に「最後に変更されたもの」を管理しています。
なので、一昨日変更したファイルに戻したいとか、あの人が改修したものだけ取り込みたいみたいなケースには対応できません。
※日付フォルダを使って管理する。人名フォルダを使って管理する。みたいな手間をかければ出来なくはないです。

2.ファイルの編集

ファイルを編集する際の問題点を見てみると…

(1) どのファイルを変更したのかわかりにくい
変更したファイルを簡単に特定する方法が無いです。
なので、変更後、共有フォルダーへの反映時に、変更したファイルで更新する作業が漏れる可能性があります。

(2) 元に戻せない
失敗や変更のやり直し、試行錯誤段階など、変更を無かったことにしたいケースが開発の中ではよくあります。

しかし、共有フォルダーからコピーするやり方では、再度コピーする以外の方法がありません。
※厳密には、日付フォルダで都度管理するとか、ファイル末尾に日付を加えるなどで、管理できなくもないですが、実に面倒で。

(3) 作業対象の「バージョン」が一定しない
元に戻す(変更をなかったことにしたいとか)際、共有フォルダーから再度コピーすると、最初にコピーした時点と、作業対象のファイルのバージョンが変わってしまいます。
(この作業対象のファイルの「バージョン」を、作業ベースと呼びます。これは豆。)

3.作業結果の反映

作業結果を共有フォルダーに反映するときにも落とし穴が…

(1) 他の人が同時に変更している可能性
自分が編集したファイルを他の人が同時に変更している可能性が常にあります。
この時、ファイルサーバの共有フォルダでの管理では、必ず「後勝ち」となるため、先に共有フォルダーにアップした人の変更が失われます。

(2) 誤操作で削除する可能性
共有フォルダーは、誤操作で(或いは意図的に)スナック感覚でファイルを消すことができます。

(3) 環境を壊す可能性
開発中の成果物が中途半端な状態になることで、簡単に環境が壊れてしまい、テストが不可能になったり、開発の意図がわからなかったりします。

では、どうするか?

これらの問題は、人間は間違う生き物なので「気を付ける」レベルで対処できません。気を付けるという程度や頻度はその人の精度によって異なります。

そこで登場するのが VCS です。

人間が間違えやすいところをツールにサポートさせることにすると、開発を円滑に進めることができます。
その中のひとつである 分散型 VCS は、みんなが手元にそれぞれ基ファイルのコピーとかを持っているということになるのです。

ここまでみてきた手法では「みんなが触るフォルダ」がひとつあって、個々人は「みんながさわるフォルダ」に対して作業コピーの内容を反映させたりしていました。
あるいは、日付や人名のフォルダを作って管理するという、くっそ煩雑な対応が必要でした。

でも、Git の場合は、そういう「みんながたったひとつのフォルダを触る」感じではなくて、それぞれが手元に「みんなが触るフォルダのコピー」を持ちます。
作業コピーに対して行った変更を、「分散してるフォルダ」(= 手元のフォルダ)に対して反映させるので、「分散させたバージョン管理」(VCS)となります。

ここで、ひとつの疑問があります。

「大勢で編集する」のに便利な VCS なのに、それぞれが自分のフォルダに対して変更を反映するだけでは、意味が無い。ということです。
つまり、自分が行った変更を誰かと共有したり、だれかが行った変更を自分のところに取り込んだり…

それができなければ、 VCS の嬉しさは半減です。埼玉県民なら誰でも知っていると言っても過言ではない 餃子の満州 みたいに、「三割美味い!」とか言っているってことは、残りの7割は不味いのかよ!みたいな感じになってしまいます。

そこで、Git には

このリポジトリにある変更を、そっちのリポジトリに反映してくれない?
そのリポジトリの変更、こっちのリポジトリに取り込ませてよ。

みたいなノリで、リポジトリ同士で変更内容を取り込んだりする機能があります。
これによって、複数のメンバーで同じコードを触ることができるようになるわけです。もちろん、このときに競合が起こったりした場合は

あー競合しちゃっているからそれ取り込めないわ、ちょっと手元で直してから取り込んでもらっていいかい?

みたいな感じで Git が教えてくれます。

現時点では具体的なことがわからなくても、「そんなイメージなんだな」くらいに思っていただければ幸いです。

補足

今後、"Git" と書いたり "git" と書いたりと表記の揺らぎがあると思いますが、どちらも同じ意味です。他の英文字も同じです。キャメルケースやスネークケースで書くこともあります。気分とか何も考えてないだけで表記上の違いだけです。


支援のお願い

本記事は無料でお読みいただけますが、投げ銭形式にしているので、気に入ったらご購入いただけると嬉しいです。
また、下記リンクのご支援をいただけると励みになります。


素材引用元

アイコン

見出し


この記事が気に入ったらサポートをしてみませんか?