Projet GitHub

Voici quelques conseils pour bien mettre en place le projet GitHub. Cela prend un peu de temps à se familiariser mais permet vraiment d'aider le travail en équipe.

1. Créer/Accéder au repository Git
2. Découper le projet en tâches qui peuvent se faire en 1-2 jours pour faciliter le travail, garder la motivation et accélerer la revue de code
3. Pour gérer les tâches, il peut être pratique de créer des Issues sur le repository sur GitHub et de les attribuer
4. Protéger la branche main des push pour forcer l'usage des pull requests pour inclure du code sur main
5. Créer des nouvelles branches pour chaque fonctionnalité avec des noms explicites (exemple: add-robot-smart-rotation) et proposer la modification via des PR (pull request)
6. Pour assurer un minimum de qualité de code il est possible d'imposer au moins une approbation d'une autre personnes avant qu'une PR puisse être mergée.
7. S'assurer que le code compile, est formatté et que les tests passent encore à chaque PR (une CI sur GitHub Actions peut être mise en place pour automatiser cela si envie d'aller plus loin)
8. Imposer le même formatage de code pour tout le monde, pour éviter des centaines de conflits Git générés juste parce que le formattage n'est pas le même. Ces réglages peuvent être imposés via un fichier .clang-format. Les réglages par défaut de CLion peuvent être exportés dans ce format depuis les réglages, si ces configurations conviennent.
9. Merger les branches souvent pour éviter que le code diverge trop. Autant la branche main vers les branches de fonctionnalités pour récupérer les dernières améliorations, que les branches fonctionnalités via des PRs. Plus les modifications sont petites, plus de potentiel de conflits Git est faible et plus il sera facile à intégrer les changements.
10. Supprimer les branches une fois que les PRs associées ont été mergées (bouton Delete branch visible une fois mergé), pour facilement identifier les branches en cours des vieilles branches qui n'ont plus d'utilité.
11. Demander l'écriture de tests unitaires avant de merger une PR, pour valider les calculs ou la logique qui fait sens
12. Pour la revue de l'état de son projet par une autre équipe et la revue du projet d'une autre équipe, assigne juste 1-2 personnes dessus et ne dérange pas le reste de l'équipe régulièrement avec des discussions du type: "Alors l'équipe qu'on doit review elle est prête ?" ou encore "L'équipe qui doit nous review elle peut venir ou pas encore ?"

Voici quelques page de documentation de GitHub pour faciliter la gestion du projet GitHub:

• Pour empêcher les push sur la branche main - Managing a branch protection rule
• Pour apprendre gérer, revoir et commenter des pull requests: Creating a pull request
• Pour gérer les conflits Git: Addressing merge conflicts
• Pour revoir le code d'une PR: Reviewing proposed changes in a pull request

Les situations à vraiment éviter

1. Rester chacun dans son coin au sein de l'équipe. -> C'est un travail d'équipe, il est important de communiquer régulièrement, de s'entraider et d'améliorer la manière de s'organiser en faisant le point régulièrement.
2. Séparer l'équipe en deux (pour l'UI et le reste), faire deux branches et merger le tout à la fin. -> En attendant la toute fin, le merge va être ULTRA compliqué tellement le code a divergé le long du projet. Il faut absolument faire des revues de code régulièrement et merger régulièrement des petits incréments.
3. Rester bloqué plusieurs jours et ne jamais poser de questions. -> C'est normal d'être bloqué sur des problèmes de calculs, de géométrie, de logique, de stratégie ou d'usage de Qt. Les enseignant·es et assistant·es sont là pour t'aider, aller poser des questions au plus vite ! Parfois, juste de reexpliquer ce qu'on a compris donne confiance en sa compréhension ou ajuste le modèle mental du jeu.