# Integrazione con il controllo di versione (/it/docs/verdent-for-vscode/common-workflows/version-control)

> Lavorare con Git e altri sistemi di controllo di versione



Verdent for VS Code si integra perfettamente con Git e altri sistemi di controllo di versione, permettendo operazioni di controllo di versione in linguaggio naturale, la generazione automatica dei messaggi di commit e una gestione intelligente dei branch. Questa guida ti mostra come sfruttare l'integrazione Git di Verdent per flussi di lavoro di controllo di versione efficienti.

***

## Creare messaggi di commit significativi [#creare-messaggi-di-commit-significativi]

Supponiamo che tu abbia apportato delle modifiche e voglia che Verdent generi un messaggio di commit descrittivo.

<Steps>
  <Step title="Richiedere un commit con messaggio generato">
    ```
    Stage all changes and create a commit with an appropriate message
    ```

    Verdent analizza le tue modifiche usando git diff.
  </Step>

  <Step title="Verdent analizza le modifiche">
    Verdent esamina:

    * I file modificati e il loro scopo
    * La natura delle modifiche (nuova funzionalità, correzione di bug, refactoring)
    * L'ambito dell'impatto
    * Le funzionalità correlate
  </Step>

  <Step title="Genera un messaggio di commit descrittivo">
    ```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"
    ```

    Il messaggio segue il formato conventional commit e descrive cosa è cambiato.
  </Step>

  <Step title="Il commit viene creato">
    Le modifiche vengono committate con il messaggio generato. Puoi rivedere il commit:

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

<Tip>
  **Suggerimenti:**

  * Verdent segue i formati conventional commit (feat, fix, refactor, docs, ecc.)
  * I messaggi di commit si concentrano sul "cosa" e sul "perché", non sul "come"
  * Puoi personalizzare il formato del messaggio di commit nelle User Rules o nelle Project Rules
  * Richiedi stili specifici per il messaggio di commit: "Crea un commit con un messaggio dettagliato su più righe"
</Tip>

***

## Personalizzare i formati dei messaggi di commit [#personalizzare-i-formati-dei-messaggi-di-commit]

Supponiamo che tu voglia che Verdent segua le convenzioni specifiche del tuo team per i messaggi di commit.

<Tabs>
  <Tab title="User Rules (globali)">
    Definisci le preferenze per i messaggi di commit in `VERDENT.md` per tutti i progetti:

    ```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 queste regole a livello globale.
  </Tab>

  <Tab title="Project Rules">
    Definisci le convenzioni di commit specifiche del progetto in `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"
    ```

    Le regole si applicano solo a questo progetto.
  </Tab>

  <Tab title="Istruzioni inline">
    Fornisci istruzioni una tantum direttamente:

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

    Verdent genera:

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

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

<Tip>
  **Suggerimenti:**

  * Le User Rules si applicano a livello globale a tutti i progetti
  * Le Project Rules (AGENTS.md) hanno la precedenza sulle User Rules per progetti specifici
  * Le istruzioni inline hanno la precedenza su entrambe per esigenze una tantum
  * Il formato Conventional Commits è consigliato per garantire coerenza
</Tip>

***

## Creare pull request [#creare-pull-request]

Supponiamo che tu voglia che Verdent crei una pull request completa.

<Steps>
  <Step title="Assicurarsi che le modifiche siano committate">
    ```
    Make sure all my changes are committed
    ```

    Verdent controlla lo stato di git e committa eventuali modifiche non committate.
  </Step>

  <Step title="Effettuare il push del branch sul remoto">
    ```
    Push this branch to origin
    ```

    Verdent effettua il push di:

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

  <Step title="Richiedere la creazione della PR">
    ```
    Create a pull request for this feature
    ```

    Verdent usa la CLI `gh` per creare la PR.
  </Step>

  <Step title="Verdent genera la descrizione della PR">
    Verdent analizza i commit e le modifiche per generare:

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

    La PR viene creata con una descrizione completa.
  </Step>
</Steps>

<Tip>
  **Suggerimenti:**

  * Verdent analizza tutti i commit nel branch per generare la descrizione della PR
  * Richiedi formati specifici per la PR: "Crea una PR con un piano di test dettagliato"
  * Includi screenshot: "Aggiungi questo screenshot alla descrizione della PR"
  * Puoi perfezionare la descrizione della PR prima della creazione: "Aggiorna la PR per menzionare la breaking change"
</Tip>

***

## Risolvere i conflitti di merge [#risolvere-i-conflitti-di-merge]

Supponiamo che tu incontri dei conflitti di merge e abbia bisogno dell'aiuto di Verdent per risolverli.

<Steps>
  <Step title="Tentare il merge">
    ```
    Merge main into this feature branch
    ```

    Si verifica un conflitto di merge:

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

  <Step title="Richiedere la risoluzione del conflitto">
    ```
    Help me resolve the merge conflict in src/auth.ts
    ```

    Verdent legge i marcatori di conflitto.
  </Step>

  <Step title="Verdent analizza entrambe le versioni">
    Verdent esamina:

    * Le modifiche del branch corrente (HEAD)
    * Le modifiche in arrivo (branch main)
    * Il contesto attorno ai conflitti
    * L'intento di entrambe le modifiche
  </Step>

  <Step title="Verdent propone una risoluzione">
    ```
    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 risolve il conflitto integrando in modo intelligente entrambe le modifiche.
  </Step>

  <Step title="Contrassegnare il conflitto come risolto">
    ```bash
    git add src/auth.ts
    git commit -m "Merge main into feature/jwt-auth, resolved conflicts"
    ```

    Il conflitto è risolto e il merge è completato.
  </Step>
</Steps>

<Tip>
  **Suggerimenti:**

  * Verdent comprende il contesto del codice per risolvere i conflitti in modo intelligente
  * Rivedi sempre le risoluzioni dei conflitti prima di committare
  * Per i conflitti complessi, chiedi a Verdent di spiegare prima entrambe le versioni
  * Testa a fondo dopo aver risolto i conflitti
</Tip>

<Tip>
  Verdent analizza i conflitti di merge comprendendo l'intento di entrambi i branch, suggerendo risoluzioni che preservano le funzionalità di entrambe le parti.
</Tip>

***

## Gestire branch e tag [#gestire-branch-e-tag]

Supponiamo che tu debba gestire i branch e creare tag di rilascio.

<Tabs>
  <Tab title="Operazioni sui branch">
    **Creare e passare da un branch all'altro:**

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

    Verdent esegue:

    <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">
    **Unire i branch delle funzionalità:**

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

    Verdent esegue il flusso di lavoro di merge:

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

    Verdent si assicura che main sia aggiornato prima del merge.
  </Tab>

  <Tab title="Creare tag per i rilasci">
    **Creare tag annotati:**

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

    Verdent crea un tag dettagliato:

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

    **Effettuare il push dei tag:**

    ```
    Push all tags to origin
    ```

    Verdent effettua il push di:

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

<Tip>
  **Suggerimenti:**

  * Usa nomi di branch descrittivi: `feature/user-auth`, `fix/cart-bug`, `refactor/api-layer`
  * Effettua sempre il pull delle ultime modifiche prima del merge
  * Usa tag annotati per i rilasci (includono metadati)
  * Segui il versionamento semantico: v1.2.3 (major.minor.patch)
</Tip>

<Tip>
  Convenzioni coerenti per la denominazione dei branch aiutano Verdent a comprendere il tuo flusso di lavoro. Definisci gli schemi in AGENTS.md per una conformità automatica.
</Tip>

***

## Domande frequenti [#domande-frequenti]

<Accordion title="Verdent committa automaticamente le mie modifiche?">
  No. Verdent crea commit solo quando lo richiedi esplicitamente. Mantieni il pieno controllo su quando le modifiche vengono committate. Basta chiedere "Metti in stage tutte le modifiche e crea un commit" quando sei pronto.
</Accordion>

<Accordion title="Posso modificare il messaggio di commit prima di committare?">
  Sì. Puoi chiedere a Verdent di rivedere il messaggio di commit prima che venga creato. Di' "Aggiorna il messaggio di commit per menzionare la breaking change" oppure "Rendi quel messaggio di commit più conciso". Verdent rigenererà il messaggio in base al tuo feedback.
</Accordion>

<Accordion title="Verdent funziona con GitHub, GitLab, Bitbucket e altre piattaforme Git?">
  Sì. Verdent usa i comandi Git standard, quindi funziona con qualsiasi repository Git indipendentemente dalla piattaforma di hosting. Per la creazione delle pull request, Verdent usa la CLI `gh` che richiede GitHub, ma tutte le altre operazioni Git funzionano universalmente.
</Accordion>

<Accordion title="Verdent effettuerà il push sui repository remoti senza chiedere?">
  No. Verdent effettua il push sui repository remoti solo quando lo richiedi esplicitamente. Tutte le operazioni Git (commit, push, merge, rebase) richiedono un'istruzione esplicita per motivi di sicurezza.
</Accordion>

<Accordion title="Verdent può risolvere tutti i tipi di conflitti di merge?">
  Verdent può risolvere la maggior parte dei conflitti di merge basati su testo comprendendo il contesto e l'intento del codice. I conflitti di file binari o i conflitti multi-way molto complessi possono richiedere un intervento manuale. Rivedi sempre la risoluzione dei conflitti di Verdent prima di committare.
</Accordion>

***

## Vedi anche [#vedi-anche]

<CardGroup cols="2">
  <Card title="Esempi di attività multi-step" icon="list-check" href="/docs/verdent-for-vscode/common-workflows/multi-step-tasks">
    Flussi di lavoro complessi a più passaggi e gestione delle attività
  </Card>

  <Card title="Scrivere nuovo codice" icon="code" href="/docs/verdent-for-vscode/task-based-guides/writing-code">
    Creare nuove funzionalità e componenti con Verdent
  </Card>
</CardGroup>