Web開発現場で必須のGitの基本コマンドから、よくあるミスの対策まで実際のプロジェクトベースで詳しく解説します。
こんな悩みありませんか?
「コードを修正したら動かなくなって、前の状態に戻せない」「チームでファイルを共有していて、誰がどこを変更したか分からない」「間違えて重要なファイルを削除してしまった」
神奈川のWeb制作会社Fivenine Designで20年間プロジェクトを手がける中で、こうした悩みを持つクライアントの皆様と数多くお会いしてきました。特に、複数人でWordPressサイトを管理されている企業様や、LaravelやNext.jsでシステム開発を進めている開発チーム様から、ファイルの管理に関するご相談を頻繁にいただきます。
これらの課題を根本的に解決するのが**バージョン管理システム「Git」**です。本記事では、YouTube動画では説明しきれなかった詳細な操作方法と、現場で実際に起こりがちなトラブルの対策を、実践的なコマンド例とともにお伝えします。
なぜバージョン管理が必要なのか?現場の実情
従来のファイル管理で起こる問題
あるクライアント企業では、WordPressのカスタムテーマを複数人で開発していました。当初は「ファイル名に日付を付ける」「修正前のファイルをコピーして残す」といった方法で管理されていましたが、以下のような問題が頻発していました:
style.css、style_backup.css、style_20241201.cssといったファイルが乱立- どのファイルが最新版か分からなくなる
- 同じファイルを複数人が同時に編集してしまう
- 重要な変更履歴が失われる
- 本番環境に間違ったファイルをアップロードしてしまう
こうした状況では、開発効率が大幅に低下し、品質の低下やセキュリティリスクの増大にもつながります。
Gitが解決する課題
Gitを導入することで、以下のような変化が期待できます:
GitとGitHubの違いを理解する
初心者の方によくある誤解として「Git=GitHub」というものがあります。実際は以下のような関係です:
| 項目 | Git | GitHub |
|---|---|---|
| 種類 | ソフトウェア(ツール) | Webサービス(プラットフォーム) |
| 機能 | バージョン管理 | Gitリポジトリのホスティング |
| 場所 | ローカル環境 | クラウド |
| 利用料金 | 無料 | 基本無料(プラン有り) |
| インターネット | 不要 | 必要 |
Gitは、あなたのパソコン上でファイルの変更履歴を記録・管理するツールです。一方、GitHubは、そのGitで管理したファイルをインターネット上で共有・保存できるサービスです。
基本コマンドの詳細解説と実践例
1. プロジェクト初期化(git init)
新しいプロジェクトでGitを始める場合の手順:
# プロジェクトディレクトリに移動
cd /path/to/your/project
# Gitリポジトリを初期化
git init
# 確認:.gitフォルダが作成されているか
ls -la
実際のプロジェクトでは、このように使います:
# WordPressのカスタムテーマ開発の場合
cd /wp-content/themes/custom-theme
git init
echo "# Custom WordPress Theme" > README.md
2. ファイルをステージに追加(git add)
git addコマンドは、変更したファイルを「次のコミットに含める準備」をするコマンドです:
# 特定のファイルを追加
git add style.css
# 複数ファイルを指定
git add index.php functions.php
# すべての変更ファイルを追加(注意が必要)
git add .
# 変更されたファイルのみ追加(新規ファイル除く)
git add -u
重要な注意点:git add .は便利ですが、機密情報を含むファイル(.envファイルなど)も追加してしまう可能性があります。後述の「よくある失敗」で詳しく解説します。
3. 変更をコミット(git commit)
コミットは「変更内容を記録として保存する」作業です:
# コミットメッセージを付けて保存
git commit -m "ヘッダーデザインを修正"
# より詳細なメッセージの場合
git commit -m "feat: レスポンシブ対応のヘッダーナビゲーションを実装
- スマートフォン表示でハンバーガーメニューを追加
- タブレット表示での配置を調整
- アクセシビリティを向上(キーボードナビゲーション対応)"
コミットメッセージの良い例・悪い例:
git commit -m "fix: お問い合わせフォームのバリデーションエラーを修正"
git commit -m "feat: 商品検索機能にカテゴリフィルターを追加"
git commit -m "style: CSSの整理とコメント追加"
4. リモートリポジトリにプッシュ(git push)
ローカルの変更をGitHubなどのリモートリポジトリに送信:
# 初回:リモートリポジトリを登録してプッシュ
git remote add origin https://github.com/username/repository.git
git branch -M main
git push -u origin main
# 2回目以降:通常のプッシュ
git push origin main
# 現在のブランチをプッシュ(ブランチ名を省略)
git push
実際のワークフロー例
Laravelプロジェクトでの典型的な作業フローを見てみましょう:
# 1. 現在の状況を確認
git status
# 2. 新機能のブランチを作成・切り替え
git checkout -b feature/user-authentication
# 3. ファイルを編集後、変更内容を確認
git diff
# 4. 変更をステージに追加
git add app/Http/Controllers/AuthController.php
git add resources/views/auth/
# 5. コミット
git commit -m "feat: ユーザー認証機能を実装
- ログイン・ログアウト機能
- ユーザー登録機能
- パスワードリセット機能"
# 6. リモートにプッシュ
git push origin feature/user-authentication
よくある失敗パターンと対策
1. 機密情報の漏洩リスク
失敗例:データベースのパスワードや API キーを含む .env ファイルをコミットしてしまう
# 危険な例
git add . # .envファイルも含めてすべて追加してしまう
git commit -m "設定ファイル更新"
git push origin main # 機密情報が公開リポジトリに!
対策:.gitignoreファイルを適切に設定
# .gitignoreファイルの内容
.env
.env.local
.env.production
node_modules/
vendor/
*.log
.DS_Store
Thumbs.db
# WordPressの場合
wp-config.php
wp-content/uploads/
既に機密情報をコミットしてしまった場合の緊急対応:
# 最新のコミットを取り消し(まだpushしていない場合)
git reset --soft HEAD~1
# ファイルをステージから除外
git reset HEAD .env
# .gitignoreを作成・編集してから再コミット
echo ".env" >> .gitignore
git add .gitignore
git commit -m "feat: .gitignoreを追加して機密情報を除外"
2. 強制プッシュ(force push)の危険性
失敗例:チームメンバーの変更を知らずに強制プッシュしてしまう
# 危険な例
git push --force origin main # 他の人の変更が失われる可能性
対策:安全な更新方法を使う
# 1. リモートの最新情報を取得
git fetch origin
# 2. リモートの変更をマージ
git pull origin main
# 3. コンフリクトがあれば解決してから通常のプッシュ
git push origin main
# どうしても必要な場合は --force-with-lease を使用
git push --force-with-lease origin main
3. コミットメッセージの修正
問題:コミット後にメッセージの間違いに気づく
# 最新のコミットメッセージを修正(まだpushしていない場合)
git commit --amend -m "正しいコミットメッセージ"
# エディタでメッセージを編集
git commit --amend
4. 間違ったファイルをコミットした場合
# 特定のファイルを最新のコミットから除外
git reset HEAD~1 -- unwanted-file.txt
git commit --amend --no-edit
# または、ファイルを完全に履歴から削除
git rm --cached unwanted-file.txt
git commit -m "不要なファイルを除外"
効果的なブランチ戦略
実際のプロジェクトでは、以下のようなブランチ運用を推奨しています:
flowchart TD
A[main<br/>本番環境] --> B[develop<br/>開発統合]
B --> C[feature/login<br/>ログイン機能]
B --> D[feature/payment<br/>決済機能]
B --> E[hotfix/bug-001<br/>緊急修正]
C --> B
D --> B
E --> A
B --> A# 機能開発ブランチの作成
git checkout -b feature/contact-form
# 開発完了後、developブランチにマージ
git checkout develop
git merge feature/contact-form
# 不要になったブランチを削除
git branch -d feature/contact-form
チーム開発での実践的な使い方
プルリクエスト(Pull Request)の活用
GitHubでのチーム開発では、直接mainブランチにプッシュするのではなく、プルリクエストを通じてコードレビューを行います:
# 1. 機能ブランチで開発
git checkout -b feature/responsive-design
# ... 開発作業 ...
git add .
git commit -m "feat: レスポンシブデザインを実装"
git push origin feature/responsive-design
# 2. GitHubでプルリクエストを作成
# 3. チームメンバーによるレビュー
# 4. 承認後、mainブランチにマージ
コードレビューでよくチェックする点
- セキュリティ上の問題(SQLインジェクション対策など)
- パフォーマンスへの影響
- コーディング規約の遵守
- テストの網羅性
便利なGitコマンド集
状況確認系
# 現在の状況を確認
git status
# 変更内容の詳細を確認
git diff
# コミット履歴を確認
git log --oneline
# ブランチ一覧
git branch -a
作業取り消し系
# ワーキングディレクトリの変更を破棄
git checkout -- filename.txt
# ステージした変更を取り消し
git reset HEAD filename.txt
# 最新のコミットを取り消し(変更内容は保持)
git reset --soft HEAD~1
履歴確認系
# 特定のファイルの変更履歴
git log -p filename.txt
# 誰がどの行を変更したか
git blame filename.txt
# 特定のコミットの内容を確認
git show [コミットハッシュ]
まとめと次のステップ
Gitを導入することで、以下のような大きな変化を実感していただけるはずです:
- 開発効率の向上:変更履歴が明確になり、問題発生時の原因特定が迅速に
- チーム連携の改善:複数人での同時開発がスムーズに
- 品質の向上:コードレビューフローの確立により、バグの早期発見が可能
- リスク軽減:重要な変更の取り消しや、機密情報漏洩の防止
実際に、当社でGitを導入したクライアント様の多くから「開発スピードが上がった」「チーム内のコミュニケーションが改善された」といった声をいただいています。
今すぐ始められるアクション
以下のチェックリストに従って、段階的にGitを導入してください:
Gitの導入や運用でお困りのことがあれば、ぜひFivenine Designまでご相談ください。20年以上のWeb開発経験を活かし、お客様のプロジェクトに最適なバージョン管理体制の構築をお手伝いいたします。