# Intégration du contrôle de version (/fr/docs/verdent-for-vscode/common-workflows/version-control)

> Utilisation avec Git et d'autres systèmes de contrôle de version



Verdent for VS Code s'intègre parfaitement avec Git et d'autres systèmes de contrôle de version, permettant des opérations de contrôle de version en langage naturel, une génération automatisée de messages de commit et une gestion intelligente des branches. Ce guide vous montre comment tirer parti de l'intégration Git de Verdent pour des flux de travail de contrôle de version efficaces.

***

## Créer des messages de commit pertinents [#créer-des-messages-de-commit-pertinents]

Supposons que vous avez effectué des modifications et que vous souhaitez que Verdent génère un message de commit descriptif.

<Steps>
  <Step title="Demander un commit avec un message généré">
    ```
    Stage all changes and create a commit with an appropriate message
    ```

    Verdent analyse vos modifications à l'aide de git diff.
  </Step>

  <Step title="Verdent analyse les modifications">
    Verdent examine :

    * Les fichiers modifiés et leur objectif
    * La nature des modifications (nouvelle fonctionnalité, correction de bug, refactorisation)
    * La portée de l'impact
    * Les fonctionnalités associées
  </Step>

  <Step title="Génère un message de commit descriptif">
    ```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"
    ```

    Le message suit le format de commit conventionnel et décrit ce qui a changé.
  </Step>

  <Step title="Le commit est créé">
    Les modifications sont commitées avec le message généré. Vous pouvez consulter le commit :

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

<Tip>
  **Astuces :**

  * Verdent suit les formats de commit conventionnels (feat, fix, refactor, docs, etc.)
  * Les messages de commit se concentrent sur le « quoi » et le « pourquoi », pas sur le « comment »
  * Vous pouvez personnaliser le format des messages de commit dans les règles utilisateur ou les règles du projet
  * Demandez des styles de messages de commit spécifiques : « Crée un commit avec un message détaillé sur plusieurs lignes »
</Tip>

***

## Personnaliser les formats de messages de commit [#personnaliser-les-formats-de-messages-de-commit]

Supposons que vous souhaitez que Verdent suive les conventions spécifiques de messages de commit de votre équipe.

<Tabs>
  <Tab title="Règles utilisateur (globales)">
    Définissez vos préférences de messages de commit dans `VERDENT.md` pour tous les projets :

    ```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 suit ces règles globalement.
  </Tab>

  <Tab title="Règles du projet">
    Définissez des conventions de commit spécifiques au projet dans `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"
    ```

    Les règles s'appliquent uniquement à ce projet.
  </Tab>

  <Tab title="Instructions en ligne">
    Fournissez des instructions ponctuelles directement :

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

    Verdent génère :

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

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

<Tip>
  **Astuces :**

  * Les règles utilisateur s'appliquent globalement à tous les projets
  * Les règles du projet (AGENTS.md) remplacent les règles utilisateur pour des projets spécifiques
  * Les instructions en ligne remplacent les deux pour des besoins ponctuels
  * Le format Conventional Commits est recommandé pour la cohérence
</Tip>

***

## Créer des pull requests [#créer-des-pull-requests]

Supposons que vous souhaitez que Verdent crée une pull request complète.

<Steps>
  <Step title="Vérifier que les modifications sont commitées">
    ```
    Make sure all my changes are committed
    ```

    Verdent vérifie le statut git et commite toutes les modifications non commitées.
  </Step>

  <Step title="Pousser la branche vers le dépôt distant">
    ```
    Push this branch to origin
    ```

    Verdent pousse :

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

  <Step title="Demander la création d'une PR">
    ```
    Create a pull request for this feature
    ```

    Verdent utilise la CLI `gh` pour créer la PR.
  </Step>

  <Step title="Verdent génère la description de la PR">
    Verdent analyse les commits et les modifications pour générer :

    **Titre :** Ajouter un système de notification utilisateur

    **Corps :**

    ```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 est créée avec une description complète.
  </Step>
</Steps>

<Tip>
  **Astuces :**

  * Verdent analyse tous les commits de la branche pour générer la description de la PR
  * Demandez des formats de PR spécifiques : « Crée une PR avec un plan de test détaillé »
  * Incluez des captures d'écran : « Ajoute cette capture d'écran à la description de la PR »
  * Vous pouvez affiner la description de la PR avant sa création : « Mets à jour la PR pour mentionner le changement cassant »
</Tip>

***

## Résoudre les conflits de fusion [#résoudre-les-conflits-de-fusion]

Supposons que vous rencontrez des conflits de fusion et avez besoin de l'aide de Verdent pour les résoudre.

<Steps>
  <Step title="Tenter la fusion">
    ```
    Merge main into this feature branch
    ```

    Un conflit de fusion se produit :

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

  <Step title="Demander la résolution du conflit">
    ```
    Help me resolve the merge conflict in src/auth.ts
    ```

    Verdent lit les marqueurs de conflit.
  </Step>

  <Step title="Verdent analyse les deux versions">
    Verdent examine :

    * Les modifications de la branche actuelle (HEAD)
    * Les modifications entrantes (branche main)
    * Le contexte autour des conflits
    * L'intention des deux modifications
  </Step>

  <Step title="Verdent propose une résolution">
    ```
    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 résout le conflit en intégrant intelligemment les deux modifications.
  </Step>

  <Step title="Marquer le conflit comme résolu">
    ```bash
    git add src/auth.ts
    git commit -m "Merge main into feature/jwt-auth, resolved conflicts"
    ```

    Le conflit est résolu et la fusion est terminée.
  </Step>
</Steps>

<Tip>
  **Astuces :**

  * Verdent comprend le contexte du code pour résoudre intelligemment les conflits
  * Vérifiez toujours les résolutions de conflits avant de commiter
  * Pour les conflits complexes, demandez à Verdent d'expliquer d'abord les deux versions
  * Testez minutieusement après la résolution des conflits
</Tip>

<Tip>
  Verdent analyse les conflits de fusion en comprenant l'intention des deux branches, en suggérant des résolutions qui préservent les fonctionnalités des deux côtés.
</Tip>

***

## Gérer les branches et les tags [#gérer-les-branches-et-les-tags]

Supposons que vous devez gérer des branches et créer des tags de version.

<Tabs>
  <Tab title="Opérations sur les branches">
    **Créer et changer de branche :**

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

    Verdent exécute :

    <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="Fusion">
    **Fusionner des branches de fonctionnalité :**

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

    Verdent effectue le flux de fusion :

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

    Verdent s'assure que main est à jour avant la fusion.
  </Tab>

  <Tab title="Marquage des versions">
    **Créer des tags annotés :**

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

    Verdent crée un tag détaillé :

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

    **Pousser les tags :**

    ```
    Push all tags to origin
    ```

    Verdent pousse :

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

<Tip>
  **Astuces :**

  * Utilisez des noms de branches descriptifs : `feature/user-auth`, `fix/cart-bug`, `refactor/api-layer`
  * Récupérez toujours les dernières modifications avant de fusionner
  * Utilisez des tags annotés pour les versions (ils incluent des métadonnées)
  * Suivez le versionnage sémantique : v1.2.3 (majeur.mineur.correctif)
</Tip>

<Tip>
  Des conventions de nommage de branches cohérentes aident Verdent à comprendre votre flux de travail. Définissez des modèles dans AGENTS.md pour une conformité automatique.
</Tip>

***

## Questions fréquentes [#questions-fréquentes]

<Accordion title="Verdent commite-t-il automatiquement mes modifications ?">
  Non. Verdent ne crée des commits que lorsque vous le demandez explicitement. Vous gardez le contrôle total sur le moment où les modifications sont commitées. Demandez simplement « Ajoute toutes les modifications à l'index et crée un commit » lorsque vous êtes prêt.
</Accordion>

<Accordion title="Puis-je modifier le message de commit avant de commiter ?">
  Oui. Vous pouvez demander à Verdent de réviser le message de commit avant sa création. Dites « Mets à jour le message de commit pour mentionner le changement cassant » ou « Rends ce message de commit plus concis. » Verdent régénérera le message en fonction de vos retours.
</Accordion>

<Accordion title="Verdent fonctionne-t-il avec GitHub, GitLab, Bitbucket et d'autres plateformes Git ?">
  Oui. Verdent utilise les commandes Git standard, il fonctionne donc avec n'importe quel dépôt Git, quelle que soit la plateforme d'hébergement. Pour créer des pull requests, Verdent utilise la CLI `gh`, qui nécessite GitHub, mais toutes les autres opérations Git fonctionnent universellement.
</Accordion>

<Accordion title="Verdent pousse-t-il vers des dépôts distants sans demander ?">
  Non. Verdent ne pousse vers des dépôts distants que lorsque vous le demandez explicitement. Toutes les opérations Git (commit, push, merge, rebase) nécessitent votre instruction explicite pour des raisons de sécurité.
</Accordion>

<Accordion title="Verdent peut-il résoudre tous les types de conflits de fusion ?">
  Verdent peut résoudre la plupart des conflits de fusion basés sur du texte en comprenant le contexte et l'intention du code. Les conflits sur fichiers binaires ou les conflits multi-voies très complexes peuvent nécessiter une intervention manuelle. Vérifiez toujours la résolution de conflit de Verdent avant de commiter.
</Accordion>

***

## Voir aussi [#voir-aussi]

<CardGroup cols="2">
  <Card title="Exemples de tâches multi-étapes" icon="list-check" href="/docs/verdent-for-vscode/common-workflows/multi-step-tasks">
    Flux de travail multi-étapes complexes et gestion des tâches
  </Card>

  <Card title="Écrire du nouveau code" icon="code" href="/docs/verdent-for-vscode/task-based-guides/writing-code">
    Créer de nouvelles fonctionnalités et composants avec Verdent
  </Card>
</CardGroup>