【RPGゲームでたとえる】30分で理解するGit (初級編)

社会人1年目の機械系プログラマです。大学時代はロボコンをやっていました。そこで得た知見として、応用ができる人は基礎理解モデルが違うということです。（詳しくは以前書いたこちらの記事を見ていただきたいです。）基礎理解モデルが正しいと早く理解することができ、成長も早くなります。そして、基礎理解モデルは人によって異なるため、その人の経験に基づいた説明が必要です。本ブログではこれを読んでいるあなたに基礎理解モデルを作ることをポリシーに書いています。そして、今回は初学者プログラマーがつまずくGitの解説をします。一応RPGゲームをやったことがある人向けに書いています。評判がよかったら組織人向けも書いてみます。はじめに概要と疑問を簡潔に書き、あとから具体例を元に詳しい説明をしていきます。ちなみに基礎的な用語は知っている前提なので、Gitの用語を全く知らない方は他のサイトで調べてみてください。

GitとGithubの違い

よく、GitとGithubが一緒に解説されているので違いがわからなくて混乱する人もいると思いますが、両者は別物です。Gitはバージョン管理ツールで、GithubはGitの一部の機能を継承した、ソースコードの共同編集ができるサービスです。今回はGitを解説していきます。（Githubは別記事にて解説）

Gitとは何なのか

簡単に言うとファイル変更のバージョンを管理するツールです。Gitには3つの機能があり、それぞれ「変更の保存」「変更の分岐」「変更の確認」になります。ちなみにGit使えるようになると、過去の状態に戻したり、過去の状態と現在の状態の比較ができるようになります。バージョン管理と聞くと馴染みがないように感じますが、これをRPGゲームで喩えると簡単に理解できるようになります。

ファイル管理地獄から見るGitの必要性

まずはGitはなぜ必要なのかを考えてみましょう。あなたは新しいプログラムの行を追加した後に何をしますか？上書き保存をしますよね？しかし、書いている途中でバグが出てきたらどうしましょうか。そのときに「バグが出てなかった頃に戻したいが上書き保存してしまったから容易にできない。」ともどかしい思いをすることになります。それなら、「保存するたびにファイルを別にすればいいじゃない」と思うかもしれませんが、それだとファイルの数が膨大になってしまいます。この管理の苦労はGitを使うことによって解決することができるのです。

Gitの概要をゲームを例に説明する

Gitの大きな利用目的が2つあります。それは変更をもとに戻すと変更の比較です。"もとに戻す"をゲームで喩えるとセーブの場面になります。ゲームの場合には勇者の剣を手に入れた状態でセーブを行うと、勇者の剣を手に入れる前の状態に戻すことはできませんが、Gitでバージョン管理をすると勇者の剣を手に入れる前の状態に戻すことができます。

変更の比較を喩えると、セーブする前とセーブしたあとで何が違うのかを簡単に確認することができる機能です。ゲームは違いを自分で覚えておく必要がありますが、Gitでは変更の履歴を保存しておけるため、異なるセーブ間の違いをハイライトで確認できます。

以降は2つの目的を叶えるためにGitに備わっている機能を紹介していきます。

コミット

これは「変更の保存」にあたる、Gitの最も基本となる操作です。まずはこれを理解しましょう。

「コミット＝変更をセーブする」です。コミットをすることで変更を保存することができます。Gitの場合はゲームと違い、そのままコミットしても最新状態だけが残るのではなく、コミットするごとに別のバージョンとして保存されます。つまり、1つのファイルで保存しているのに新しい別ファイルでセーブしたのと同じような管理状態になります。

コミットをする際にはコメントを追加する必要があります。コメントを追加することで、あとから見た際に何を変更したバージョンなのかがひと目見てわかります。コメントの注意点としては、「関数Aを追加」のようにその時書いた人しかわからない書き方をしてはいけません。なぜなら時間が経ってから見るとその関数の仕様を忘れてしまっているため、変更内容がわからなくなるからです。「魔王の城　魔王撃破」のように今進んでいる作業が何なのかを第三者が見てわかるように端的に表したコメントにしましょう。具体的には、「×ボタン長押しでダッシュする機能を追加」「スキルが使えなくなるバグを修正」のように変更を簡潔に書きます。

ステージング

実はコミットをする前に一手間加える必要があります。その作業がステージングです。（「git add」コマンドで表される操作です。）

「ステージング＝セーブデータしたい場面を選択すること」です。バージョン管理するためには、管理したいファイルをステージングすることで追加します。

ビデオゲームで進行状況を保存したいときは、セーブしたい場面になったタイミングでセーブファイルを作成し、セーブの管理画面を開いて上書き保存するか新しくデータを作るか選びます。ゲームでよくあるこの状態はすべての変更をステージングした状態です。これに対し、Gitのステージングでは保存したい変更のあるファイルを選択することができます。

コミットするタイミング

コミットのタイミングは、プログラムの小機能単位ごとやデバッグの修正が終わったタイミングになります。プログラムの少機能単位ごとにコミットすることで、ある時点の機能に少し違う機能を足した様々なバリエーションのプログラムを簡単に作ることができます。また、万が一バグがでて収集がつかなくなったときは、確実にバグがなかったバージョンと比較してデバッグに活かしたり、そのバージョンに戻して書き直したりできます。これによって開発効率が大幅に上がります。

ブランチとは何なのか

「変更の分岐」にあたる機能です。ブランチには様々な利用方法がありますが、ここでは主な使い方を2つ紹介します。1つめは、新たなプログラムを作るときにある時点のプログラムを利用したいとき。2つめは、デバッグの際に元のソースコードを残したいときです。

ブランチの利用法1　ある時点のプログラムを再利用したいとき

RPGゲームでルート分岐の直前で新しいセーブデータを作ってセーブをすることはよくあると思います。それは一体なぜでしょうか。そう、もしそのルートがだめだった場合に他のルートも見るためですね。これと一緒で、プログラムを作る際にもそれぞれのルート(大機能)ごとに変更を保存しておきたいという需要があります。どうしてそのような需要があるかと言うと、プログラムの規模が大きくなると、「過去のあの時点の状態のソースコードを分岐させてプログラムを作りたい」という場面がでてくるからです。何らかのプログラムを作るときに、過去のある状態に少し追加するだけで完成するという場面は多くあります。そのようなときに、ある時点のバージョンからブランチを作って分岐させ、そのブランチで別の機能を追加してコミットします。そうすることで元の変更は残したまま、自分でコピー＆ペーストする手間なく簡単に少し違うバージョンを作ることができます。

RPGゲームを作るときを考えてみましょう。それぞれのルートのプログラムを作りたいときに別のブランチで作成しておくと、それぞれのルートのプログラムが干渉せずに分離してデバッグができるので非常に開発がはかどります。注意しなくてはいけないことが、小機能単位でブランチを作らないことです。ブランチは増えすぎても管理が大変になるので大きな機能を追加したい場合に利用することを心がけましょう。

ブランチの利用法2　デバッグ時のブランチ分け

あなたはとあるスマートフォンゲームを作成、管理しているプログラマーです。案の定リリースしたらユーザからバグの報告がありました。直ちにバグの修正をしようとしますが、そのまま書くと"元のファイルを変更してしまう"ことになるので元の状態のものをそのまま残しておきたいです。また、バグの修正をするために試行錯誤したいので、それ用の同じプログラムがもう一つほしいですね。さてどうすればいいでしょうか？そんなときにデバッグ用のブランチを作成し、そちらで作業します。すると元のブランチはそのままの状態で残ります。そして、バグが修正し終わったらブランチを合流させて修正済みのデータにすることができます。このようにすることで、作業中も元のソースコードをそのまま利用し続けることができます。これがスマホアプリで言う"アップデート"にあたります。

まとめ

Gitの基礎となるステージング、コミット、ブランチを解説しました。これだけ覚えれば解説を聞くときも入ってきやすくなると思います。Gitの機能はまだまだあり、他にも変更を確認したりブランチを付け替えたりする機能やGithubとの連携などがあります。それは続きの記事で解説していきます。この記事が役に立ったという人はスキを押してもらえると今後のモチベーションアップにつながるのでよろしくおねがいします。

参考

https://kray.jp/blog/expound-git-add/