MechaToraのブログ

記事のアイキャッチ画像
技術・開発

Git/GitHub実践ガイド - 個人開発で使えるワークフロー

「Gitは難しい」「コマンドが覚えられない」「コンフリクトが怖い」——プログラミング初心者がGitで躓くのはよくある話です。しかし、基本的な使い方を理解すれば、Gitは強力なバックアップ・履歴管理ツールになります。

この記事では、MechaToraで15個のプロジェクトを管理してきた経験から、個人開発で実際に使っているGit/GitHubのワークフローを解説します。最低限覚えるべきコマンド、ブランチの使い方、よくあるトラブルの解決法まで、実践的な内容をお伝えします。

なぜGit/GitHubが必要なのか

Gitがない世界

Git導入前の私の管理方法:

project/
├── index.html
├── index_backup.html
├── index_backup2.html
├── index_old.html
├── index_20240101.html
├── index_final.html
├── index_final_final.html
└── index_本当に最終版.html

これでは、以下の問題が発生します:

Gitのメリット

Git/GitHubの基本概念

セクション画像

リポジトリ(Repository)

プロジェクトの保管庫。ファイルと変更履歴を全て含みます。

コミット(Commit)

変更を記録する単位。「セーブポイント」のイメージです。

ブランチ(Branch)

並行して複数のバージョンを管理する機能。新機能開発時に使います。

リモート(Remote)

GitHub上のリポジトリ。ローカル(自分のPC)の変更をアップロードします。

環境構築

Gitのインストール

# Mac(Homebrew)
brew install git

# Windows
# https://git-scm.com/ からインストーラーをダウンロード

# インストール確認
git --version
# 出力例: git version 2.39.0

初期設定

# ユーザー名とメールアドレスを設定(GitHubと同じにする)
git config --global user.name "MechaTora"
git config --global user.email "mechatora@example.com"

# デフォルトブランチ名を main に設定
git config --global init.defaultBranch main

# 設定確認
git config --list

基本ワークフロー

セクション画像

1. リポジトリの作成

# プロジェクトフォルダに移動
cd my-project

# Gitリポジトリを初期化
git init

# 出力: Initialized empty Git repository in /path/to/my-project/.git/

2. ファイルを追加してコミット

# ファイルを作成
echo "# My Project" > README.md

# ステージングエリアに追加
git add README.md

# または、全てのファイルを追加
git add .

# コミット(変更を記録)
git commit -m "Initial commit: Add README"

# 出力:
# [main (root-commit) a1b2c3d] Initial commit: Add README
#  1 file changed, 1 insertion(+)

3. GitHubにプッシュ

# GitHub で新しいリポジトリを作成後、リモートを追加
git remote add origin https://github.com/mechatora/my-project.git

# main ブランチをプッシュ
git push -u origin main

# 2回目以降は
git push

日常的に使うコマンド

現在の状態確認

# 変更されたファイルを確認
git status

# 出力例:
# On branch main
# Changes not staged for commit:
#   modified:   index.html
# Untracked files:
#   style.css

変更内容の確認

# ファイルの差分を表示
git diff

# ステージング済みの差分を表示
git diff --staged

コミット履歴の確認

# コミット履歴を表示
git log

# 1行で表示(見やすい)
git log --oneline

# 出力例:
# a1b2c3d (HEAD -> main) Fix bug in login form
# e4f5g6h Add user authentication
# i7j8k9l Initial commit

私がよく使うコマンドトップ5

  1. git status:現在の状態確認(1日10回以上)
  2. git add .:全ての変更をステージング
  3. git commit -m "message":コミット
  4. git push:GitHubにアップロード
  5. git log --oneline:履歴確認

ブランチの使い方

なぜブランチを使うのか

新機能開発中に、mainブランチ(本番用)を壊したくないからです。

ブランチの基本操作

# 新しいブランチを作成
git branch feature/new-login

# ブランチ一覧を表示
git branch

# 出力:
# * main
#   feature/new-login

# ブランチを切り替え
git checkout feature/new-login

# または、作成と切り替えを同時に
git checkout -b feature/new-login

ブランチでの作業

# feature/new-login ブランチで開発
# ファイルを編集...

git add .
git commit -m "Add new login form"

# GitHubにプッシュ
git push -u origin feature/new-login

ブランチのマージ

# main ブランチに戻る
git checkout main

# feature/new-login をマージ
git merge feature/new-login

# 不要なブランチを削除
git branch -d feature/new-login

実践:MechaToraでのブランチ戦略

シンプルな運用

個人開発なので、以下のシンプルなルールで運用しています:

実際のワークフロー

# 1. 新機能開発開始
git checkout -b feature/earthquake-notification

# 2. 開発してコミット
git add .
git commit -m "Add earthquake notification feature"

# 3. GitHubにプッシュ
git push -u origin feature/earthquake-notification

# 4. 動作確認OK → main にマージ
git checkout main
git merge feature/earthquake-notification

# 5. 本番環境にデプロイ
git push

# 6. ブランチ削除
git branch -d feature/earthquake-notification
git push origin --delete feature/earthquake-notification

コンフリクトの解決

コンフリクトとは

同じファイルの同じ箇所を、異なるブランチで別々に編集したときに発生します。

コンフリクトの例

# mainブランチでマージしようとすると...
git merge feature/update-header

# 出力:
# Auto-merging index.html
# CONFLICT (content): Merge conflict in index.html
# Automatic merge failed; fix conflicts and then commit the result.

解決方法

ファイルを開くと、以下のような表示があります:

<!-- index.html -->
<header>
<<<<<<< HEAD
    <h1>MechaTora - Webツール</h1>
=======
    <h1>MechaTora - 便利なアプリ</h1>
>>>>>>> feature/update-header
</header>

手動で修正:

<!-- 修正後 -->
<header>
    <h1>MechaTora - 便利なWebツール</h1>
</header>

コミット:

git add index.html
git commit -m "Resolve merge conflict in header"

よくあるトラブルと解決法

トラブル1:コミットを取り消したい

# 直前のコミットを取り消し(変更は残す)
git reset --soft HEAD~1

# 直前のコミットを完全に削除(変更も消える)
git reset --hard HEAD~1

# 注意:pushした後は使わない!

トラブル2:間違えてファイルを削除してしまった

# 最後のコミット時点に戻す
git checkout -- index.html

# 全てのファイルを戻す
git checkout -- .

トラブル3:GitHubにpushできない

# エラー: Updates were rejected because the remote contains work...

# 原因:リモートに新しいコミットがある

# 解決策:まずpullする
git pull origin main

# コンフリクトがあれば解決後、再度push
git push

トラブル4:.gitignore を後から追加

# .gitignore ファイルを作成
echo "node_modules/" > .gitignore
echo ".env" >> .gitignore

# すでにトラッキングされているファイルを削除
git rm -r --cached node_modules/
git rm --cached .env

# コミット
git add .gitignore
git commit -m "Add .gitignore"

.gitignore の活用

基本的な .gitignore

# 依存関係
node_modules/
vendor/

# 環境変数
.env
.env.local

# ビルド成果物
dist/
build/

# エディタ設定
.vscode/
.idea/

# OS固有ファイル
.DS_Store
Thumbs.db

# ログファイル
*.log

コミットメッセージのベストプラクティス

良いコミットメッセージ

✅ feat: Add earthquake notification feature
✅ fix: Resolve login form validation bug
✅ docs: Update README with setup instructions
✅ refactor: Extract API calls to separate module
✅ style: Format code with Prettier

悪いコミットメッセージ

❌ 修正
❌ Update
❌ aaa
❌ 色々直した
❌ とりあえずコミット

Conventional Commits

プレフィックスで種類を明示:

GitHub Pages へのデプロイ

# 1. GitHubでリポジトリ作成

# 2. ローカルリポジトリとリンク
git remote add origin https://github.com/mechatora/my-site.git

# 3. プッシュ
git add .
git commit -m "Initial commit"
git push -u origin main

# 4. GitHub のリポジトリ設定 → Pages
# Source: main branch を選択

# 5. https://mechatora.github.io/my-site/ でアクセス可能!

まとめ

最低限覚えるべきコマンド

# 初期設定(1回だけ)
git config --global user.name "Your Name"
git config --global user.email "your@email.com"

# 新規プロジェクト
git init
git add .
git commit -m "Initial commit"
git remote add origin [GitHub URL]
git push -u origin main

# 日常的な作業
git status          # 状態確認
git add .           # 変更をステージング
git commit -m "〇〇" # コミット
git push            # GitHubにアップロード
git pull            # GitHubから最新を取得

# ブランチ作業
git checkout -b feature/new-feature  # ブランチ作成・切り替え
git checkout main                    # mainに戻る
git merge feature/new-feature        # マージ

運用のコツ

Gitは最初は難しく感じますが、基本的なコマンドを繰り返し使えば自然と身に付きます。MechaToraでは、15個のプロジェクト全てをGitで管理し、変更履歴を完全に追跡できています。

まずは、小さなプロジェクトで試してみてください!