はじめに
なぜGitが必要なのか？
- 誤ってコードを消しても元に戻せる
- 過去の変更履歴がすべて残る
- 機能ごとに枝分かれして作業できる（ブランチ）
- オンラインにアップすればバックアップ＆チーム共有も可能
開発を継続するほど、Gitのありがたさが身にしみてきます。
環境
- OS：Windows 10/11
- エディタ：VSCode（もしくはターミナル）
- ローカルリポジトリ：C:\Users\user-name\game-project
- GitHub（任意）：リモートバックアップ先として使用（無料）
Git環境構築（おさらい）
１回目の際に、Gitの初期化及び、Githubでリポジトリの作成方法を解説しています。
【AI × 個人開発】ゼロから始めるアプリ制作 #01：仕様書から始める！個人アプリ開発の準備
アプリ開発を始めたいけど何から手を付けていいかわからない？この記事では、AI×個人開発でゲーム制作を目指す筆者が、仕様書の作り方からGitHubリポジトリ運用、README設計まで「実用的な準備」を丁寧に解説します。
https://humanxai.info/posts/app-dev-production-01/もしまだの場合は以下を実行する事で、初期化できます。
① Gitの初期化
プロジェクトフォルダに移動して、以下のコマンドを実行します。
cd C:\Users\(user-name)\game-project
git init
すると .git という隠しフォルダが生成され、Git管理が開始されます。
② 変更を記録する基本の流れ
git add .
git commit -m "初回コミット"
git add：追跡対象に追加（全ファイルは .） git commit -m “コメント”：スナップショットを保存
③ 履歴の確認と復元
git log --oneline
以前の状態に戻したい場合：
git reset --hard <コミットID>
④ GitHubとの連携（オンラインバックアップ）
- GitHubでリポジトリ作成
GitHubにログインして「New Repository」から新規作成。
- リモート接続を登録
git remote add origin https://github.com/ユーザー名/matching-game.git
- 初回のみpush
git branch -M main
git push -u origin main
※ 二回目以降の更新は以下だけでOK：
git add .
git commit -m "更新内容"
git push
⑤ よくあるトラブルと対処
| トラブル内容 | 解決策 |
|---|---|
| 誤って変更したファイルを元に戻したい | git checkout -- ファイル名 |
| 変更を取り消したい | git reset --hard |
| Gitが無視しているファイルがある | .gitignore を確認 |
よく使うコマンド
gitで個人開発をする際に、日常的によく使うコマンドは「add」「commit」「push」になると思います。
commitで更新内容を書くのは最初は面倒でしたが、慣れてくるとコピペでもいいので、
- 「どの記事を追加したか」
- 「どの記事を修正したか」
だけでも、書いておくと後で見た時に分かりやすいです。
兎に角、最初は取っつきにくいと思うので、無理せず同じコミット内容でもいいのでコマンドを叩いて慣れる事が重要だと思います。
.gitignoreとは？
Gitに「このファイルは追跡しないでね」と伝える設定ファイルです。
Gitでは、プロジェクトの中にあるファイルを全部まとめて管理できますが、 一部のファイルは管理したくない場合があります。
たとえば：
| ファイルの種類 | 理由例 |
|---|---|
| 自動生成されるファイル（例：ログ、キャッシュ） | 変更が多く意味がない |
| 個人設定ファイル（例：VSCodeの設定） | 他の人には不要 |
| 重いファイル（例：画像や動画の一時ファイル） | Gitには向かない |
| パスワードなどの秘密情報（例：APIキー） | 公開したら危険！ |
gitignoreの書き方
プロジェクトのルートフォルダに .gitignore という名前のテキストファイルを作成し、 中に除外したいファイルやフォルダのパターンを書くだけです。
📌 例：
# ビルド生成物
dist/
build/
# OSごとのゴミファイル
.DS_Store
Thumbs.db
# エディタの設定（VSCodeなど）
.vscode/
# ログや一時ファイル
*.log
*.tmp
# 秘密情報
.env
secret.json
おすすめ：.gitignoreのテンプレート
GitHubには有名な言語・ツール用の .gitignore テンプレートがあります。
例：Node.jsやPython、Unity、VSCodeなど
GitHub - github/gitignore: A collection of useful .gitignore templates
A collection of useful .gitignore templates. Contribute to github/gitignore development by creating an account on GitHub.
https://github.com/github/gitignore⚠ 注意点：
すでにGitで管理してしまったファイルは、.gitignoreでは無視されません
その場合は、以下のコマンドで削除＆無視ができます：
git rm --cached ファイル名
たとえば：
git rm --cached .env
まとめ
- .gitignoreは、**「無視するファイルリスト」**です。
- Gitに不要なファイルをコミットしないように制御できます。
- 開発が快適＆安全になり、GitHubにうっかり秘密情報を公開する事故も防げます。
関連リンク：
以下は、過去の.gitignoreにまつわる トラブルTipsを含んだ記事なので、興味があればご参考ください。
![[git] Gitで管理してるフォルダを分離させ新規リポジトリを作る](https://humanxai.info/images/uploads/git-separation-project.webp)
[git] Gitで管理してるフォルダを分離させ新規リポジトリを作る
Gitで管理してるフォルダを分離させ新規リポジトリを作る（トラブルシューティングあり）
https://humanxai.info/posts/git-separation-project/git statusで確認
Gitの「今の状況」を教えてくれるコマンドです。
今、何が変更されたか？ どのファイルがまだコミットされていないか？ を確認できます。
どんなときに使う？
| 使用タイミング | 目的 |
|---|---|
| ファイルを編集・追加・削除したあと | どれが変更されたか確認するため |
| コミット前に内容を確認したいとき | うっかりコミットミスを防ぐ |
git add や git commit の前後 |
状態がどう変化したかを把握する |
実際に活用情報の紹介をしてみます。
① 変更前の状態
$ git status
On branch main
nothing to commit, working tree clean
👉 これは「変更なし、すべてコミット済み」という意味です。
② ファイルを新しく作った時
$ echo "Hello" > hello.txt
$ git status
On branch main
Untracked files:
(use "git add <file>..." to include in what will be committed)
hello.txt
👉 Untracked files は「Gitがまだ管理してない新しいファイル」の意味です。
③ ファイルを編集した時
$ nano hello.txt # 編集
$ git status
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
modified: hello.txt
👉 modified: は「編集済みだが、まだコミットされていない」状態です。
④ git add したあとの状態
$ git add hello.txt
$ git status
On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
new file: hello.txt
👉 Changes to be committed は「次のコミットで記録される予定のファイル」です。
覚えておくと便利な用語
| 表示 | 意味 |
|---|---|
untracked |
Gitがまだ知らない新規ファイル |
modified |
変更されたけど、まだ add してない |
staged（to be committed） |
git add 済みで、コミット待ち |
まとめ
- git status は「今のGitの状態を確認するコマンド」
- 変更されたファイルがどういう状態なのかが一目でわかる
- コミット前に必ずチェックすると安全！
🕰️ git log とは？
Gitのコミット履歴（過去の記録）を表示するコマンドです。 「いつ」「誰が」「何を変更したか」など、プロジェクトの歴史がわかります。
どんなときに使うの？
| 使用タイミング | 目的 |
|---|---|
| いつどんな変更をしたか確認したいとき | 自分や他人の作業履歴を見る |
| コミットID（ハッシュ）を確認したい | git reset や git revert に使える |
| 変更の内容をたどりたいとき | バグ修正や差分調査の手がかりに |
実際に使ってみよう
基本形
$ git log
commit 1a2b3c4d5e6f7g8h9i0j (HEAD -> main)
Author: lain <lain@example.com>
Date: Fri Jun 21 10:00:00 2025 +0900
🎨 タイトル画面のBGM切り替え機能を追加
commit 0z9y8x7w6v5u4t3s2r1q
Author: lain <lain@example.com>
Date: Thu Jun 20 14:30:00 2025 +0900
🐛 カードめくり効果音の再生タイミングを修正
意味を解説
| 表示項目 | 意味 |
|---|---|
commit XXXXX |
各コミットのID（識別用ハッシュ） |
Author: |
誰が作業したか |
Date: |
いつ作業したか |
| コメント（最後） | 何をしたか（コミットメッセージ） |
より見やすくするオプション
- 1行でサクッと見る –oneline
$ git log --oneline
1a2b3c4 🎨 タイトル画面のBGM切り替え機能を追加
0z9y8x7 🐛 カードめくり効果音の再生タイミングを修正
👉 ハッシュとメッセージだけを1行で表示。履歴を素早く確認したい時に便利！
- グラフ付きでブランチを視覚化 –graph
$ git log --oneline --graph
* 1a2b3c4 🎨 タイトル画面のBGM切り替え機能を追加
* 0z9y8x7 🐛 カードめくり効果音の再生タイミングを修正
👉 分岐（ブランチ）やマージの流れが見えるので、複数人開発にも役立ちます。
まとめ
- git log は履歴を見るコマンド。プロジェクトの過去をたどれる。
- オプションで短く・見やすくできる（–oneline, –graph）。
- バージョン管理の強みを活かすための重要コマンド！
git reset とは？
Gitで作業していて、
- 「間違えてコミットしちゃった…」
- 「前の状態に戻したい…」
というときに使う、履歴や変更を“元に戻す”コマンドです。
知っておきたい3つの世界
Gitの変更には、実は以下の3段階があります：
| 領域 | 説明 |
|---|---|
作業ディレクトリ |
実際にファイルを編集している場所 |
ステージングエリア |
git add で準備された変更 |
リポジトリ（コミット） |
git commit で保存された履歴 |
| git reset は、この3つの領域のうちどこまで戻すかを選べます。 |
🔙 よく使う使い方と違い
✅ 1. ステージ解除だけ → git reset
$ git reset
- git add でステージングしたけど、「やっぱやめた！」という時。
- 作業ディレクトリ（編集済みファイル）はそのまま。
📝 例：
$ git add index.js
$ git reset # → ステージから除外されるが、編集内容は残る
❌ 2. 直前のコミットをなかったことにする → git reset –soft
$ git reset --soft HEAD^
- 最後のコミットを取り消して、内容はステージに残す。
- 「コミットは早すぎたけど、変更内容はまだ使う」というときに便利。
📝 例：
$ git commit -m "誤ってコミット"
$ git reset --soft HEAD^
❌ 3. 直前のコミット＋ステージも消す → git reset –mixed
$ git reset --mixed HEAD^
- 最後のコミットとステージを両方クリア。作業ディレクトリには残る。
- デフォルトの動きと同じ（–mixed は省略できる）
⚠️ 4. すべて元に戻す → git reset –hard
$ git reset --hard HEAD^
- コミットもステージも作業内容も全部戻る！
- 編集内容も完全に消える（要注意！）
🚨 危険！：
$ git reset --hard HEAD^
→ 取り返しがつかない消去になることも。使う前に慎重に確認！
よく使う場面まとめ
| 状況 | コマンド | 説明 |
|---|---|---|
git add を取り消したい |
git reset |
ステージから外すだけ |
| 直前のコミットだけ消したい | git reset --soft HEAD^ |
内容は保持、再編集できる |
| ステージも戻したい | git reset --mixed HEAD^ |
作業ファイルは残る |
| 全部なかったことにしたい | git reset --hard HEAD^ |
元に戻れない、要注意！ |
補足：HEAD^ってなに？
- HEAD：現在の最新コミット
- HEAD^：1つ前のコミット（HEAD~1 と同じ意味）
実験用に使ってみたい人へ
# 新しいブランチで実験しましょう！
$ git checkout -b reset-test
リスクなく試せるので、安心して git reset の挙動を学べます。
まとめ
- git reset は変更を「巻き戻す」コマンド。
- –soft, –mixed, –hard で巻き戻しレベルが変わる。
- –hard は取り消しできないので要注意！
変更の中身や履歴を確認する3つの便利コマンド
最後に、以下の３つのコマンドの解説をして終わりにしたいと思います。
- git show（特定のコミットの中身を見る）
- git diff（変更点だけを見る）
- git reflog（過去のHEADの動き）
git show：特定のコミットの中身をじっくり見る
🔧 使い方：
git show [コミットID]
📌 できること：
- そのコミットで「誰が・いつ・何を変更したか」が全部見える！
- 分（変更内容）もファイルごとに表示されます。
📝 よくある使い方：
git log --oneline # ← 一覧でコミットID確認
git show abc1234 # ← そのコミットの内容を確認
💡 例：
commit abc1234
Author: lain
Date: 2025-06-20
Fix bug in audio playback
diff --git a/app.js b/app.js
...
git diff：どこがどう変わったかを比較する
🔧 使い方：
git diff
📌 できること：
- ステージしてない変更内容を表示。
- 「今まさに何を編集してるか」が分かる。
他にも：
| コマンド | 比較する内容 |
|---|---|
git diff |
作業ツリー vs. ステージ |
git diff --staged（または --cached） |
ステージ vs. 最新コミット |
git diff HEAD~1 HEAD |
1つ前のコミットと最新コミットの比較 |
💡 例：
git diff
- volume = 1.0
+ volume = 0.8
git reflog：HEADがどこを指してたか履歴を見る
🔧 使い方：
git reflog
📌 できること：
- 過去の「HEADの動き」 をすべて記録してくれてる。
- 「やばっ！間違ってgit reset –hardしちゃった…」時も、ここから救出できる。
💡 例：
git reflog
abc1234 HEAD@{0}: reset: moving to HEAD~1
9f8e7d6 HEAD@{1}: commit: Fix volume bug
c1d2e3f HEAD@{2}: commit: Add title screen
これを見ると、
「あ、1個前のコミットは HEAD@{1} だったな」
というように、復元したい状態の「地点」を特定できます。
使いどころまとめ
| コマンド | 見える内容 | 主な用途 |
|---|---|---|
git show |
コミットの詳細（誰・いつ・何を） | コミット内容を確認したいとき |
git diff |
ファイルの変更点の差分 | 何がどう変わったか確認したいとき |
git reflog |
HEADの履歴（何をしてきたか） | 間違って戻してしまった履歴をたどる |
ワンポイント：初学者にありがちな誤解
- git log は 「公式の履歴」
- git reflog は 「あくまでローカルの行動履歴」
→ 共有リポジトリには含まれません（他人には見えません）
おすすめ練習コマンド
git log --oneline # コミット履歴を簡潔に
git show HEAD~1 # 1つ前のコミットの中身を確認
git diff # 今の作業内容の確認
git reflog # 過去の行動履歴のチェック
まとめ：Gitで自由に実験できる開発環境へ
Gitは最初こそ取っ付きづらいですが、使い慣れると「何をしても壊れない安心感」が得られます。
AIと人間の協働でどんどん開発が進む時代だからこそ、バージョン管理の基礎は習得しておきたいスキルです。
不明な点は、問題を先送りせず、AIを活用して問題を明確化した方が、広い目で見てトラブルが少ないと思います。
この記事の作成も、大半を質問形式でAIに解説を出力して貰い、それを少し手直しして記事化してますが、
同様にAIを活用して分からない事は、どんどん聞いていけばGitへの理解がより一層深まると思います。
ただ、一番は恐れずにコマンドを叩くことですね…。
この解説を読んでも、頭には入っても実際活用はしにくいのではないかと思うし、私自身も同じでした。
一度、サイトデータを全部飛ばすような過ちを犯したことがあり、その際に「git reset」のありがたみが身に染みて分かったり、 状況を確認する一連のコマンドの使い方も、身に染みて分かりました。
Gitはよほどのことがない限りデータが飛ぶ事がないように設計されているので、恐れず毎日コマンドを叩くことが重要だと思います。
この記事を読まれてる、貴方の良きパートナーとしてGitを活用してもらえるようになれたら幸いです。
💡次回予告
次は、いよいよ作成したゲームの公開
「#05 Web公開の選択肢：GitHub Pages・Netlifyなど比較」
について、実践していきます。
💬 コメント