GitHub連携ガイド
Gitを活用したプロフェッショナルな開発ワークフロー
目次
1. GitHub連携のメリット
なぜGitHub連携が推奨されるのか
- 変更履歴の完全な記録 - いつ、誰が、何を変更したかがすべて記録される
- 安全なロールバック - 問題が発生しても、過去の安定版にすぐ戻せる
- 複数人での同時開発 - チームメンバーが並行して作業できる
- コードレビュー - プルリクエストで品質を担保
- 自動デプロイ - プッシュするだけで本番環境に反映
- ドキュメント管理 - README、Wiki、Issuesで情報共有
このガイドの対象者:
- Gitの基本操作ができる方
- GitHubアカウントを持っている方
- ターミナル(コマンドライン)の操作経験がある方
2. 初期セットアップ
ステップ1: Gitのインストール
Gitがインストールされているか確認:
git --version
インストールされていない場合:
- Windows: https://git-scm.com/ からインストーラーをダウンロード
- Mac: Homebrewで
brew install git - Linux:
sudo apt-get install git(Ubuntu/Debian)
ステップ2: Gitの初期設定
ユーザー情報を設定:
git config --global user.name "あなたの名前" git config --global user.email "your-email@example.com"
ステップ3: SSH鍵の生成と登録
SSH鍵を生成(既に持っている場合はスキップ):
ssh-keygen -t ed25519 -C "your-email@example.com" # Enterを3回押して、デフォルト設定で生成
公開鍵をコピー:
# Mac/Linux cat ~/.ssh/id_ed25519.pub # Windows (Git Bash) cat ~/.ssh/id_ed25519.pub | clip
GitHubに登録:
- GitHub → Settings → SSH and GPG keys
- 「New SSH key」をクリック
- Titleに任意の名前、Keyにコピーした公開鍵を貼り付け
- 「Add SSH key」をクリック
ステップ4: リポジトリのクローン
AsamiWorksから提供されたリポジトリをクローン:
git clone git@github.com:asamiworks/your-project.git cd your-project
3. 開発ワークフロー
日常的な開発フローを説明します。
基本的なワークフロー
- 最新の変更を取得
git pull origin main
- 作業ブランチを作成
git checkout -b feature/new-feature # ブランチ名の例: feature/add-contact-form, fix/header-bug
- ファイルを編集
お好きなエディタで編集してください
- 変更をステージング
git add . # すべてのファイル git add path/to/file.tsx # 特定のファイル
- コミット
git commit -m "feat: お問い合わせフォームを追加" # コミットメッセージの例: # feat: 新機能追加 # fix: バグ修正 # docs: ドキュメント更新 # style: スタイル変更 # refactor: リファクタリング # test: テスト追加 # chore: ビルド・設定変更
- リモートにプッシュ
git push origin feature/new-feature
- プルリクエストを作成
GitHubでプルリクエストを作成し、レビューを依頼
- マージ後、ブランチを削除
git checkout main git pull origin main git branch -d feature/new-feature # ローカルブランチ削除
変更を確認するコマンド
git status # 変更されたファイルを確認 git diff # 差分を確認 git log # コミット履歴を確認 git log --oneline # 簡潔な履歴表示 git log --graph --all # ブランチツリー表示
4. ブランチ戦略
推奨ブランチ戦略: Git Flow(簡易版)
| ブランチ名 | 用途 | 作成元 |
|---|---|---|
main | 本番環境にデプロイされる安定版 | - |
develop | 開発用の統合ブランチ | main |
feature/* | 新機能開発 | develop |
fix/* | バグ修正 | develop |
hotfix/* | 緊急バグ修正(本番環境) | main |
ブランチ作成例
# 新機能開発 git checkout develop git checkout -b feature/add-payment-system # バグ修正 git checkout develop git checkout -b fix/contact-form-validation # 緊急修正(本番環境) git checkout main git checkout -b hotfix/security-patch
ブランチ命名規則:
- 小文字で記述
- 単語はハイフンで区切る
- 簡潔で内容がわかる名前にする
- 例:
feature/add-user-auth,fix/header-responsive
5. CI/CD連携
GitHub Actionsを使った自動デプロイの設定方法を説明します。
Vercel連携(Next.js推奨)
ステップ1: Vercelアカウント連携
- VercelにGitHubアカウントでログイン
- 「New Project」をクリック
- GitHubリポジトリを選択
- フレームワーク(Next.js等)を自動検出
- 「Deploy」をクリック
これだけで、mainブランチへのプッシュで自動デプロイされます。
Netlify連携(静的サイト向け)
自動デプロイ設定
- NetlifyにGitHubアカウントでログイン
- 「New site from Git」をクリック
- GitHubリポジトリを選択
- ビルドコマンドと公開ディレクトリを設定
- 「Deploy site」をクリック
GitHub Actions(カスタムワークフロー)
.github/workflows/deploy.ymlの例
name: Deploy to Production
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup Node.js
uses: actions/setup-node@v3
with:
node-version: '18'
- name: Install dependencies
run: npm ci
- name: Build
run: npm run build
- name: Deploy to server
uses: easingthemes/ssh-deploy@main
with:
SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
REMOTE_HOST: ${{ secrets.REMOTE_HOST }}
REMOTE_USER: ${{ secrets.REMOTE_USER }}
SOURCE: "dist/"
TARGET: "/var/www/html/"6. チーム開発
プルリクエストの作成
- 作業ブランチをプッシュ
- GitHubリポジトリページで「Pull request」をクリック
- タイトルと説明を記入:
- 何を変更したか
- なぜ変更したか
- 動作確認方法
- スクリーンショット(必要に応じて)
- レビュワーを指定
- 「Create pull request」をクリック
コードレビューのポイント
- 建設的なフィードバック - 批判ではなく提案を
- 具体的なコメント - 「ここを直して」ではなく「〇〇の理由で△△にした方が良いです」
- 迅速なレスポンス - 24時間以内にはレビュー
- 小さな変更は承認 - 完璧を求めすぎない
コンフリクト(競合)の解決
コンフリクトが発生した場合
# 最新のmainブランチを取得 git checkout main git pull origin main # 作業ブランチに移動してマージ git checkout feature/your-branch git merge main # コンフリクトを解消(エディタで編集) # <<<<<<<, =======, >>>>>>> のマーカーを削除し、正しいコードを残す # 解消後、コミット git add . git commit -m "fix: mainとのコンフリクトを解消" git push origin feature/your-branch
7. トラブルシューティング
🔴 Permission denied (publickey)
原因: SSH鍵が正しく設定されていない
解決方法:
# SSH接続をテスト ssh -T git@github.com # 正しく設定されていれば以下のメッセージが表示される: # Hi username! You've successfully authenticated... # エラーの場合、SSH鍵を再設定
🔴 間違えてコミットしてしまった
プッシュ前なら:
# 直前のコミットを取り消し(変更は保持) git reset --soft HEAD~1 # コミットもファイル変更も取り消し git reset --hard HEAD~1
プッシュ後なら:
# 特定のコミットを打ち消す新しいコミットを作成 git revert <commit-hash> git push origin <branch-name>
🔴 .gitignoreが効かない
原因: 既にGit管理下にあるファイルは.gitignoreで除外できない
解決方法:
# キャッシュを削除してから再追加 git rm -r --cached . git add . git commit -m "fix: .gitignoreを適用"
🔴 ブランチを間違えて作業してしまった
# 変更を一時保存 git stash # 正しいブランチに移動 git checkout correct-branch # 変更を適用 git stash pop
8. よくある質問
Q. GitとGitHubの違いは何ですか?
Git は、バージョン管理システム(ソフトウェア)です。GitHub は、Gitリポジトリをホスティングするクラウドサービスです。GitはローカルPCで動作し、GitHubはオンラインでリポジトリを共有・管理します。
Q. コミットメッセージは日本語でも良いですか?
はい、問題ありません。ただし、国際的なプロジェクトでは英語が推奨されます。チーム内で統一しましょう。
Q. どれくらいの頻度でコミットすべきですか?
1つの機能や修正が完了したら、その都度コミットするのが理想です。「動作する状態」ごとにコミットし、「意味のある単位」で分けることを心がけてください。1日の終わりにまとめてコミットするのは避けましょう。
Q. リポジトリは公開すべきですか?非公開すべきですか?
企業のWebサイトや機密情報を含む場合は非公開(Private)リポジトリを使用してください。オープンソースプロジェクトやポートフォリオとして公開したい場合は公開(Public)リポジトリを選択します。
Q. 機密情報(APIキー等)を誤ってコミットしてしまいました
以下の手順で対処してください:
- すぐにAPIキーを無効化・再発行
- git-filter-repoやBFG Repo-Cleanerで履歴から削除
- .gitignoreに追加して再発防止
- 環境変数やシークレット管理サービスを使用
※公開リポジトリの場合、履歴を削除しても既にクロールされている可能性があります。
Q. GitHubのIssuesやProjectsも使った方が良いですか?
チーム開発の場合は積極的に活用することをおすすめします。Issuesでタスク管理、Projectsでカンバンボード、Wikiでドキュメント管理ができます。個人開発でも、TODO管理として便利です。
GitHub連携サポート
リポジトリのセットアップや、CI/CD環境の構築サポートも承っております。 お気軽にご相談ください。