Git & GitHub

Un workflow est un ensemble de conventions sur comment utiliser les branches. Sans workflow, chaque développeur fait comme il veut — c'est le chaos. Avec un workflow, tout le monde suit les mêmes règles.

GitHub Flow — simple et efficace

C'est le workflow recommandé pour les petites équipes et les projets web :

1. La branche main est TOUJOURS déployable
2. Pour chaque changement, créer une branche depuis main
3. Commiter et pousser la branche
4. Ouvrir une Pull Request
5. Après review et approbation, merger dans main
6. Déployer main (automatiquement ou manuellement)

C'est tout. 6 étapes. Simple, efficace, compréhensible.

GitFlow — pour les gros projets

GitFlow utilise plus de branches :

• main — le code en production (ce que les utilisateurs voient)
• develop — le code de la prochaine version (intégration)
• feature/ — fonctionnalités en cours (depuis develop)
• release/ — préparation d'une version (depuis develop, merge dans main + develop)
• hotfix/ — correction urgente en production (depuis main, merge dans main + develop)

GitFlow est plus complexe et convient aux projets avec des cycles de release (applications mobiles, logiciels avec versions). Pour un site web qui déploie en continu, GitHub Flow suffit.

Choisir le bon workflow

• Projet solo ou petite équipe web → GitHub Flow
• Projet avec versions numérotées (v1.0, v2.0) → GitFlow
• Open source avec beaucoup de contributeurs → GitFlow ou variante

Les tags — marquer les versions

Les tags marquent un commit spécifique comme une version :

git tag v1.0.0 crée un tag sur le commit actuel. git push --tags pousse les tags sur GitHub.

Convention SemVer : v1.2.3 = vMajeur.Mineur.Patch

• Majeur — changements incompatibles (refonte complète)
• Mineur — nouvelles fonctionnalités (rétrocompatibles)
• Patch — corrections de bugs

> Recommandation : Commencez avec GitHub Flow. C'est le workflow utilisé par GitHub eux-mêmes. Passez à GitFlow seulement si votre projet l'exige.