Skip to main content
Verdent for VS Code integrates seamlessly with Git and other version control systems, enabling natural language version control operations, automated commit message generation, and intelligent branch management. This guide shows you how to leverage Verdent’s Git integration for efficient version control workflows.

​
Creating Meaningful Commit Messages

Suppose you’ve made changes and want Verdent to generate a descriptive commit message.
1

Request commit with generated message

Stage all changes and create a commit with an appropriate message
Verdent analyzes your changes using git diff.
2

Verdent analyzes changes

Verdent examines:
  • Files modified and their purpose
  • Nature of changes (new feature, bug fix, refactoring)
  • Scope of impact
  • Related functionality
3

Generates descriptive commit message

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"
Message follows conventional commit format and describes what changed.
4

Commit is created

Changes are committed with the generated message. You can review the commit:
git log -1
Tips:
  • Verdent follows conventional commit formats (feat, fix, refactor, docs, etc.)
  • Commit messages focus on “what” and “why”, not “how”
  • You can customize commit message format in User Rules or Project Rules
  • Request specific commit message styles: “Create a commit with a detailed multi-line message”

​
Customizing Commit Message Formats

Suppose you want Verdent to follow your team’s specific commit message conventions.
  • User Rules (Global)
  • Project Rules
  • Inline Instructions
Define commit message preferences in user_rules.md for all projects:
# user_rules.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 <email@example.com>
Verdent follows these rules globally.
Tips:
  • User Rules apply globally across all projects
  • Project Rules (AGENTS.md) override User Rules for specific projects
  • Inline instructions override both for one-time needs
  • Conventional Commits format is recommended for consistency

​
Creating Pull Requests

Suppose you want Verdent to create a comprehensive pull request.
1

Ensure changes are committed

Make sure all my changes are committed
Verdent checks git status and commits any uncommitted changes.
2

Push branch to remote

Push this branch to origin
Verdent pushes:
git push origin feature/user-notifications
3

Request PR creation

Create a pull request for this feature
Verdent uses gh CLI to create PR.
4

Verdent generates PR description

Verdent analyzes commits and changes to generate:Title: Add user notification systemBody:
## 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
The PR is created with a comprehensive description.
Tips:
  • Verdent analyzes all commits in the branch to generate PR description
  • Request specific PR formats: “Create a PR with detailed test plan”
  • Include screenshots: “Add this screenshot to the PR description”
  • You can refine PR description before creation: “Update the PR to mention the breaking change”

​
Resolving Merge Conflicts

Suppose you encounter merge conflicts and need Verdent’s help resolving them.
1

Attempt merge

Merge main into this feature branch
Merge conflict occurs:
Auto-merging src/auth.ts
CONFLICT (content): Merge conflict in src/auth.ts
2

Request conflict resolution

Help me resolve the merge conflict in src/auth.ts
Verdent reads the conflict markers.
3

Verdent analyzes both versions

Verdent examines:
  • Current branch changes (HEAD)
  • Incoming changes (main branch)
  • Context around conflicts
  • Intent of both changes
4

Verdent proposes resolution

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 resolves the conflict by integrating both changes intelligently.
5

Mark conflict as resolved

git add src/auth.ts
git commit -m "Merge main into feature/jwt-auth, resolved conflicts"
The conflict is resolved and the merge is complete.
Tips:
  • Verdent understands code context to resolve conflicts intelligently
  • Always review conflict resolutions before committing
  • For complex conflicts, ask Verdent to explain both versions first
  • Test thoroughly after resolving conflicts
Verdent analyzes merge conflicts by understanding both branches’ intent, suggesting resolutions that preserve functionality from both sides.

​
Managing Branches and Tags

Suppose you need to manage branches and create release tags.
  • Branch Operations
  • Merging
  • Tagging Releases
Create and switch branches:
Create a new branch called feature/user-notifications
Verdent executes:
git checkout -b feature/user-notifications
Tips:
  • Use descriptive branch names: feature/user-auth, fix/cart-bug, refactor/api-layer
  • Always pull latest changes before merging
  • Use annotated tags for releases (they include metadata)
  • Follow semantic versioning: v1.2.3 (major.minor.patch)
Consistent branch naming conventions help Verdent understand your workflow—define patterns in AGENTS.md for automatic compliance.

​
Frequently Asked Questions

No. Verdent only creates commits when you explicitly request them. You maintain full control over when changes are committed. Simply ask “Stage all changes and create a commit” when you’re ready.
Yes. You can ask Verdent to revise the commit message before it’s created. Say “Update the commit message to mention the breaking change” or “Make that commit message more concise.” Verdent will regenerate the message based on your feedback.
Yes. Verdent uses standard Git commands, so it works with any Git repository regardless of hosting platform. For creating pull requests, Verdent uses the gh CLI which requires GitHub, but all other Git operations work universally.
No. Verdent only pushes to remote repositories when you explicitly request it. All Git operations (commit, push, merge, rebase) require your explicit instruction for safety.
Verdent can resolve most text-based merge conflicts by understanding code context and intent. Binary file conflicts or very complex multi-way conflicts may require manual intervention. Always review Verdent’s conflict resolution before committing.

​
See Also

Multi-Step Task Examples

Complex multi-step workflows and task management

Writing New Code

Creating new features and components with Verdent