Verdent Docs
Fluxos de trabalho comuns

Integração com controle de versão

Trabalhando com Git e outros sistemas de controle de versão

Verdent for VS Code integra-se perfeitamente com Git e outros sistemas de controle de versão, possibilitando operações de controle de versão em linguagem natural, geração automatizada de mensagens de commit e gerenciamento inteligente de branches. Este guia mostra como aproveitar a integração Git do Verdent para fluxos de trabalho de controle de versão eficientes.


Criando mensagens de commit significativas

Suponha que você fez alterações e quer que o Verdent gere uma mensagem de commit descritiva.

Solicite o commit com mensagem gerada

Stage all changes and create a commit with an appropriate message

Verdent analisa suas alterações usando git diff.

Verdent analisa as alterações

Verdent examina:

  • Arquivos modificados e seu propósito
  • Natureza das alterações (novo recurso, correção de bug, refatoração)
  • Escopo do impacto
  • Funcionalidade relacionada

Gera uma mensagem de commit descritiva

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"

A mensagem segue o formato de commit convencional e descreve o que mudou.

O commit é criado

As alterações são commitadas com a mensagem gerada. Você pode revisar o commit:

git log -1

Dicas:

  • Verdent segue formatos de commit convencionais (feat, fix, refactor, docs, etc.)
  • As mensagens de commit focam no "o quê" e no "porquê", não no "como"
  • Você pode personalizar o formato da mensagem de commit em User Rules ou Project Rules
  • Solicite estilos específicos de mensagem de commit: "Crie um commit com uma mensagem detalhada de múltiplas linhas"

Personalizando formatos de mensagem de commit

Suponha que você queira que o Verdent siga as convenções específicas de mensagem de commit da sua equipe.

Defina as preferências de mensagem de commit em VERDENT.md para todos os projetos:

# 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 <email@example.com>

Verdent segue essas regras globalmente.

Defina convenções de commit específicas do projeto em AGENTS.md:

# 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"

As regras se aplicam apenas a este projeto.

Forneça instruções pontuais diretamente:

Create a commit with message format: "[TICKET-NUMBER] description" including reference to issue #42

Verdent gera:

git commit -m "[PROJ-42] Add search functionality

Relates to #42"

Dicas:

  • As User Rules se aplicam globalmente a todos os projetos
  • As Project Rules (AGENTS.md) sobrepõem as User Rules para projetos específicos
  • As instruções inline sobrepõem ambas para necessidades pontuais
  • O formato Conventional Commits é recomendado para consistência

Criando pull requests

Suponha que você queira que o Verdent crie um pull request abrangente.

Garanta que as alterações estejam commitadas

Make sure all my changes are committed

Verdent verifica o git status e commita quaisquer alterações não commitadas.

Faça push da branch para o remoto

Push this branch to origin

Verdent faz push:

git push origin feature/user-notifications

Solicite a criação do PR

Create a pull request for this feature

Verdent usa a CLI gh para criar o PR.

Verdent gera a descrição do PR

Verdent analisa os commits e as alterações para gerar:

Título: Add user notification system

Corpo:

## 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

O PR é criado com uma descrição abrangente.

Dicas:

  • Verdent analisa todos os commits da branch para gerar a descrição do PR
  • Solicite formatos específicos de PR: "Crie um PR com um plano de testes detalhado"
  • Inclua capturas de tela: "Adicione esta captura de tela à descrição do PR"
  • Você pode refinar a descrição do PR antes da criação: "Atualize o PR para mencionar a mudança incompatível"

Resolvendo conflitos de merge

Suponha que você encontre conflitos de merge e precise da ajuda do Verdent para resolvê-los.

Tente o merge

Merge main into this feature branch

Ocorre um conflito de merge:

Auto-merging src/auth.ts
CONFLICT (content): Merge conflict in src/auth.ts

Solicite a resolução do conflito

Help me resolve the merge conflict in src/auth.ts

Verdent lê os marcadores de conflito.

Verdent analisa ambas as versões

Verdent examina:

  • Alterações da branch atual (HEAD)
  • Alterações recebidas (branch main)
  • Contexto ao redor dos conflitos
  • Intenção de ambas as alterações

Verdent propõe uma resolução

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 resolve o conflito integrando ambas as alterações de forma inteligente.

Marque o conflito como resolvido

git add src/auth.ts
git commit -m "Merge main into feature/jwt-auth, resolved conflicts"

O conflito é resolvido e o merge é concluído.

Dicas:

  • Verdent entende o contexto do código para resolver conflitos de forma inteligente
  • Sempre revise as resoluções de conflito antes de commitar
  • Para conflitos complexos, peça ao Verdent para explicar ambas as versões primeiro
  • Teste minuciosamente após resolver conflitos

Verdent analisa conflitos de merge entendendo a intenção de ambas as branches, sugerindo resoluções que preservam a funcionalidade dos dois lados.


Gerenciando branches e tags

Suponha que você precise gerenciar branches e criar tags de release.

Criar e alternar branches:

Create a new branch called feature/user-notifications

Verdent executa:

git checkout -b feature/user-notifications
git checkout main
git checkout -b feature/payment-integration
git push -u origin feature/payment-integration

Fazer merge de branches de feature:

Merge the feature/user-notifications branch into main

Verdent executa o fluxo de trabalho de merge:

git checkout main
git pull origin main
git merge feature/user-notifications
git push origin main

Verdent garante que a main esteja atualizada antes de fazer o merge.

Criar tags anotadas:

Create an annotated tag for version 1.2.0 with release notes

Verdent cria uma tag detalhada:

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"

Fazer push das tags:

Push all tags to origin

Verdent faz push:

git push origin --tags

Dicas:

  • Use nomes de branch descritivos: feature/user-auth, fix/cart-bug, refactor/api-layer
  • Sempre faça pull das últimas alterações antes de fazer o merge
  • Use tags anotadas para releases (elas incluem metadados)
  • Siga o versionamento semântico: v1.2.3 (major.minor.patch)

Convenções consistentes de nomenclatura de branches ajudam o Verdent a entender seu fluxo de trabalho. Defina padrões no AGENTS.md para conformidade automática.


Perguntas frequentes

O Verdent commita minhas alterações automaticamente?

Não. Verdent só cria commits quando você os solicita explicitamente. Você mantém total controle sobre quando as alterações são commitadas. Basta dizer "Adicione todas as alterações ao stage e crie um commit" quando estiver pronto.

Posso editar a mensagem de commit antes de commitar?

Sim. Você pode pedir ao Verdent para revisar a mensagem de commit antes que ela seja criada. Diga "Atualize a mensagem de commit para mencionar a mudança incompatível" ou "Torne essa mensagem de commit mais concisa". Verdent vai regenerar a mensagem com base no seu feedback.

O Verdent funciona com GitHub, GitLab, Bitbucket e outras plataformas Git?

Sim. Verdent usa comandos Git padrão, então funciona com qualquer repositório Git independentemente da plataforma de hospedagem. Para criar pull requests, Verdent usa a CLI gh, que requer GitHub, mas todas as outras operações Git funcionam universalmente.

O Verdent vai fazer push para repositórios remotos sem perguntar?

Não. Verdent só faz push para repositórios remotos quando você o solicita explicitamente. Todas as operações Git (commit, push, merge, rebase) requerem sua instrução explícita por segurança.

O Verdent consegue resolver todos os tipos de conflito de merge?

Verdent consegue resolver a maioria dos conflitos de merge baseados em texto entendendo o contexto e a intenção do código. Conflitos de arquivos binários ou conflitos de múltiplas vias muito complexos podem exigir intervenção manual. Sempre revise a resolução de conflitos do Verdent antes de commitar.


Veja também