# バージョン管理連携 (/ja/docs/verdent-for-vscode/common-workflows/version-control)
> Git やその他のバージョン管理システムとの連携
Verdent for VS Code は Git やその他のバージョン管理システムとシームレスに連携し、自然言語によるバージョン管理操作、コミットメッセージの自動生成、インテリジェントなブランチ管理を実現します。このガイドでは、効率的なバージョン管理ワークフローのために Verdent の Git 連携を活用する方法を説明します。
***
## 意味のあるコミットメッセージを作成する [#意味のあるコミットメッセージを作成する]
変更を加え、説明的なコミットメッセージを Verdent に生成してもらいたい場合を考えます。
```
Stage all changes and create a commit with an appropriate message
```
Verdent は git diff を使って変更を分析します。
Verdent は次の点を確認します。
* 変更されたファイルとその目的
* 変更の性質（新機能、バグ修正、リファクタリング）
* 影響範囲
* 関連する機能
```bash
git commit -m "feat: add user profile image upload with S3 integration
- Add file upload endpoint to user API
- Integrate AWS S3 for image storage
- Update user model with profileImage field
- Add frontend image upload component with preview"
```
メッセージは Conventional Commits 形式に従い、何が変更されたかを記述します。
変更は生成されたメッセージでコミットされます。コミットを確認できます。
```bash
git log -1
```
**ヒント:**
* Verdent は Conventional Commits 形式（feat、fix、refactor、docs など）に従います
* コミットメッセージは「どのように」ではなく「何を」「なぜ」に焦点を当てます
* コミットメッセージの形式は User Rules や Project Rules でカスタマイズできます
* 特定のコミットメッセージスタイルをリクエストできます。例:「詳細な複数行メッセージでコミットを作成して」
***
## コミットメッセージ形式をカスタマイズする [#コミットメッセージ形式をカスタマイズする]
チーム固有のコミットメッセージ規約に Verdent を従わせたい場合を考えます。
すべてのプロジェクトに適用するコミットメッセージの設定を `VERDENT.md` で定義します。
```markdown
# VERDENT.md
## Git Commit Messages
When generating commit messages:
- Always include ticket number in format: [PROJ-123]
- Use present tense verbs
- Maximum 50 characters for first line
- Include detailed explanation in body
- Add "Co-authored-by" for pair programming sessions
Example format:
[PROJ-123] Add user authentication feature
Detailed explanation of changes...
Co-authored-by: Team Member
```
Verdent はこれらのルールをグローバルに適用します。
プロジェクト固有のコミット規約を `AGENTS.md` で定義します。
```markdown
# AGENTS.md
## Git Commit Conventions
For this project, use conventional commits with these scopes:
- feat(api): API changes
- feat(ui): Frontend changes
- fix(auth): Authentication fixes
- docs(readme): Documentation updates
Always reference GitHub issue: "Fixes #123" or "Relates to #456"
```
ルールはこのプロジェクトにのみ適用されます。
一度限りの指示を直接与えます。
```
Create a commit with message format: "[TICKET-NUMBER] description" including reference to issue #42
```
Verdent は次を生成します。
```bash
git commit -m "[PROJ-42] Add search functionality
Relates to #42"
```
**ヒント:**
* User Rules はすべてのプロジェクトにグローバルに適用されます
* Project Rules（AGENTS.md）は特定のプロジェクトで User Rules を上書きします
* インライン指示は一度限りのニーズのために両者を上書きします
* 一貫性のために Conventional Commits 形式を推奨します
***
## プルリクエストを作成する [#プルリクエストを作成する]
包括的なプルリクエストを Verdent に作成してもらいたい場合を考えます。
```
Make sure all my changes are committed
```
Verdent は git status を確認し、未コミットの変更があればコミットします。
```
Push this branch to origin
```
Verdent は次をプッシュします。
```bash
git push origin feature/user-notifications
```
```
Create a pull request for this feature
```
Verdent は `gh` CLI を使って PR を作成します。
Verdent はコミットと変更を分析し、次を生成します。
**タイトル:** Add user notification system
**本文:**
```markdown
## Summary
- Implements real-time user notifications
- Adds WebSocket support for instant delivery
- Includes email fallback for offline users
- Comprehensive test coverage
## Test Plan
- [ ] Test real-time notifications in browser
- [ ] Verify email fallback for offline users
- [ ] Check notification persistence across sessions
- [ ] Test with multiple concurrent users
## Changes
- Added NotificationService with WebSocket integration
- Created notification UI components
- Integrated SendGrid for email notifications
- Added notification preferences to user settings
```
PR は包括的な説明とともに作成されます。
**ヒント:**
* Verdent はブランチ内のすべてのコミットを分析して PR の説明を生成します
* 特定の PR 形式をリクエストできます。例:「詳細なテストプラン付きで PR を作成して」
* スクリーンショットを含められます。例:「このスクリーンショットを PR の説明に追加して」
* 作成前に PR の説明を調整できます。例:「破壊的変更について触れるよう PR を更新して」
***
## マージコンフリクトを解決する [#マージコンフリクトを解決する]
マージコンフリクトに遭遇し、その解決に Verdent の助けが必要な場合を考えます。
```
Merge main into this feature branch
```
マージコンフリクトが発生します。
```bash
Auto-merging src/auth.ts
CONFLICT (content): Merge conflict in src/auth.ts
```
```
Help me resolve the merge conflict in src/auth.ts
```
Verdent はコンフリクトマーカーを読み取ります。
Verdent は次を確認します。
* 現在のブランチの変更（HEAD）
* 受信側の変更（main ブランチ）
* コンフリクト周辺のコンテキスト
* 両方の変更の意図
```
The conflict is between your JWT implementation and the main branch's session-based auth. I'll merge both approaches to support both authentication methods.
```
Verdent は両方の変更をインテリジェントに統合してコンフリクトを解決します。
```bash
git add src/auth.ts
git commit -m "Merge main into feature/jwt-auth, resolved conflicts"
```
コンフリクトが解決され、マージが完了します。
**ヒント:**
* Verdent はコードのコンテキストを理解してコンフリクトをインテリジェントに解決します
* コミット前には必ずコンフリクトの解決内容を確認してください
* 複雑なコンフリクトの場合は、まず Verdent に両方のバージョンを説明してもらいましょう
* コンフリクト解決後は十分にテストしてください
Verdent は両方のブランチの意図を理解してマージコンフリクトを分析し、双方の機能を維持する解決策を提案します。
***
## ブランチとタグを管理する [#ブランチとタグを管理する]
ブランチを管理し、リリースタグを作成する必要がある場合を考えます。
**ブランチの作成と切り替え:**
```
Create a new branch called feature/user-notifications
```
Verdent は次を実行します。
```bash "Create New Branch"
git checkout -b feature/user-notifications
```
```bash "Switch to Existing Branch"
git checkout main
```
```bash "Create and Push Branch"
git checkout -b feature/payment-integration
git push -u origin feature/payment-integration
```
**フィーチャーブランチをマージする:**
```
Merge the feature/user-notifications branch into main
```
Verdent はマージワークフローを実行します。
```bash
git checkout main
git pull origin main
git merge feature/user-notifications
git push origin main
```
Verdent はマージ前に main が最新であることを確認します。
**注釈付きタグを作成する:**
```
Create an annotated tag for version 1.2.0 with release notes
```
Verdent は詳細なタグを作成します。
```bash
git tag -a v1.2.0 -m "Release 1.2.0
New Features:
- User notification system
- Email integration
- Real-time WebSocket support
Bug Fixes:
- Fixed authentication timeout issue
- Resolved cart calculation bug"
```
**タグをプッシュする:**
```
Push all tags to origin
```
Verdent は次をプッシュします。
```bash
git push origin --tags
```
**ヒント:**
* 説明的なブランチ名を使いましょう。例: `feature/user-auth`、`fix/cart-bug`、`refactor/api-layer`
* マージ前には必ず最新の変更を取り込んでください
* リリースには注釈付きタグを使いましょう（メタデータを含みます）
* セマンティックバージョニングに従いましょう。v1.2.3（major.minor.patch）
一貫したブランチ命名規約は Verdent がワークフローを理解する助けになります。AGENTS.md でパターンを定義すると自動的に準拠します。
***
## よくある質問 [#よくある質問]
いいえ。Verdent は明示的にリクエストした場合にのみコミットを作成します。いつ変更をコミットするかは完全にあなたが制御できます。準備ができたら「すべての変更をステージしてコミットを作成して」と頼むだけです。
はい。作成前に Verdent にコミットメッセージの修正を依頼できます。「破壊的変更について触れるようコミットメッセージを更新して」や「そのコミットメッセージをもっと簡潔にして」と伝えてください。Verdent はフィードバックに基づいてメッセージを再生成します。
はい。Verdent は標準的な Git コマンドを使うため、ホスティングプラットフォームに関係なくあらゆる Git リポジトリで動作します。プルリクエストの作成には Verdent が `gh` CLI を使用し、これには GitHub が必要ですが、その他の Git 操作はすべて汎用的に動作します。
いいえ。Verdent は明示的にリクエストした場合にのみリモートリポジトリにプッシュします。安全のため、すべての Git 操作（commit、push、merge、rebase）には明示的な指示が必要です。
Verdent はコードのコンテキストと意図を理解することで、ほとんどのテキストベースのマージコンフリクトを解決できます。バイナリファイルのコンフリクトや、非常に複雑な多方向のコンフリクトは手動での対応が必要になる場合があります。コミット前には必ず Verdent のコンフリクト解決内容を確認してください。
***
## 関連項目 [#関連項目]
複雑なマルチステップワークフローとタスク管理
Verdent で新機能やコンポーネントを作成する