---
title: Integração com controle de versão
description: 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.

<Steps>
  <Step title="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.
  </Step>

  <Step title="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
  </Step>

  <Step title="Gera uma mensagem de commit descritiva">
    ```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"
    ```

    A mensagem segue o formato de commit convencional e descreve o que mudou.
  </Step>

  <Step title="O commit é criado">
    As alterações são commitadas com a mensagem gerada. Você pode revisar o commit:

    ```bash
    git log -1
    ```
  </Step>
</Steps>

<Tip>
  **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"
</Tip>

***

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

<Tabs>
  <Tab title="User Rules (global)">
    Defina as preferências de mensagem de commit em `VERDENT.md` para todos os projetos:

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

    Verdent segue essas regras globalmente.
  </Tab>

  <Tab title="Project Rules">
    Defina convenções de commit específicas do projeto em `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"
    ```

    As regras se aplicam apenas a este projeto.
  </Tab>

  <Tab title="Instruções inline">
    Forneça instruções pontuais diretamente:

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

    Verdent gera:
    ```bash
    git commit -m "[PROJ-42] Add search functionality

    Relates to #42"
    ```
  </Tab>
</Tabs>

<Tip>
  **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
</Tip>

***

## Criando pull requests

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

<Steps>
  <Step title="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.
  </Step>

  <Step title="Faça push da branch para o remoto">
    ```
    Push this branch to origin
    ```

    Verdent faz push:
    ```bash
    git push origin feature/user-notifications
    ```
  </Step>

  <Step title="Solicite a criação do PR">
    ```
    Create a pull request for this feature
    ```

    Verdent usa a CLI `gh` para criar o PR.
  </Step>

  <Step title="Verdent gera a descrição do PR">
    Verdent analisa os commits e as alterações para gerar:

    **Título:** Add user notification system

    **Corpo:**
    ```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
    ```

    O PR é criado com uma descrição abrangente.
  </Step>
</Steps>

<Tip>
  **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"
</Tip>

***

## Resolvendo conflitos de merge

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

<Steps>
  <Step title="Tente o merge">
    ```
    Merge main into this feature branch
    ```

    Ocorre um conflito de merge:
    ```bash
    Auto-merging src/auth.ts
    CONFLICT (content): Merge conflict in src/auth.ts
    ```
  </Step>

  <Step title="Solicite a resolução do conflito">
    ```
    Help me resolve the merge conflict in src/auth.ts
    ```

    Verdent lê os marcadores de conflito.
  </Step>

  <Step title="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
  </Step>

  <Step title="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.
  </Step>

  <Step title="Marque o conflito como resolvido">
    ```bash
    git add src/auth.ts
    git commit -m "Merge main into feature/jwt-auth, resolved conflicts"
    ```

    O conflito é resolvido e o merge é concluído.
  </Step>
</Steps>

<Tip>
  **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
</Tip>

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

***

## Gerenciando branches e tags

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

<Tabs>
  <Tab title="Operações com branches">
    **Criar e alternar branches:**

    ```
    Create a new branch called feature/user-notifications
    ```

    Verdent executa:

    <CodeGroup>
    ```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
    ```
    </CodeGroup>
  </Tab>

  <Tab title="Merge">
    **Fazer merge de branches de feature:**

    ```
    Merge the feature/user-notifications branch into main
    ```

    Verdent executa o fluxo de trabalho de merge:
    ```bash
    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.
  </Tab>

  <Tab title="Criando tags de release">
    **Criar tags anotadas:**

    ```
    Create an annotated tag for version 1.2.0 with release notes
    ```

    Verdent cria uma tag detalhada:
    ```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"
    ```

    **Fazer push das tags:**

    ```
    Push all tags to origin
    ```

    Verdent faz push:
    ```bash
    git push origin --tags
    ```
  </Tab>
</Tabs>

<Tip>
  **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)
</Tip>

<Tip>
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.
</Tip>

***

## Perguntas frequentes

<Accordion title="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.
</Accordion>

<Accordion title="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.
</Accordion>

<Accordion title="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.
</Accordion>

<Accordion title="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.
</Accordion>

<Accordion title="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.
</Accordion>

***

## Veja também

<CardGroup cols={2}>
  <Card title="Exemplos de tarefas de múltiplas etapas" icon="list-check" href="/docs/verdent-for-vscode/common-workflows/multi-step-tasks">
    Fluxos de trabalho complexos de múltiplas etapas e gerenciamento de tarefas
  </Card>

  <Card title="Escrevendo novo código" icon="code" href="/docs/verdent-for-vscode/task-based-guides/writing-code">
    Criando novos recursos e componentes com Verdent
  </Card>
</CardGroup>