あら？どうしたのケンタくん。顔色悪いわよ？

あー、あるある。shooting.hsp、shooting_tama.hsp、shooting_tama_atari.hsp、shooting_tama_atari_sound.hsp、shooting_ugoku_yatsu.hsp…って感じでファイルが増えていくやつね（笑）

それなら、GitHubを使ってみたらどう？

そう。Gitっていうのは、簡単に言うとファイルの履歴を管理してくれるツールなの。GitHubは、そのGitをネット上で使えるようにしたサービスよ

例えば、ゲームのセーブデータって、「セーブ1」「セーブ2」「セーブ3」って複数保存できるでしょ？Gitはそれをプログラムでやってくれるの。「この時点のコード」「あの時点のコード」って、全部記録しておけるのよ

その通り！しかも、「いつ」「誰が」「何を」「なぜ」変更したかも全部記録できるの。メモも残せるから、後で見返したときに「あれ、なんでこうしたんだっけ？」ってならないのよ

あはは、安心して。それは「パブリック（公開）リポジトリ」の場合ね。GitHubには「プライベート（非公開）リポジトリ」っていう機能があるの

うん。プライベートにしておけば、自分だけ、もしくは許可した人だけが見られるようになるの。だから、個人の勉強用とか、会社の秘密のプロジェクトとかも安心して使えるのよ

そうそう。むしろ、ぐちゃぐちゃなコードだからこそ、Gitで整理していくのがおすすめよ。後で「あの時はこんなコード書いてたんだ」って成長が実感できるから

じゃあ、GitHubで具体的に何ができるか説明するわね

まず一番大事なのが「タイムマシン機能」。さっき言ったように、過去のどの時点にも戻れるの

そうそう。例えば、「昨日の夜までは動いてたのに、今日いじったら動かなくなった」って時、昨日の状態に簡単に戻せるのよ

それから、「ブランチ」っていう機能もあるの。これは、元のコードはそのままにして、別の場所で新機能を試せるの

うん。例えば、「今動いてるゲーム」はそのままにして、「新しい敵キャラを追加してみる実験」を別のブランチでやるの。うまくいったら元に合流させて、失敗したら捨てればいい

あと、すごく便利なのが「複数のパソコンで同じプロジェクトを扱える」ってことね

そう。例えば、家のデスクトップPCと、持ち運び用のノートPCでプログラミングするとするでしょ？

だったら、GitHubは最高よ！家でコミット＆プッシュしておけば、学校のPCでプルするだけで、続きから作業できるの

簡単よ。USBメモリでファイルを持ち運ぶ必要もないし、「あれ、最新版どっちだっけ？」って悩むこともないの

あるある（笑）。GitHubを使えば、そういう悲劇とはおさらばよ

確かに、Gitのコマンドは最初はちょっと戸惑うかもね。でも大丈夫！

うん。実は、GitHubには「GitHub Desktop」っていうアプリがあるの。これを使えば、マウスでポチポチするだけでGitが使えるのよ

打たなくていいの（笑）。ボタンを押すだけで保存できるし、履歴も見やすいし、初心者にはすごくおすすめよ

それに、慣れてきたらコマンドも覚えていけばいいから。最初はアプリで感覚をつかむのが一番よ

あ、そうだ。GitHubを使う前に、一つ大事な準備があるの

HSPのエディタ、普段は「hsed3.exe」を使ってるでしょ？

GitHubで使うなら、「hsed3u8.exe」に変えた方がいいわ。これはUTF-8版のエディタなの

文字コードの違いね。標準版はShift-JISっていう古い形式なんだけど、GitHubはUTF-8が標準なの

GitHubで「どこを変更したか」を見る画面があるんだけど、文字コードが違うと文字化けして、まともに比較できなくなっちゃうのよ

だから、最初からUTF-8版を使っておけば安心ってこと。使い方は標準版とほとんど同じだから、心配いらないわ

じゃあ、実際の使い方を簡単に説明するわね

まず、GitHubのサイトでアカウントを作るの。メールアドレスがあれば無料で作れるわ

全然！メールアドレスとパスワード、ユーザー名を決めるだけで、1分もかからないわよ

それに、実はGitHubは2018年にMicrosoftに買収されて、今はMicrosoft傘下なの

そう！だから、すごく安心して使えるのよ。世界最大のソフトウェア企業がバックにいるから、サービスが突然終了する心配もないしね

大手企業も、中小企業もお金を払ってPrivateリポジトリで自社サービスを開発しているわよ。あ、でも個人向けはPrivateが無料だから安心して使ってね！

次に、「リポジトリ」っていうのを作るの。これは、プロジェクト専用の保存場所みたいなものね

そうそう、その理解で大丈夫！「シューティングゲーム用」「RPG用」って分けて作るイメージね

そしたら、GitHub Desktopでそのリポジトリを「クローン」するの。これは、ネット上のリポジトリを自分のPCにコピーすることよ

その通り！で、普段通りプログラムを書いて、キリのいいところで「コミット」するの

セーブのことよ。「ここまでの変更を記録する」って操作ね。その時に「敵キャラのスピードを調整」とかメモを残すの

いい例え！最後に「プッシュ」して、変更をネット上のGitHubに送れば完了よ

じゃあ、実際にケンタくんのシューティングゲームをGitHubで管理してみましょうか

まず、GitHubにログインして、右上の「+」ボタンから「New repository」を選ぶの

リポジトリの名前は「shooting-game」とかでいいわね。下の方に「Private」ってチェックボックスがあるから、それにチェックを入れて

「Create repository」ボタンを押したら、リポジトリの完成よ

いい感覚ね（笑）。次に、GitHub Desktopを開いて、「Clone a repository」を選んで、今作ったリポジトリを選ぶの

ドキュメントフォルダとか、わかりやすい場所でいいわよ

じゃあ、Show in Explorerをクリックして、エクスプローラーでそのフォルダに、今まで作ってたHSPファイルをコピーしてみて

GitHub Desktopを見てみて。左側に変更されたファイルが表示されてるはずよ

もしここでhsed3.exe（標準）を使っていると、右の差分表示が文字化けして読めないことになっているわ。注意してね

変なファイル？どんなの？

あー！それはHSPが自動で作る一時ファイルね。実行したりコンパイルすると勝手にできるやつ

ダメダメ！これをコミットすると、実行するたびに『ファイルが変更された』って表示されて、めちゃくちゃ混乱するわよ

こういう『管理しなくていいファイル』を指定するために、「.gitignore（ギットイグノア）」っていうファイルを作るの

うん。『ignore（無視する）』って意味ね。このファイルに書いたものは、Gitが無視してくれるのよ

一つ一つ手作業で除外することも出来るけど

(Ignore file (add to .gitignore)を選ぶ)
ここではHSP特有の.gitignoreを教えるわ

それは「コメント」ね。メモみたいなもので、Gitは無視するわ。自分が後で見返すときのために書いておくの。HSPで言うなれば、 ; コメント、あるいは // コメントよ

あと、「*.exe」は『すべてのexeファイル』って意味。「*」はワイルドカードって言って、『何でもいい』って意味なの

じゃあ、初めてのコミットをしてみましょう。左下の「Summary」っていう欄に、メモを書くの

最初だから「初回コミット」とか「プロジェクト開始」とかでいいわよ。英語で「Initial commit」って書く人も多いわね

いいわね！気持ちがこもってる（笑）。じゃあ、青い「Commit to main」ボタンを押してみて

正解！コミット（保存）されたから、変更済みファイルのリストから消えたのよ

最後に、上の「Push origin」……初回だからPublish branchボタンを押して、GitHubに送るの

そう！GitHubのサイトに戻って、リポジトリを見てみて

これからは、プログラムを書いたら、こまめにコミットする習慣をつけるといいわよ

そうね、「敵キャラを追加した」「弾の速度を調整した」「BGMを追加した」みたいに、一つの機能ができたらコミットする感じかな

そう。あんまり細かすぎても大変だけど、「今日やったこと全部まとめて」だと、後で探しにくくなるからね

それと、コミットメッセージ（さっきのメモ）は、後で自分が見てわかるように書くのがコツよ。「修正」だけじゃなくて、「敵の当たり判定を修正」って書いた方が、後で探しやすいわ

いいわね！流れは簡単よ

そう、まったく同じ（笑）。重要なのは「作業前に必ずプル」ってこと。これを忘れると、古いバージョンで作業しちゃうから

そしたら、Gitが「コンフリクトしてるよ」って教えてくれるの

大丈夫、落ち着いて。この場合は、各ファイルをエディターで修正するか、”Use the modified file from main”、つまり手元のファイルを使うか、”Use the modified file from origin/main”、つまりGitHubのファイルを使うかを選べるわ。

その気持ち、大事よ。だから、「プッシュ忘れない」「プルを習慣にする」を徹底すれば大丈夫！

逆にGitHubが超便利なのよ！作業が終わったらプッシュしておけば、PCのデータが消えても、GitHubには残ってるから

その通り！むしろ、そういう環境でこそGitHubの真価が発揮されるわ

いい質問ね！「戻る」には2つのパターンがあるのよ

例えば、新しい敵キャラを追加してみたけど、全然うまくいかなくて、コードがぐちゃぐちゃになっちゃった、みたいな状況

そういう時こそ、Gitの出番！変更したファイルを右クリックして、「Discard changes…（変更を破棄）」を選ぶの

前回コミットした時の状態に、一瞬で戻るの！まさにセーブポイントに戻るゲームみたいでしょ？

そう！だから、思い切って実験できるのよ。失敗しても「Discard changes」で戻せばいいだけだから

次は、コミットした後で「やっぱりダメだった」ってパターンね

戻せるわよ。GitHub Desktopの「History」タブで、戻りたいコミットを右クリックして、「Revert changes in commit」を選ぶの

「打ち消す」って意味ね。例えば、「敵キャラを追加」ってコミットをRevertすると、「敵キャラを削除」っていう新しいコミットが作られるの。履歴は残るけど、内容は元に戻るわ

9割は「Discard changes」を使うことになるわ。だから、まずはこっちを覚えておけば大丈夫！

慣れてきたら、「ブランチ」も使ってみるといいわよ

そう！例えば、「ボスキャラを追加したいけど、うまくいくかわからない」って時、新しいブランチを作るの

GitHub Desktopの上の方に「Current branch」ってあるでしょ？そこをクリックして「New branch」を選ぶの。

名前は「boss-character」とかでいいわね

これで、今から書くコードは「boss-character」ブランチに記録されるの。元の「main」ブランチには影響しないわ

そう。うまくいったら「main」に合流（マージ）させて、失敗したらブランチを削除すればいいの

いい質問ね！確かに、Revertでも「やり直す」ことはできるのよ。でも、ブランチとRevertでは考え方が全然違うの

Revertはね、「あの変更は間違いだった」ってことにして、逆の変更を記録するの。つまり、「敵キャラを追加した」を「敵キャラを削除した」に打ち消すのよ

そう！でも、もし「敵キャラ追加」が1日かけた大きな実験だったら、どう？

ブランチなら、最初から「敵キャラ実験用ブランチ」を作って、そこで1日かけて試行錯誤するわけよ。途中の細かいコミットも全部残る

そう。「敵キャラの色を変えてみた」「当たり判定を調整した」「ボス敵にしてみた」…こういう全部のコミットが記録されるの。そのブランチ内では履歴が完全に保存されるわ

で、「やっぱりうまくいかないな」ってなったら、そのブランチ全体を削除しちゃう。mainブランチは触られない。きれいなままよ

その通り！それにね、「敵キャラ実験」と「BGM追加実験」を同時にやりたくなったら、ブランチなら簡単よ。別々のブランチで同時進行できるのよ

Revertだと、「敵キャラ追加」を打ち消した後に「BGM追加」をやるから、実験が直列になっちゃう。遅いのよ

その通り！だからね、「大きな実験」「新機能の追加」「いろんなことを試したい」って時は、ブランチを使う。それに対して、Revertは「あ、もう遠くになった1個のコミットで小さなミスがあった」みたいな時に使うイメージね

いい理解よ！使い分けをまとめるとこんな感じね

いい質問ね！実はもっといい方法があるの。「Pull Request」っていう機能を使うのよ

「この変更をmainブランチに取り込んでください」っていうお願いを出す機能なの

そう見えるけど（笑）、実はこれ、一人プロジェクトでもすごく便利なのよ！　まずはboss-battleブランチをPublishしましょう！

GitHubに行くと、Compare & Pull Requestという画面が出ているわね。

このPull Requestを使うと、変更内容を「レビュー画面」で見られるの。何を追加して、何を削除したか、一目でわかるのよ

クリックするとこんな画面よ。

下に行くと変更内容が色分けで表示されるの。赤が削除、緑が追加ね

ここで、自分のコードをじっくり見直すの。「このコメント、わかりにくいな」とか「この変数名、もっといい名前にしよう」とか気づくことが多いのよ

まさに！問題なければ、後で読み返してもわかるように内容を書いて
「Create pull request」ボタンを押せば、晴れてPull Requestが出来るわ。出来たPRは

このように見れて、必要ならもう一回File changedでどんな変更を加えたかを見ることも出来るわ。最後は下にスクロールしてMerge pull requestよ！

あー、それはGemini Code Assistね

GoogleのAIがコードを自動でレビューしてくれる機能よ。Pull Requestを作ると、勝手にコードを見て「ここ、こうした方がいいんじゃない？」って提案してくれるの

そう！例えば、「この数字、マジックナンバーだから定数にした方がいいよ」とか、具体的にアドバイスしてくれるのよ

でしょ？一人プロジェクトでも、AIがペアプログラミングの相手になってくれる感じね

GitHubのMarketplaceから「Gemini Code Assist」をインストールするだけよ。無料で使えるわ

必要だったからね。ただし、AIの提案が常に正しいとは限らないし、問題の全てを指摘してくれることもないから、「なるほど、こういう考え方もあるんだ」くらいの気持ちで参考にするのがいいわね

ちなみに、Pull Requestをマージしたら、そのブランチは削除していいわよ

大丈夫。マージ済みのブランチは、もう役目を終えたから。GitHubが「Delete branch」ボタンも用意してくれてるわ

大丈夫、GitHubは利用者が多いから、ネットに情報がたくさんあるわよ

うん。「GitHub 使い方」とか「Git 初心者」とか検索すれば、優しい記事がいっぱい出てくるわ。GitHub公式のドキュメントも日本語対応してるし

最初は戸惑うこともあるかもしれないけど、使ってるうちに絶対慣れるから。焦らずゆっくりいきましょ

ケンタくん、その後GitHubは使ってる？

おお、いい感じじゃない（笑）

でしょ？それがGitの醍醐味よ

すごくいい使い方してるわね！

どういたしまして。これからも、どんどん新しいことに挑戦していってね