Git Workflow Flashcards
Pourquoi utiliser un workflow Git dans un projet de développement web ?
Un workflow Git standardise les pratiques de développement en équipe, permettant un contrôle continu du code et l’identification précoce des dysfonctionnements. Il améliore la qualité du code, facilite la collaboration et permet une meilleure réactivité en cas de problèmes. Dans un contexte professionnel, chaque entreprise a ses propres process de développement et il est essentiel de s’y adapter.
Expliquez la structure des branches dans le workflow présenté.
Ce workflow utilise trois branches principales protégées:
*
main: contient le code de production, toujours fonctionnel et déployable
*
staging: environnement de préproduction pour les tests avant déploiement
*
dev: branche de développement où sont fusionnées toutes les fonctionnalités
Et des branches temporaires:
*
Branches de fonctionnalité: une branche par User Story (ex: S02US12_contact_form)
*
Branches de correction: pour réparer des bugs (ex: fix_responsive_navbar)
Décrivez le processus de développement d’une nouvelle fonctionnalité dans ce workflow.
Je me mets à jour par rapport à la branche dev avec git pull origin dev
2. Je crée une nouvelle branche de fonctionnalité: git checkout -b S02US12_contact_form dev
3. Je développe la fonctionnalité en faisant des commits réguliers pour chaque tâche technique
4. Je teste complètement la fonctionnalité pour m’assurer qu’elle est pleinement opérationnelle
5. Je pousse ma branche sur GitHub: git push origin S02US12_contact_form
6. Je crée une Pull Request pour demander la fusion de ma branche vers dev
7. Après review et validation par l’équipe et le formateur, la PR est mergée dans dev
Qu’est-ce qu’une Pull Request et quel est son rôle dans le processus de développement ?
Une Pull Request (PR) est une demande de fusion entre deux branches. Elle joue plusieurs rôles essentiels:
* Permet une revue de code par les pairs avant intégration
* Offre une plateforme pour discuter des changements et suggérer des améliorations
* Met en place un système de validation/refus avec différentes règles
* Maintient un historique des modifications et des discussions
* Assure la qualité du code via un processus de validation multiple (pairs + formateur)
Quelles sont les bonnes pratiques pour réaliser une Pull Request de qualité ?
Une bonne Pull Request doit:
* Se limiter à une seule User Story ou fonctionnalité
* Ne pas contenir de code mort (commenté) ou de traces de debug
* Utiliser des noms de variables clairs et cohérents
* Être exempte de fautes d’orthographe
* Respecter les normes de codage du projet
* Être complètement fonctionnelle, stylisée et sécurisée
* Être responsive si c’est une interface utilisateur
* Être accompagnée d’une description claire de ce qu’elle apporte
Comment gérez-vous les conflits dans ce workflow Git ?
Les conflits sont gérés selon un processus défini:
1. Le formateur place le label “CONFLICTS” sur la PR quand des conflits sont détectés
2. Je ne dois pas essayer de résoudre les conflits avant que ce label soit placé
3. Une fois autorisé, je peux résoudre les conflits localement:
o git checkout ma-branche
o git pull origin dev (pour récupérer les derniers changements)
o Résolution des conflits dans les fichiers concernés
o git add [fichiers résolus]
o git commit -m “Resolve conflicts with dev”
o git push origin ma-branche
4. Je place ensuite le label “CONFLICTS RESOLVED” sur la PR
5. La PR peut être mergée sans nouvelle revue puisqu’elle avait déjà été acceptée
Comment intégrez-vous la méthode Scrum à ce workflow Git ?
La méthode Scrum s’intègre parfaitement à ce workflow Git:
* Chaque Sprint d’une semaine correspond à un ensemble de fonctionnalités à développer
* Les User Stories du Sprint backlog se traduisent en branches de fonctionnalités
* Le daily meeting permet de suivre l’avancement des PR et d’identifier les blocages
* Les branches mergées dans dev représentent les fonctionnalités terminées du Sprint
* La revue de Sprint du vendredi utilise la branche staging pour présenter les fonctionnalités
* La rétrospective permet d’améliorer continuellement le processus workflow
Expliquez comment vous utiliseriez les labels dans les Pull Requests.
Les labels facilitent le suivi des PR:
* “REVIEWED”: Indique que la PR a été validée par un autre développeur
* “CHANGES REQUESTED”: Des modifications sont nécessaires suite à la review
* “CORRECTIONS DONE”: Les corrections demandées ont été effectuées
* “CONFLICTS”: Des conflits ont été détectés et doivent être résolus
* “CONFLICTS RESOLVED”: Les conflits ont été résolus et la PR peut être mergée
Comment ce workflow intègre-t-il les aspects de sécurité et de qualité du code ?
Ce workflow renforce la sécurité et la qualité du code de plusieurs façons:
* Double validation des PR (pairs + formateur) pour détecter les problèmes
* Intégration possible de CI/CD pour automatiser les tests
* Séparation claire entre environnements (dev, staging, production)
* Process de review obligatoire empêchant le push direct sur les branches protégées
* Pratique du “code en état fonctionnel permanent” sur les branches principales
* Tests systématiques avant fusion des PR
* Identification des critères de qualité (pas de code mort, pas de traces de debug, etc.)
Comment intégreriez-vous le CI/CD (Continuous Integration/Continuous Delivery) à ce workflow Git ?
Le CI/CD pourrait être intégré de cette façon:
* Continuous Integration: Mise en place de tests automatiques sur les PR
o Tests de style de code (linting)
o Tests unitaires
o Tests d’intégration
o Vérification de sécurité
o Refus automatique de la PR en cas d’échec des tests
* Continuous Delivery: Automatisation du déploiement
o
Déploiement automatique de la branche dev vers l’environnement de développement
o
Déploiement automatique de la branche staging vers l’environnement de préproduction
o Déploiement manuel (ou automatique avec validation) de main vers la production
Cela augmenterait la qualité du code et accélérerait les cycles de développement.
