Git初心者が学んだ！はじめての「GitHubバージョン管理」の始め方

最近、ひとりでアプリやウェブサービスを作ろうと思い立ち、「Gitでコード管理すると便利らしい」という噂を聞き、思い切って始めてみました。最初は「Gitってなんや、わざわざGitを使う意味ある？」と疑問だったのですが、こまめにバージョンを記録して差分を追えるメリットは想像以上に大きかったんです。ここでは、私が学んだGitとGitHubの基本的な流れや、AI対応エディターを使って作業をラクにする方法、そして各種コマンド例も含めてご紹介します。

私がGitを最初に触れたのは、「コードが分からず自然言語でAIに開発を依頼し、エラーが起き、そしてAIに修正を頼んだら出力がめちゃくちゃになってしまった」という経験からでした。とはいえ、ターミナルでコマンドを打つのも初めてで、`git init`、`git add`、`git commit`…どのタイミングでやればいいのか分からず混乱したんですよね。しかも、ブランチとかプルリクエストなんて聞くと「なにがなんやら？」という状態でした。実際にファイルを上書きして困ったり、変更点を見失ったりすることを何度か繰り返した頃に、「これはちゃんとGitを使いこなしたほうが良さそうだ」とようやく腹をくくった感じです。結果としては、一つひとつの作業を記録しておけるメリットに気づき、今では「Gitなしの開発は怖すぎる！」と思うほどになりました。

まずはGitがどんな仕組みで動いているかをざっくり理解して、変更を「ステージ→コミット」で記録する流れに慣れてみるのがおすすめです。個人開発でもブランチを使えば、実験的な機能を別ラインで開発して、うまくいったらメインブランチに取り込む、という安全策が取れるようになります。GitHubにリポジトリを作っておけば、万が一PCがクラッシュしても、リモート上にデータが残るので安心。さらに、AI対応エディター（CursorやWindsurfなど）を使ってみると、コミットメッセージを自動で生成できたり、自然言語でGit操作ができたりと、覚える手間がかなり軽減される点も大きいですよ。では、私がやってみて感じたポイントと、その際に利用したコマンドを詳しく解説します。

● 個人開発でもGitは大いに役立つ

Gitは複数人でのチーム開発に限らず、個人開発でも大いにメリットがあります。たとえば長く続けている趣味のプロジェクトだと、いつの間にかコード量が増えて「どの段階でどんな変更をしたんだっけ？」と分からなくなる瞬間、ありませんか？ Gitでは、コミット単位で差分を追えるので、もしバグが入り込んだとしても「いつ頃からバグが発生し始めたか」を調べやすくなります。しかも、そのコミットごと取り消して以前の状態に戻すことさえ可能です。

● ステージとコミットの基本的な流れ

私が最初に苦労したのは、「ステージとコミットをいつやればいいの？」という点でした。いざやってみると、「編集が終わったファイルは`git add .`でステージして、`git commit -m "コメント"`で履歴に残す」だけで意外と簡単。コミットメッセージをしっかり書いておけば、「このコミットはUIを微調整」「アルゴリズムの速度を改善」など、後から思い返すのが楽になります。個人開発だとしても、「どうしてこう変えたんだっけ？」がひと目でわかるのは助かります。

Git の３つの主要な場所

Gitの用語、「ワークツリー」「ステージングエリア」「ローカルリポジトリ」を、たとえば身近な「机」「チェック用の箱」「記録アルバム」に例えてみましょう。

1. ワークツリー（Working Directory）＝「あなたの机」

• 説明：
  ワークツリーは、あなたが普段使っている作業スペース、つまりパソコン上でファイルを編集したり、新しく作ったりする場所です。

• 例え：
  これは、机の上に散らばっている書類やメモのようなものです。まだ正式にどこかに保存（記録）されていない、今作業中の状態と考えてください。

---

2. ステージングエリア（Staging Area / Index）＝「チェック用の箱」

• 説明：
  ステージングエリアは、あなたが机で作業してできた書類の中から、これから正式に記録（コミット）したいものを一時的に集めておく場所です。

• 例え：
  これは、机に散らばっている書類の中から「提出する書類だけ」をピックアップして、専用の箱に入れる作業に似ています。たとえば、試験前に答案用紙を選び出して、提出用の箱に入れるイメージです。

• ポイント：
  もし机（ワークツリー）にその後書き直しをしても、箱（ステージングエリア）に入れておいた内容はそのままなので、間違った状態で提出（コミット）されるのを防ぐことができます。

---

3. ローカルリポジトリ（Local Repository）＝「記録アルバム」

• 説明：
  ローカルリポジトリは、ステージングエリアに集めた書類（変更内容）を、正式に記録として保存する場所です。

• 例え：
  これは、箱に入れた提出書類を、最終的にファイルキャビネットや記録アルバムにしっかりと保存する作業に似ています。保存された記録は、あとでいつでも見返すことができ、もし必要ならその状態に戻すことも可能です。

• ポイント：
  コミット（記録アルバムに保存する作業）は、ステージングエリア（箱）の内容を確定させる大事なステップです。

Git の基本操作の流れ（例：机→箱→アルバム）

• 作業する（ワークツリー＝机）ファイルを作ったり編集したりします。例えば、新しいメモを机の上に置くイメージです。

• 選ぶ（ステージングエリア＝箱に入れる「この書類は正式に記録に残そう」と思ったものを、git add ファイル名 で箱に入れます。例：

$ git add sample.txt

• 記録する（コミット＝アルバムに保存する）箱に入れた書類を、git commit -m "コミットメッセージ" で記録アルバムに保存します。例：

$ git commit -m "sample.txt を追加して、Hello Git と表示するように変更"

• 履歴を確認する　いつ保存（コミット）したのか、どんな内容なのかを git log で確認できます。例：

$ git log

---

point

• ワークツリー（机）：
  作業中のファイルが置かれる場所。まだ正式な記録にはなっていない状態です。

• ステージングエリア（箱）：
  次に記録（コミット）するために、机から選び出したファイルを一時的に集める場所です。

• ローカルリポジトリ（記録アルバム）：
  ステージングエリアに入れたファイルを、正式な履歴として記録する場所です。

この流れは、日常生活で何かを整理して記録するプロセスと似ています。まずは机の上で自由に作業し、必要なものだけをチェック用の箱にまとめ、最後に記録アルバムに保存するイメージで覚えてみてください。

ブランチ管理は実は便利

ブランチも「一人なら必要ない？」と最初は思っていましたが、使い始めてみると安定版（メインブランチ）を壊さずに新機能を試せるので、不安なくガンガン実験できるんですよね。うまくいったらマージ、ダメならブランチごと破棄。個人開発でも大いに役立ちます。

GitHubでのバックアップ

さらに、GitHubを使えばリポジトリをクラウド上に置けるので、PCトラブルや誤ってファイルを消したときにも履歴を復旧できるのが最高です。プライベートリポジトリなら他人に見られませんし、将来的に共同開発したくなったら、そのまま公開や招待するだけなので拡張性もバッチリ。

AI対応エディター（Cursor・Windsurf）で作業がラクに

最近はCursorやWindsurfなどのAI対応エディターを使えば、コミットメッセージを自動生成してくれたり、自然言語で「コミットしてプッシュして」と頼むだけでGit操作を代行してくれたりします。すべてをAI任せにするのは怖いですが、最終チェックを自分でしながら使えば、コマンド入力の手間がぐっと省けて個人開発の生産性が上がります。

リポジトリの準備（作成・クローン）

1. ローカルで新規作成する場合   　　　　　　　　　　　　　　　

ディレクトリを作成して移動

 mkdir my-project
  cd my-project

Git管理を開始する

git init

この時点で.gitディレクトリが生成され、ここに履歴が保存されるようになります。

2. リモートリポジトリ（GitHub）を作成し、紐付ける場合

• GitHubのウェブ画面で「New repository」をクリックし、リポジトリ名を入力して作成

• ローカルで以下のコマンドを実行

git remote add origin <リポジトリURL>
git branch -M main
git push -u origin main

これでローカルのmainブランチが、GitHubのmainブランチと追跡関係を持つようになります。

3. 既存のリポジトリをクローンする場合

git clone <リポジトリURL>

これでGitHub上のリポジトリが、丸ごとローカルにコピーされます。
GitHubと連携しておくと、PCを乗り換えたり別の場所で作業したりするときに楽になりますし、バックアップにもなるのでおすすめです。

ブランチ管理

1. ブランチの作成と移動

• 新機能や実験的な変更を試す際に、メインブランチを壊さないためにもブランチを分けます。

# 新しいブランチを作成
git branch feature/experiment

# ブランチへの切り替え
git checkout feature/experiment

※ Gitのバージョンが新しければ、git switch -c feature/experimentでもOKです。

2. ブランチの一覧や削除

• 現在のローカルブランチ一覧を確認

git branch

• 不要になったブランチを削除

git branch -d feature/experiment

まだマージしていないブランチを強制削除する場合は、-Dオプションを使うこともあります。

3. ブランチの活用ポイント

• メインブランチ（main）には安定したコードのみを置き、実験や大きな修正は別ブランチで行う。

• うまくいったらメインにマージし、必要なければブランチごと破棄すればメインを汚さずに済む。

• 一人開発でも「コードが壊れたらどうしよう」という不安を減らせるため、ブランチ管理はおすすめです。

変更の記録（ステージとコミット）

1. ステージとコミットの基本

• 編集を終えたファイルをステージする

git add <ファイル名>
git add .

git add . でカレントディレクトリ以下の全変更をまとめてステージできます。

• コミットで履歴を保存する

git commit -m "変更内容のコメント"

例

git commit -m "feat: ユーザーログイン機能を追加"

2. コミットメッセージのコツ

• 何をどう変えたかが分かるように、短くても具体的に書くと後で便利。

• 一人開発だとしても「どうしてこう直したのか」を思い出せるようにすると、長期プロジェクトでは特に役立ちます。

3. コミット履歴の確認

git log

コミットIDやメッセージ、日時が表示されます。
git log --onelineで1行表示になるので見やすくなる場合があります。

リモートリポジトリ操作（プッシュ / プル）

1. プッシュ（Push）

• ローカルの変更をリモート（GitHub）に送る

git push origin <ブランチ名>

初回のみ、追跡設定を兼ねて -u オプションを使うのがおすすめ

git push -u origin <ブランチ名>

これで次回からは単に git push でOK。

2. プル（Pull）

• リモートの最新を取り込み、現在のブランチにマージ

git pull origin <ブランチ名>

チーム開発のイメージが強いかもしれませんが、一人でも複数端末を使う場合には重要。
最新の変更が反映されていないまま作業すると、後でコンフリクトの原因になります。

3. フェッチ（Fetch）

• リモートのコミット情報やブランチ一覧だけを更新する

git fetch origin

自動マージはせず、リモートの状態を確認したいときに便利です。
その後、必要なら git merge や git pull で自分のブランチに取り込みます。

プルリクエスト（Pull Request)

1. 個人開発でも使えるPR

• チームレビュー用と思われがちなプルリクエスト（PR）ですが、一人開発でもセルフレビューに役立ちます。

• 新機能をブランチで作ったあと、GitHub上から「New Pull Request」を作成してみましょう。

• 差分が見やすいので、「どこを変更したか」をパッと把握できます。

2. プルリクエストの作り方

1. ローカルでブランチを作って作業

2. git push origin <ブランチ名> でリモートへアップ

3. GitHub画面にアクセスし、「Compare & pull request」などの案内に従ってPRを作成

3. マージとクローズ

• 一人開発でも、PR画面で差分をチェックして「問題なさそう」と思えば「Merge pull request」でメインブランチに統合。

• 変更が取り込まれた時点でPRはクローズされます。

---

マージ（Merge）

1. ブランチを統合する

• コマンドでマージするとき

# メインブランチに移動
git checkout main

# featureブランチをmainに取り込む
git merge feature/experiment

• プルリクエスト経由の場合は、GitHub上で「Merge pull request」をクリックするだけで同じ処理が行われます。

2. コンフリクト（競合）対処

• 異なるブランチで同じ行を編集すると衝突し、コンフリクトが発生する場合があります。

• 対応策:

  1. コンフリクトが生じたファイルを開く

  2. <<<<<<< HEAD などの印を目安に、どちらの変更を採用するか手動で修正

  3. 修正をステージしてコミットし直す

• コンフリクトはむしろ、衝突箇所を教えてくれる仕組みなので、焦らずに対応すればOK。

3. マージ戦略

• 「Merge commit」を残して履歴を分かりやすくするか、「Squash and merge」でコミットをまとめるかはお好み。

• 個人開発の場合は、そこまで複雑にならないので、シンプルにマージコミットを残す運用でも十分です

AI対応エディターでのGit操作（Cursor・Windsurf）

1. Cursorでコミットメッセージ自動生成

• ステージした変更をAIが解析し、コミットメッセージを提案してくれる機能が便利。

• たとえば、誤字修正を含む変更なら「fix: タイポ修正」など、自分で考えるより早く的確なメッセージが得られることもあります。

2. Windsurfで自然言語操作

• 「commit and push my changes」とチャットで指示すれば、AIがgit add .→git commit -m "～"→git pushの流れを代行。

• すべてを任せすぎると危ない面もあるので、最終的な確認は自分で行うと安心。

3. 使い分けのポイント

• 簡単な修正はAIエディターをフル活用し、コミットメッセージを瞬時に生成

• 重要な変更や複雑なコンフリクトは、コマンドラインや手動でじっくり対処

• 個人開発は時間との勝負でもあるので、上手にAIを取り入れるのは大いにアリ。

最後に

GitとGitHubによるバージョン管理は大きな助けになります。こまめなコミットやブランチの活用で、思い切った実装や実験ができるようになり、万が一のときも簡単に過去の状態に戻れる安心感は格別です。さらにGitHubを使えば、バックアップと他人と共同作業する場合にも備えられるので、一石二鳥どころか三鳥四鳥のメリットを得られるでしょう。AI対応エディターを導入すれば、コミットメッセージ作成などの煩わしさもグッと減るので、ぜひ試してみてください。バージョン管理をちゃんとやることで、個人開発がもっと気楽に、そして楽しくなるはずです。