Intégration du contrôle de version
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
Supposons que vous avez effectué des modifications et que vous souhaitez que Verdent génère un message de commit descriptif.
Demander un commit avec un message généré
Stage all changes and create a commit with an appropriate messageVerdent analyse vos modifications à l'aide de git diff.
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
Génère un message de commit descriptif
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é.
Le commit est créé
Les modifications sont commitées avec le message généré. Vous pouvez consulter le commit :
git log -1Astuces :
- 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 »
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.
Définissez vos préférences de messages de commit dans VERDENT.md pour tous les projets :
# 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.
Définissez des conventions de commit spécifiques au projet dans 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"Les règles s'appliquent uniquement à ce projet.
Fournissez des instructions ponctuelles directement :
Create a commit with message format: "[TICKET-NUMBER] description" including reference to issue #42Verdent génère :
git commit -m "[PROJ-42] Add search functionality
Relates to #42"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
Créer des pull requests
Supposons que vous souhaitez que Verdent crée une pull request complète.
Vérifier que les modifications sont commitées
Make sure all my changes are committedVerdent vérifie le statut git et commite toutes les modifications non commitées.
Pousser la branche vers le dépôt distant
Push this branch to originVerdent pousse :
git push origin feature/user-notificationsDemander la création d'une PR
Create a pull request for this featureVerdent utilise la CLI gh pour créer la PR.
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 :
## 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 settingsLa PR est créée avec une description complète.
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 »
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.
Tenter la fusion
Merge main into this feature branchUn conflit de fusion se produit :
Auto-merging src/auth.ts
CONFLICT (content): Merge conflict in src/auth.tsDemander la résolution du conflit
Help me resolve the merge conflict in src/auth.tsVerdent lit les marqueurs de conflit.
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
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.
Marquer le conflit comme résolu
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.
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
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.
Gérer les branches et les tags
Supposons que vous devez gérer des branches et créer des tags de version.
Créer et changer de branche :
Create a new branch called feature/user-notificationsVerdent exécute :
git checkout -b feature/user-notificationsgit checkout maingit checkout -b feature/payment-integration
git push -u origin feature/payment-integrationFusionner des branches de fonctionnalité :
Merge the feature/user-notifications branch into mainVerdent effectue le flux de fusion :
git checkout main
git pull origin main
git merge feature/user-notifications
git push origin mainVerdent s'assure que main est à jour avant la fusion.
Créer des tags annotés :
Create an annotated tag for version 1.2.0 with release notesVerdent crée un tag détaillé :
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 originVerdent pousse :
git push origin --tagsAstuces :
- 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)
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.
Questions fréquentes
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.
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.
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.
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é.
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.