Verdent Docs
Flussi di lavoro comuni

Integrazione con il controllo di versione

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

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

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.

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

Genera un messaggio di commit descrittivo

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.

Il commit viene creato

Le modifiche vengono committate con il messaggio generato. Puoi rivedere il commit:

git log -1

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"

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.

Definisci le preferenze per i messaggi di commit in VERDENT.md per tutti i progetti:

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

Definisci le convenzioni di commit specifiche del progetto in 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"

Le regole si applicano solo a questo progetto.

Fornisci istruzioni una tantum direttamente:

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

Verdent genera:

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

Relates to #42"

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

Creare pull request

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

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.

Effettuare il push del branch sul remoto

Push this branch to origin

Verdent effettua il push di:

git push origin feature/user-notifications

Richiedere la creazione della PR

Create a pull request for this feature

Verdent usa la CLI gh per creare la PR.

Verdent genera la descrizione della PR

Verdent analizza i commit e le modifiche per generare:

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

La PR viene creata con una descrizione completa.

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"

Risolvere i conflitti di merge

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

Tentare il merge

Merge main into this feature branch

Si verifica un conflitto di merge:

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

Richiedere la risoluzione del conflitto

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

Verdent legge i marcatori di conflitto.

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

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.

Contrassegnare il conflitto come risolto

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

Il conflitto è risolto e il merge è completato.

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

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


Gestire branch e tag

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

Creare e passare da un branch all'altro:

Create a new branch called feature/user-notifications

Verdent esegue:

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

Unire i branch delle funzionalità:

Merge the feature/user-notifications branch into main

Verdent esegue il flusso di lavoro di merge:

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.

Creare tag annotati:

Create an annotated tag for version 1.2.0 with release notes

Verdent crea un tag dettagliato:

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:

git push origin --tags

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)

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.


Domande frequenti

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.

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.

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.

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.

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.


Vedi anche