【個人開発】HabitSparkリリースまでに実際に使ったGit/GitHubコマンド＆運用備忘録（図解あり）

はじめに

先日、KPT（Keep, Problem, Try）フレームワークを活用した習慣化アプリ「HabitSpark」をリリースしました！
👉 HabitSpark-振り返りで続くシンプル習慣化アプリ

開発を進める中で、ソースコードのバージョン管理としてGitとGitHubを使用しました。
チーム開発ほどの厳密なルールは必要ありませんが、「動いていた状態にすぐ戻せる」「秘密のファイルをうっかり公開しない」といった最低限の運用は個人開発でも必須です。

この記事では、今回のアプリ開発で実際にこれだけは絶対に使った！というGitコマンドと、個人開発向けのシンプルな運用ルールを図解も交えて備忘録としてまとめます。

1. 個人開発でのシンプルなブランチ運用

チーム開発では「Git Flow」や「GitHub Flow」などを導入しますが、一人開発の場合はシンプルイズベストです。今回は以下のような運用にしました。

main ブランチ: 常に「App Storeにリリースできる（またはしている）安定版」を置く。
feature/... ブランチ: 新機能の追加やバグ修正を行う時は、必ずここから派生させる。

👉 「mainブランチに直接コミットしない」 というルールを守るだけでも、バグが起きた時の原因究明が劇的に楽になります。

2. 開発スタート時の初期設定

Xcodeでプロジェクトを作成したら、まずはターミナルで対象のディレクトリに移動してGitを初期化します。

Gitの初期化

# プロジェクトのディレクトリに移動
cd path/to/your/project

# Gitリポジトリを作成
git init

⚠️ 超重要：.gitignore の設定

AdMobなどの広告ID、APIキー、証明書などの機密情報が含まれるファイルは、絶対にGitHubにプッシュしてはいけません。

開発を始める前に、必ず .gitignore ファイルを作成します。

# .gitignoreを作成し、追跡から除外したいファイル名を追記
echo "Config.swift" >> .gitignore
echo ".DS_Store" >> .gitignore

💡 これを忘れると、最悪の場合APIキーなどが不正利用される事故に繋がるので注意です。

3. Gitの仕組み（4つのステージ）

コマンドを丸暗記する前に、「今自分のコードがどこにあるのか」を視覚的に理解することが一番の近道です。各コマンドが「どの領域のデータを動かしているのか」を図解してみました。

💡 コマンドの前に：Gitの「4つのステージ」を理解する

Gitで混乱する原因のほとんどは、
👉 「今どの状態にいるのか分からないこと」 です。

この「4つのステージ」を理解すると、
👉 「なぜこのコマンドを打つのか」 が一気に分かるようになります。

Gitには、データが移動する「4つの場所」があります。

1. Working Directory（作業ディレクトリ）

ここはどこ？ あなたのPC上のフォルダ。Xcodeでコードを書いている場所です。
状態保存しただけでは、まだGitには記録されていません。
👉 やること コードを書く・編集するだけ

2. Staging Area（ステージングエリア）

ここはどこ？ コミットする前に、変更を一時的に置いておく「準備用の箱」
状態 git add を使うとここに入る
👉 使うコマンド git add .
👉 ポイント 「この変更だけ保存したい」と選べる

3. Local Repository（ローカルリポジトリ）

ここはどこ？ PC内の「セーブデータ置き場」
状態 git commit で履歴として保存される
👉 使うコマンド git commit -m "変更内容"
👉 ポイント この時点ではまだ自分のPCにしかない

4. Remote Repository（リモートリポジトリ）

ここはどこ？ GitHubなどのクラウド上
状態 git push で初めてアップロードされる
👉 使うコマンド git push origin main
👉 ポイント ここまでやって初めてバックアップ完了

💥 よくあるミス

「保存したのにGitHubに反映されない…」
👉 原因： git push していない（ローカルにしか保存されていない）

🧠 まとめ（超重要）

Gitの流れはシンプルです👇

作業する（Working Directory）
変更を選ぶ（Staging Area）
履歴として保存（Local Repository）
クラウドにバックアップ（Remote Repository）

👉 この流れを理解していれば、Gitで迷うことはかなり減ります。

4. 実際に使う基本コマンド

ここからは、実際に開発中によく使うコマンドです。開発中の9割はこの作業の繰り返しになります。
👉 「いつ使うのか」もセットで覚えるのがポイントです。

① 変更を確認する

# 今どんな変更があるか確認
git status

👉 使うタイミング
作業を再開したとき / コミット前
（とりあえず最初に打つ）

② 変更をステージングする

# 特定ファイルだけ追加
git add ContentView.swift

# すべて追加
git add .

👉 使うタイミング
「この変更を保存したい」と決めたとき

③ コミットする

# ローカルに保存
git commit -m "タスク追加機能のUIを実装"

👉 使うタイミング
ひと区切りついたとき（小さくこまめに）

💡 コミットメッセージのコツ
「何をしたか + なぜしたか」を書く
→ 後から見返したときに助かる

④ ブランチを切る・移動する

# ブランチ確認
git branch

# 新規ブランチ作成＆移動
git checkout -b feature/admob-implementation

👉 使うタイミング
新機能・バグ修正を始めるとき

👉 ポイント
mainに直接コミットしないだけで安全性が上がる

5. GitHubへのプッシュ（リモート保存）

ローカルで保存した内容をGitHubにアップロードします。

初回のみ：リモートリポジトリの登録

git remote add origin [https://github.com/ユーザー名/リポジトリ名.git](https://github.com/ユーザー名/リポジトリ名.git)
git branch -M main
git push -u origin main

2回目以降：普段のプッシュ

git push origin feature/admob-implementation

👉 使うタイミング
作業が一段落したとき / バックアップしたいとき

💡 ワンポイント
👉 commit ＝セーブ
👉 push ＝クラウド保存
この違いを意識するだけで、事故がかなり減ります。

6. やらかした時のリカバリー用コマンド

個人開発で一番焦るのは「コードをいじってたら、アプリが動かなくなったし直し方も分からなくなった」時です。

コミットする前に、直前のコミットの状態まで戻す（変更の破棄）

「あー、今の修正やっぱり全部ナシ！」という時に使います。

# 特定のファイルの変更を取り消す
git restore ContentView.swift

# すべてのファイルの変更を取り消す（※本当に消えるので注意）
git restore .

直前のコミットのメッセージを間違えた時

# エディタが開くので、そこでメッセージを書き直す
git commit --amend

過去のコミット履歴を見る

「いつ、どこでバグを埋め込んだのか」を探す時に使います。

# 一行でスッキリと履歴を見る
git log --oneline

まとめ

個人開発におけるGit運用のポイントは以下の3つです。

main には直接コミットせず、作業用ブランチを切る
機密ファイルは絶対に .gitignore に入れる
動いている状態を細かくコミットしておく（セーブポイントを作る）

HabitSparkの開発でも、途中で実装を大きく変えたい時に「別ブランチを切って試す → 失敗したらブランチごと消す」というやり方で何度もGitに助けられました。

👉 Gitは難しそうに見えますが、
やっていることは**「セーブとバックアップ」**だけです。

この備忘録が、これからアプリの個人開発を始める方の参考になれば幸いです！

※ 記事内の図解イラストは、画像生成AIを使用して作成しています。