こんにちは！
駆け出しエンジニアのまるです👓️🦍
これまでプログラミング言語や、エディタの使い方、コードの書き方などを解説してきましたが、今回は僕が現場に出て最初につまづいた「Git」について解説していこうと思います！
僕もはじめ、上司に教わりながら操作はしてみたものの、仕組みが腹落ちするまでにはかなり時間がかかりました。
正直、今でも「Gitを全部完璧に理解しています！」と言い切れるわけではありません。
ただ、ひとつだけハッキリ言えるのは
「こうやればいいよ」と手順だけ教わっても、仕組みが分からないと「何をしているのかが見えなくてめちゃくちゃ怖い」ということです。
僕も最初は恐る恐る操作していましたし、実際に失敗もたくさんしてきました。
だからこそこの記事では、これからGitを使っていく方に向けて、まずは全体の仕組みをスッキリ理解できるように、初心者目線でやさしく解説していきます！
まずは Gitとは何か から触れていきますね！
Gitとは何か？
Gitは一言でいうと「バージョン管理ツール（変更履歴を管理する仕組み）」です。
僕も最初に調べたときは「？？？」でした（笑）
ざっくりイメージすると、Gitはゲームのセーブに近いです。
ただし、普通のゲームのセーブと大きく違うのは
「過去のセーブ地点に戻って、そこから別のルートでやり直せる」ところ。
Gitでは、作業の区切りごとに”セーブポイント”を作れます
このセーブポイントのことを、Gitではコミット（commit）と呼びます。
（※この記事では「Gitのセーブ＝コミット」と思って大丈夫です！）
Gitの利点
「過去に戻れると何がいいの？」って思いませんか？
俺は現在（いま）を生きてるんだ！と中二病全開の僕は思いました（笑）
それはさておき、「過去に戻れる」ということは現場でコードを書いていると、めちゃくちゃ役に立ちます。
たとえば、ホームページ開発をしていて、自分の担当画面を「画面A」とします。
どんな画面でもそうなんですが、実はそれ単体で完結することはなく、
- 画面Aそのもの（HTML/CSS）
- 画面Aを表示するための処理（ルーティング・コントローラーなど）
- 画面Bへつながるボタンの処理
・・・みたいに、小さな部品の組み合わせでできていることが多いんです。
この「小さな部品」を１つ作るたびにコミットしておくと、後で困ったときに強い。
- 不具合が出たときに「どこから壊れたか」を切り分けやすい
- 「ここ直して」と言われたときに、関係する部分の履歴を追いやすい
- 後から見返したときに「何の作業をしたコミットか」が分かりやすい
（コミットメッセージには＝名前をつけられます）
僕がやらかした話（まとめてコミットの罠）
ここで僕は一度、失敗しました…
僕はもともと「こまめにセーブするタイプ」じゃなかったので、仕事でも1日の終わりにまとめてコミットしていたんです（笑）
でもこれだと、
- 1日で何をやったのかコミットから見えづらい
- どの作業で不具合が混ざったのか切り分けづらい
→結果、修正が遅くなる
・・・ということが起きます。
取り返しがつかない失敗になるわけではないんですが、
仕事の効率は確実に落ちる ので、「こまめにコミット」をクセにするのがおすすめです！
まとめ：まず覚えるのは「コミット＝セーブ」
最後に、Gitとは何だということを、もう一度イメージでまとめます！
（まずはGitの機能を全部覚える必要はないので、最初のこの1つだけ覚えておきましょう）
Gitとは、作業の区切りごとに「セーブ（コミット）」を作っておいて、あとから好きな地点に戻れる仕組みです。
たとえば、ゲームで
【モンスターAにスキルAを覚えさせた】というセーブを作っていたとします。
※ここでいうセーブは、ファイル保存（Ctrl+S）ではなくGitのコミット（commit）のことです。
あとで「やっぱりスキルBのほうがよかったな〜！」と思ったら、
その”スキルAを覚えさせた時点まで戻って、そこからスキルBに変更して、あらためて新しいセーブを作る
これがGitでできることのイメージのひとつです！
※戻っても履歴が消えるわけではなく、必要なら別の道としてやり直せます。
言葉だけだと想像しづらいと思うので、図で見てみましょう👇️
どうです！？こう考えると、Gitってめちゃくちゃ便利じゃないですか！？
少しずつGitの全体像が見えてきたところで、次の記事ではGitのブランチについて解説していきます！
コメント