git-workflow

Git ワークフローの標準

このドキュメントでは、コミットメッセージの形式、ブランチ管理戦略、ワークフロー、マージ戦略など、プロジェクトにおける Git の使用標準を定めています。これらの標準に従うことで、共同作業の効率が向上し、変更の追跡が可能になり、自動化がサポートされ、競合を減らせます。

コミットメッセージの標準

このプロジェクトでは、Conventional Commits の仕様に従います。

<type>(<scope>): <subject>

<body>

<footer>

タイプのリファレンス

タイプ	説明	例
feat	新機能	feat(user): add user export functionality
fix	バグ修正	fix(login): fix captcha not refreshing
docs	ドキュメントの更新	docs(api): update API documentation
refactor	リファクタリング	refactor(utils): refactor utility functions
perf	パフォーマンスの改善	perf(list): optimize list performance
test	テスト関連	test(user): add unit tests
chore	その他の変更	chore: update dependency versions

件名のルール

• 動詞で始めます：add、fix、update、remove、optimize
• 50 文字以内にします
• 末尾にピリオドを付けません

詳細な規約と例については、references/commit-conventions.md を参照してください。

ブランチ管理戦略

ブランチの種類

ブランチの種類	命名規則	説明	ライフサイクル
master	master	メインブランチ。リリース可能な状態	永続
develop	develop	開発ブランチ。最新の統合済みコード	永続
feature	feature/feature-name	機能ブランチ	完了後に削除
bugfix	bugfix/issue-description	バグ修正ブランチ	修正後に削除
hotfix	hotfix/issue-description	緊急修正ブランチ	修正後に削除
release	release/version-number	リリースブランチ	リリース後に削除

ブランチ名の例

feature/user-management          # User management feature
feature/123-add-export          # Issue-linked feature
bugfix/login-error              # Login error fix
hotfix/security-vulnerability   # Security vulnerability fix
release/v1.0.0                  # Version release

ブランチ保護ルール

master ブランチ：

• 直接のプッシュは禁止
• プルリクエスト経由でマージする必要があります
• CI チェックに合格する必要があります
• 少なくとも 1 人のコードレビュー承認が必要です

develop ブランチ：

• 直接のプッシュは制限されています
• プルリクエストによるマージを推奨します
• CI チェックに合格する必要があります

詳細なブランチ戦略とワークフローについては、references/branching-strategies.md を参照してください。

ワークフロー

日常的な開発ワークフロー

# 1. Sync latest code
git checkout develop
git pull origin develop

# 2. Create feature branch
git checkout -b feature/user-management

# 3. Develop and commit
git add .
git commit -m "feat(user): add user list page"

# 4. Push to remote
git push -u origin feature/user-management

# 5. Create Pull Request and request Code Review

# 6. Merge to develop (via PR)

# 7. Delete feature branch
git branch -d feature/user-management
git push origin -d feature/user-management

ホットフィックスのワークフロー

# 1. Create fix branch from master
git checkout master
git pull origin master
git checkout -b hotfix/critical-bug

# 2. Fix and commit
git add .
git commit -m "fix(auth): fix authentication bypass vulnerability"

# 3. Merge to master
git checkout master
git merge --no-ff hotfix/critical-bug
git tag -a v1.0.1 -m "hotfix: fix authentication bypass vulnerability"
git push origin master --tags

# 4. Sync to develop
git checkout develop
git merge --no-ff hotfix/critical-bug
git push origin develop

リリースワークフロー

# 1. Create release branch
git checkout develop
git checkout -b release/v1.0.0

# 2. Update version numbers and documentation

# 3. Commit version update
git add .
git commit -m "chore(release): prepare release v1.0.0"

# 4. Merge to master
git checkout master
git merge --no-ff release/v1.0.0
git tag -a v1.0.0 -m "release: v1.0.0 official release"
git push origin master --tags

# 5. Sync to develop
git checkout develop
git merge --no-ff release/v1.0.0
git push origin develop

マージ戦略

マージとリベース

項目	マージ	リベース
履歴	完全な履歴を保持	直線的な履歴
使用例	公開ブランチ	非公開ブランチ
推奨用途	メインブランチへのマージ	上流コードとの同期

推奨事項

• feature ブランチを develop に同期する場合：rebase を使用します
• feature ブランチを develop にマージする場合：merge --no-ff を使用します
• develop を master にマージする場合：merge --no-ff を使用します

# ✅ Recommended: Feature branch syncing develop
git checkout feature/user-management
git rebase develop

# ✅ Recommended: Merge feature branch to develop
git checkout develop
git merge --no-ff feature/user-management

# ❌ Not recommended: Rebase on public branch
git checkout develop
git rebase feature/xxx  # Dangerous operation

プロジェクト規約：ブランチの履歴を保持するため、feature ブランチをマージする際は --no-ff を使用します。

詳細なマージ戦略と手法については、references/merge-strategies.md を参照してください。

競合の解決

競合の特定

<<<<<<< HEAD
// Current branch code
const name = 'Alice'
=======
// Branch being merged
const name = 'Bob'
>>>>>>> feature/user-management

競合の解決

# 1. View conflicting files
git status

# 2. Manually edit files to resolve conflicts

# 3. Mark as resolved
git add <file>

# 4. Complete the merge
git commit  # merge conflict
# or
git rebase --continue  # rebase conflict

競合解決の戦略

# Keep current branch version
git checkout --ours <file>

# Keep incoming branch version
git checkout --theirs <file>

# Abort merge
git merge --abort
git rebase --abort

競合の防止

1. 定期的にコードを同期する - 毎日の作業開始前に最新のコードをプルします
2. 小さなコミット - 小さな変更を頻繁にコミットします
3. 機能をモジュール化する - 異なる機能は別々のファイルに実装します
4. コミュニケーション - 同じファイルを同時に変更しないようにします

競合の処理と高度な手法については、references/conflict-resolution.md を参照してください。

.gitignore の標準

基本ルール

# Ignore all .log files
*.log

# Ignore directories
node_modules/

# Ignore directory at root
/temp/

# Ignore files in all directories
**/.env

# Don't ignore specific files
!.gitkeep

よく使われる .gitignore

node_modules/
dist/
build/
.idea/
.vscode/
.env
.env.local
logs/
*.log
.DS_Store
Thumbs.db

詳細な .gitignore パターンとプロジェクト固有の設定については、references/gitignore-guide.md を参照してください。

タグ管理

セマンティックバージョニングを使用します。

MAJOR.MINOR.PATCH[-PRERELEASE]

バージョン変更のルール

• MAJOR：互換性のない API 変更（v1.0.0 → v2.0.0）
• MINOR：後方互換性のある新機能（v1.0.0 → v1.1.0）
• PATCH：後方互換性のあるバグ修正（v1.0.0 → v1.0.1）

タグ操作

# Create annotated tag (recommended)
git tag -a v1.0.0 -m "release: v1.0.0 official release"

# Push tags
git push origin v1.0.0
git push origin --tags

# View tags
git tag
git show v1.0.0

# Delete tag
git tag -d v1.0.0
git push origin :refs/tags/v1.0.0

チームコラボレーション標準

プルリクエスト標準

PR には以下を含める必要があります:

## Change Description


## Change Type
- [ ] New feature (feat)
- [ ] Bug fix (fix)
- [ ] Code refactoring (refactor)

## Testing Method


## Related Issue
Closes #xxx

## Checklist
- [ ] Code has been self-tested
- [ ] Documentation has been updated

コードレビュー標準

レビューの重点項目:

• コード品質: 明確で読みやすく、適切な命名、重複コードがない
• ロジックの正確性: ビジネスロジックが正しく、エッジケースが処理されている
• セキュリティ: セキュリティ上の脆弱性がなく、機密情報が保護されている
• パフォーマンス: 明らかなパフォーマンス問題がなく、リソースが適切に解放されている

詳細なコラボレーション標準とベストプラクティスについては、references/collaboration.md を参照してください。

よくある問題

直前のコミットを修正する

# Amend commit content (not yet pushed)
git add forgotten-file.ts
git commit --amend --no-edit

# Amend commit message
git commit --amend -m "new commit message"

プッシュが拒否された

# Pull then push
git pull origin master
git push origin master

# Use rebase for cleaner history
git pull --rebase origin master
git push origin master

以前のバージョンにロールバックする

# Reset to specific commit (discards subsequent commits)
git reset --hard abc123

# Create reverse commit (recommended, preserves history)
git revert abc123

現在の作業をスタッシュする

git stash save "work in progress"
git stash list
git stash pop

ファイルの変更履歴を表示する

git log -- <file>             # Commit history
git log -p -- <file>          # Detailed content
git blame <file>              # Per-line author

ベストプラクティスまとめ

コミット標準

✅ 推奨:

• Conventional Commits 仕様に従う
• 変更内容を説明する明確なコミットメッセージを書く
• 1 つの論理的な変更につき 1 コミット
• コミット前にコードチェックを実行する

❌ 禁止:

• 曖昧なコミットメッセージ
• 1 つのコミットに複数の無関係な変更を混ぜる
• 機密情報（パスワード、キー）のコミット
• main ブランチで直接開発する

ブランチ管理

✅ 推奨:

• 開発にはフィーチャーブランチを使用する
• main ブランチのコードを定期的に同期する
• フィーチャー完了後は速やかにブランチを削除する
• 履歴を保持するために --no-ff マージを使用する

❌ 禁止:

• main ブランチで直接開発する
• 長期間マージされないフィーチャーブランチ
• 標準に沿わないブランチ命名
• 公開ブランチでのリベース

コードレビュー

✅ 推奨:

• すべてのコードはプルリクエストを経由する
• マージ前に少なくとも 1 名のレビュアーの承認を得る
• 建設的なフィードバックを提供する

❌ 禁止:

• レビューなしでのマージ
• 自分のコードを自分でレビューする

追加リソース

参照ファイル

特定のトピックに関する詳細なガイダンス:

• references/commit-conventions.md - コミットメッセージの詳細な規約と例
• references/branching-strategies.md - 包括的なブランチ管理戦略
• references/merge-strategies.md - マージ、リベース、コンフリクト解決の戦略
• references/conflict-resolution.md - コンフリクト処理と防止の詳細
• references/advanced-usage.md - Git のパフォーマンス最適化、セキュリティ、サブモジュール、高度なテクニック
• references/collaboration.md - プルリクエストとコードレビューのガイドライン
• references/gitignore-guide.md - .gitignore パターンとプロジェクト固有の設定

サンプルファイル

examples/ 内の動作するサンプル:

• examples/commit-messages.txt - 良いコミットメッセージの例
• examples/workflow-commands.sh - よく使うワークフローコマンドのスニペット

まとめ

このドキュメントはプロジェクトの Git 標準を定義しています:

1. コミットメッセージ - Conventional Commits 仕様に従う
2. ブランチ管理 - master/develop/feature/bugfix/hotfix/release ブランチ戦略
3. ワークフロー - 日々の開発、ホットフィックス、リリースの標準プロセス
4. マージ戦略 - フィーチャーブランチの同期にはリベース、マージには merge --no-ff を使用
5. タグ管理 - セマンティックバージョニング、注釈付きタグ
6. コンフリクト解決 - 定期的な同期、小さなコミット、チーム内のコミュニケーション

これらの標準に従うことで、コラボレーションの効率が向上し、コード品質が確保され、バージョン管理が簡素化されます。