ブランチ名コミットメッセージにまよったら＆Git/GitBash チーム開発完全ガイド

🚀 Git/GitBash チーム開発完全ガイド

ローカル作業→GitHubコミットまでの完全手順

🔧 事前準備

必要なツール

• ✅ Git (インストール済み確認: git --version)

• ✅ GitBash (Windowsの場合)

• ✅ GitHubアカウント

• ✅ テキストエディタ (VS Code推奨)

⚙️ 初期設定

STEP 0: ユーザー情報の設定 (最初の1回だけ)

git config --global user.name "あなたの名前"

読み方: ギット・コンフィグ・グローバル・ユーザー・ネーム

意味: Gitに自分の名前を登録する

git config --global user.email "your.email@example.com"

読み方: ギット・コンフィグ・グローバル・ユーザー・イーメール

意味: Gitに自分のメールアドレスを登録する

git config --list

読み方: ギット・コンフィグ・リスト

意味: 設定内容を確認する

結果の見方:

user.name=Taro Yamada
user.email=taro@example.com
core.editor=vim
...

→ 自分の名前とメールが表示されればOK!

📦 STEP 1: リポジトリの準備

パターンA: 既存のGitHubリポジトリをクローンする場合

cd /c/Users/あなたのユーザー名/Documents

読み方: チェンジ・ディレクトリ

意味: 作業したいフォルダに移動する

git clone https://github.com/チーム名/リポジトリ名.git

読み方: ギット・クローン

意味: GitHubからプロジェクトをコピーしてくる

結果の見方:

Cloning into 'リポジトリ名'...
remote: Enumerating objects: 100, done.
remote: Counting objects: 100% (100/100), done.
remote: Compressing objects: 100% (80/80), done.
Receiving objects: 100% (100/100), 1.5 MiB | 2.3 MiB/s, done.

→ "done" が複数出たら成功!

cd リポジトリ名

意味: クローンしたフォルダの中に入る

パターンB: ローカルの既存プロジェクトをGitで管理開始する場合

cd /c/path/to/your/project

意味: プロジェクトフォルダに移動

git init

読み方: ギット・イニット (initialize の略)

意味: このフォルダをGitで管理開始する

結果の見方:

Initialized empty Git repository in /c/path/to/your/project/.git/

→ ".git/" フォルダが作成されればOK!

git remote add origin https://github.com/あなたのユーザー名/リポジトリ名.git

読み方: ギット・リモート・アッド・オリジン

意味: GitHubのリポジトリと紐付ける

🔄 STEP 2: ブランチの作成と切り替え

現在のブランチを確認

git branch

読み方: ギット・ブランチ

意味: ブランチ一覧を表示

結果の見方:

* main
  develop
  feature/login

→ * がついているのが現在のブランチ

新しいブランチを作成して切り替え

git checkout -b feature/新機能名

読み方: ギット・チェックアウト・マイナスビー

意味: 新しいブランチを作って、そこに移動する

結果の見方:

Switched to a new branch 'feature/新機能名'

→ "Switched to a new branch" なら成功!

ブランチ命名規則の例:

• feature/ログイン機能 - 新機能追加

• feature/user-authentication - ユーザー認証機能

• feature/api-integration - API連携

• feature/payment-system - 決済システム

• fix/バグ修正内容 - バグ修正

• fix/login-error - ログインエラー修正

• fix/memory-leak - メモリリーク修正

• bugfix/issue-123 - Issue番号付きバグ修正

• hotfix/緊急修正 - 緊急の修正

• hotfix/security-patch - セキュリティパッチ

• hotfix/critical-bug - クリティカルなバグ修正

• refactor/リファクタ内容 - コード整理

• refactor/database-structure - DB構造の見直し

• refactor/code-cleanup - コードクリーンアップ

• docs/update-readme - ドキュメント更新

• docs/api-documentation - APIドキュメント追加

• test/unit-tests - テスト追加

• test/integration-tests - 統合テスト追加

• chore/update-dependencies - 依存関係更新

• chore/setup-ci - CI/CD設定

• style/format-code - コードフォーマット

• perf/optimize-query - パフォーマンス改善

• release/v1.0.0 - リリース準備

• develop - 開発統合ブランチ

• staging - ステージング環境用

命名のベストプラクティス: ✅ 小文字とハイフンを使用 ✅ 簡潔で意味が明確 ✅ Issue番号を含める（例: feature/issue-456-add-search） ❌ 日本語の使用は避ける（一部ツールで問題が起きる場合あり） ❌ スペースや特殊文字は使わない

💻 STEP 3: 作業する

この段階で、VS Codeなどでコードを編集します。 Pythonファイルを作成・編集したら、次のステップへ!

📸 STEP 4: 変更内容を確認・追加

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

git status

読み方: ギット・ステータス

意味: 今の状態を確認する

結果の見方:

On branch feature/新機能名
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   main.py

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        new_feature.py

色分けの意味:

• 🔴 赤色: まだステージングされていない変更

• 🟢 緑色: ステージング済みの変更

• ⚪ 灰色: 追跡されていない新規ファイル

変更の詳細を確認

git diff

読み方: ギット・ディフ (difference の略)

意味: 何が変更されたか詳しく表示

結果の見方:

diff --git a/main.py b/main.py
index 1234567..abcdefg 100644
--- a/main.py
+++ b/main.py
@@ -10,7 +10,7 @@ def hello():
-    print("Hello")
+    print("Hello, World!")

• - で始まる行(赤): 削除された行

• + で始まる行(緑): 追加された行

変更をステージングエリアに追加

git add ファイル名.py

読み方: ギット・アッド

意味: このファイルをコミット対象に含める

複数ファイルを一度に追加:

git add .

意味: すべての変更ファイルを追加

特定の拡張子のみ:

git add *.py

意味: すべての .py ファイルを追加

追加後の確認

git status

結果の見方:

On branch feature/新機能名
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   main.py
        new file:   new_feature.py

→ 🟢 緑色 になっていればステージング成功!

💾 STEP 5: コミット(保存)する

git commit -m "機能: ログイン機能を追加"

読み方: ギット・コミット・マイナスエム

意味: 変更内容を記録する(-m はメッセージの略)

コミットメッセージの書き方:

📝 基本フォーマット

[種類] 簡潔なタイトル（50文字以内）

詳細な説明（必要に応じて）
- 変更理由
- 影響範囲
- 関連Issue番号

🏷️ プレフィックス（種類）の例

プレフィックス 英語表記 使用場面 例 機能 feat 新機能追加 feat: ユーザー登録機能を追加 修正 fix バグ修正 fix: ログイン時のエラーを修正 改善 improve 機能改善 improve: 検索速度を50%向上 文書 docs ドキュメント docs: README にAPI仕様を追加 整形 style コード整形 style: PEP8に準拠するよう修正 リファクタ refactor コード整理 refactor: 重複コードを関数化 性能 perf パフォーマンス perf: データベースクエリを最適化 テスト test テスト追加 test: ログイン機能のテストを追加 ビルド build ビルド関連 build: Dockerfileを更新 CI ci CI/CD設定 ci: GitHub Actionsを追加 雑務 chore その他作業 chore: 依存パッケージを更新 差し戻し revert 変更を戻す revert: commit a1b2c3d を取り消し WIP wip 作業途中 wip: ログイン機能実装中

✅ 良いコミットメッセージの例

# 基本パターン
git commit -m "feat: ユーザー認証機能を追加"
git commit -m "fix: ログイン時の500エラーを修正"
git commit -m "docs: API仕様書を更新"

# 詳細付きパターン
git commit -m "feat: パスワードリセット機能を追加

- メール送信機能の実装
- トークン生成ロジックの追加
- パスワード変更画面の作成
Closes #123"

# Issue番号付き
git commit -m "fix: #456 決済処理のタイムアウトを修正"
git commit -m "feat: #789 商品検索機能を実装"

# 影響範囲を明記
git commit -m "refactor(auth): 認証ロジックを分離"
git commit -m "fix(payment): クレジットカード決済エラーを修正"
git commit -m "perf(database): インデックスを追加してクエリ速度向上"

# 英語での例
git commit -m "feat: add user authentication"
git commit -m "fix: resolve login timeout issue"
git commit -m "docs: update installation guide"
git commit -m "refactor: separate database connection logic"
git commit -m "test: add unit tests for payment module"
git commit -m "perf: optimize image loading performance"
git commit -m "chore: update dependencies to latest version"

# 複数行メッセージ（詳細を含む）
git commit -m "feat: add shopping cart functionality

- Implemented add to cart feature
- Added cart item management
- Created checkout process
- Fixes #234, Closes #235"

❌ 悪いコミットメッセージの例

# 避けるべき例
git commit -m "更新"           # ❌ 何を更新したか不明
git commit -m "修正"           # ❌ 何を修正したか不明
git commit -m "aaa"            # ❌ 意味不明
git commit -m "test"           # ❌ 何のテストか不明
git commit -m "いろいろ変更"    # ❌ 具体性がない
git commit -m "バグ直した"      # ❌ どのバグか不明
git commit -m "とりあえず保存"  # ❌ コミットの意味がない
git commit -m "WIP"            # ❌ 作業内容が不明（wip: 具体的な内容 とすべき）

📏 コミットメッセージのルール

1. 1行目は50文字以内

   • 簡潔に要点をまとめる

   • 命令形で書く（「追加する」ではなく「追加」）

2. 2行目は空行

   • 詳細説明を書く場合は1行目と2行目の間に空行

3. 3行目以降に詳細

   • 何を変更したか

   • なぜ変更したか

   • どう動作するか

4. Issue番号を含める

   • Fixes #123 - バグ修正の場合

   • Closes #456 - 機能実装の場合

   • Refs #789 - 参照する場合

🎯 コミットの粒度

# ✅ 良い例：機能ごとに分ける
git commit -m "feat: ユーザー登録フォームを追加"
git commit -m "feat: メール検証機能を実装"
git commit -m "test: ユーザー登録のテストを追加"

# ❌ 悪い例：全部まとめる
git commit -m "feat: ユーザー機能一式を追加"  # 大きすぎる

🌐 Conventional Commits（国際標準）

より厳密なルールに従いたい場合:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

例:

git commit -m "feat(auth): add JWT authentication

Implemented JWT-based authentication system
- Added token generation
- Added token validation middleware
- Updated user model

Breaking Change: Authentication header format changed
Closes #123"

結果の見方:

[feature/新機能名 a1b2c3d] 機能: ログイン機能を追加
 2 files changed, 45 insertions(+), 3 deletions(-)
 create mode 100644 new_feature.py

• 2 files changed: 2ファイルが変更された

• 45 insertions(+): 45行追加された

• 3 deletions(-): 3行削除された

📤 STEP 6: GitHubにプッシュ(アップロード)

最新の状態を取得(重要!)

git pull origin main

読み方: ギット・プル・オリジン・メイン

意味: GitHubの最新状態をダウンロードして統合

結果の見方:

Already up to date.

→ これなら問題なし!

Updating 1234567..abcdefg
Fast-forward
 some_file.py | 10 ++++++++++
 1 file changed, 10 insertions(+)

→ 他のメンバーの変更が取り込まれた

自分の変更をアップロード

git push origin feature/新機能名

読み方: ギット・プッシュ・オリジン

意味: 自分の変更をGitHubにアップロード

初回プッシュの場合:

git push -u origin feature/新機能名

意味: -u でこのブランチを追跡設定する(次回から git push だけでOK)

結果の見方:

Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 456 bytes | 456.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To https://github.com/team/repo.git
   1234567..abcdefg  feature/新機能名 -> feature/新機能名

→ 最後に -> で表示されれば成功!

🔀 STEP 7: プルリクエスト(PR)作成

GitHubウェブサイトでの操作

1. GitHubにアクセス

   • ブラウザで https://github.com/チーム名/リポジトリ名 を開く

2. プルリクエストを作成

   • 黄色いバーの「Compare & pull request」をクリック

   • または「Pull requests」タブ → 「New pull request」

3. 内容を記入

   1. タイトル: [機能追加] ユーザーログイン機能 ## 変更内容 - ログインフォームの追加 - 認証ロジックの実装 - テストケースの追加 ## 確認事項 - [ ] テストが通ることを確認 - [ ] コードレビュー依頼

4. レビュアーを指定

   • チームメンバーを Reviewers に追加

5. Create pull request ボタンをクリック

📊 日常的な作業フロー(完全版)

# 1. 最新の状態に更新
git checkout main                    # メインブランチに移動
git pull origin main                 # 最新を取得

# 2. 作業用ブランチを作成
git checkout -b feature/新機能名     # 新ブランチ作成

# 3. コードを編集(VS Codeなど)

# 4. 変更を確認
git status                           # 状態確認
git diff                             # 変更内容確認

# 5. 変更を追加
git add .                            # 全ファイル追加

# 6. コミット
git commit -m "機能: ○○を追加"      # 変更を記録

# 7. プッシュ
git push -u origin feature/新機能名  # GitHubにアップロード

# 8. GitHubでPR作成

🎯 よく使うコマンド一覧表

コマンド 読み方 意味 いつ使う? git status ステータス 現在の状態確認 こまめに確認! git log ログ コミット履歴表示 履歴を見たい時 git log --oneline ログ・ワンライン 履歴を1行で表示 簡潔に見たい時 git branch ブランチ ブランチ一覧 今どこ?を確認 git checkout ブランチ名 チェックアウト ブランチ移動 作業場所を変える git checkout -b 新ブランチ名 チェックアウト -b ブランチ作成+移動 新機能開発開始 git pull origin ブランチ名 プル 最新取得 作業前に必須! git push origin ブランチ名 プッシュ アップロード 作業後に必須! git stash スタッシュ 変更を一時保存 急な作業切り替え git stash pop スタッシュ・ポップ 保存した変更を戻す 作業に戻る時

🔍 コマンド実行結果の読み方

git status の読み方

On branch feature/login              # ← 今いるブランチ
Your branch is up to date with 'origin/feature/login'.  # ← GitHubと同期済み

Changes to be committed:             # ← コミット準備完了(緑)
  (use "git restore --staged <file>..." to unstage)
        modified:   login.py

Changes not staged for commit:      # ← まだ準備していない(赤)
  (use "git add <file>..." to update what will be committed)
        modified:   main.py

Untracked files:                    # ← 新規ファイル(赤)
  (use "git add <file>..." to include in what will be committed)
        new_file.py

git log の読み方

commit a1b2c3d4e5f6g7h8i9j0  # ← コミットID(ハッシュ値)
Author: Taro Yamada <taro@example.com>  # ← 誰が
Date:   Thu Oct 9 14:30:00 2025 +0900   # ← いつ

    機能: ログイン機能を追加  # ← 何をしたか

エラーメッセージの読み方

❌ コンフリクト(衝突)が発生

Auto-merging main.py
CONFLICT (content): Merge conflict in main.py
Automatic merge failed; fix conflicts and then commit the result.

意味: 同じファイルの同じ場所を複数人が編集した

対処法:

1. ファイルを開くと以下のような表示がある

<<<<<<< HEAD
your_code = "あなたのコード"
=======
their_code = "相手のコード"
>>>>>>> branch_name

1. どちらを採用するか選んで、マーカーを削除

2. git add ファイル名

3. git commit -m "コンフリクト解決"

❌ プッシュが拒否された

 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'https://github.com/...'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes

意味: GitHubに自分より新しい変更がある

対処法:

git pull origin main  # 最新を取得
git push origin main  # 再度プッシュ

🆘 トラブルシューティング

Q1: 間違えてコミットしてしまった!

直前のコミットを取り消し:

git reset --soft HEAD~1

意味: コミットを取り消すが、変更内容は残す

完全に取り消し(⚠️注意):

git reset --hard HEAD~1

意味: コミットも変更内容も完全削除

Q2: 間違えてmainブランチで作業してしまった!

git stash                        # 変更を一時保存
git checkout -b feature/新機能   # 新ブランチ作成
git stash pop                    # 変更を戻す

Q3: ブランチ名を間違えた!

git branch -m 古いブランチ名 新しいブランチ名

Q4: .gitignore を後から追加したい

# .gitignore ファイルを作成・編集
echo "*.pyc" >> .gitignore
echo "__pycache__/" >> .gitignore
echo ".env" >> .gitignore

# キャッシュをクリア
git rm -r --cached .
git add .
git commit -m "gitignoreを追加"

📝 Python開発でよく使う .gitignore

# Python
*.pyc
__pycache__/
*.py[cod]
*$py.class
*.so
.Python
env/
venv/
ENV/
build/
dist/
*.egg-info/

# IDE
.vscode/
.idea/
*.swp

# 環境変数
.env
.env.local

# OS
.DS_Store
Thumbs.db

🎓 チーム開発のベストプラクティス

✅ DO (推奨)

• ✅ 作業前に必ず git pull で最新化

• ✅ 1機能1ブランチの原則

• ✅ こまめにコミット(1日最低1回)

• ✅ わかりやすいコミットメッセージ

• ✅ プッシュ前にテストを実行

• ✅ コードレビューを受ける

❌ DON'T (非推奨)

• ❌ mainブランチに直接コミット

• ❌ 大量の変更を1コミットにまとめる

• ❌ 意味不明なコミットメッセージ

• ❌ 他人のブランチを勝手に変更

• ❌ プッシュせずに長期間ローカルに溜める

• ❌ コンフリクトを放置

🚀 次のステップ

このガイドをマスターしたら:

1. ✅ Gitの内部構造を学ぶ

2. ✅ リベース(git rebase)を学ぶ

3. ✅ チェリーピック(git cherry-pick)を学ぶ

4. ✅ Git Flowを理解する

5. ✅ CI/CDツールと連携する

📚 参考リンク

• Git公式ドキュメント

• GitHub Docs

• Gitコマンドチートシート

🎉 これでGit/GitBashの基本はバッチリです!

困ったときはこのガイドを見返してくださいね。 チーム開発、頑張ってください! 💪