Main et Master Branch dans Git : ce que c'est et pourquoi vous avez besoin d'une branche principale

Qu'est-ce que Main / Master Branch dans Git

Main Branch (ou Master — selon la configuration du dépôt) est la branche par défaut créée lors de l'initialisation de tout dépôt Git. C'est la branche principale du projet et elle contient du code prêt pour le déploiement en production.

Contrairement à develop, où le travail quotidien avec les nouvelles fonctionnalités bat son plein, main est la vitrine du projet. Chaque version du code dans main a suivi un cycle complet : développement dans une branche feature, intégration dans develop, préparation de la publication dans une branche release et tests finaux. Ce n'est qu'après cela que les modifications arrivent dans main.

Principe clé : main doit toujours être stable. Si une erreur est trouvée dans main, cela signifie qu'un hotfix urgent doit être publié hors tour. Par conséquent, dans les projets professionnels, main est protégée contre les modifications accidentelles par des règles de protection de branche.

Selon Git Book, main n'est pas une branche spéciale avec des propriétés uniques, mais une référence normale à un commit qui est conventionnellement considérée comme principale. Git ne fait pas de distinction entre main et toute autre branche au niveau du système.

Transition de master à main

Historiquement, la branche par défaut dans Git s'appelait master. En juin 2020, le mouvement Black Lives Matter a attiré l'attention sur les termes master et slave dans l'industrie informatique. GitHub a annoncé une transition vers le terme main pour la branche par défaut.

Depuis octobre 2020, tous les nouveaux dépôts sur GitHub sont créés avec la branche main. GitLab et Bitbucket ont également implémenté le support de main comme nom par défaut. Git 2.28 (juillet 2020) a ajouté l'option init.defaultBranch pour configurer le nom de la branche par défaut.

Techniquement, renommer une branche existante de master à main est une opération simple. Le principal défi est de mettre à jour toutes les références dans les configurations CI/CD, la documentation et les dépôts locaux des développeurs.

Pour renommer une branche dans un dépôt existant, exécutez :

# Renommer localement master en main
git branch -m master main

# Mettre à jour le dépôt distant
git push -u origin main

# Supprimer l'ancien master sur le serveur
git push origin --delete master

# Mettre à jour HEAD sur le serveur
# (via l'interface web GitHub : Settings → Branches → Default branch)

Rôle de main dans Git Flow et GitHub Flow

Git Flow et GitHub Flow définissent le rôle de la branche main différemment. Le choix du modèle dépend de la taille de l'équipe, de la fréquence des publications et des exigences de stabilité du code.

Pour le développement mobile, Git Flow est la norme, car la publication d'une application dans l'App Store et Google Play a des cycles de publication fixes. GitHub Flow est plus adapté aux projets web pouvant être déployés plusieurs fois par jour.

GitHub Flow — approche simplifiée

Dans GitHub Flow, il n'y a pas de branche develop. Toutes les branches feature sont créées directement à partir de main et, une fois terminées, sont fusionnées via une Pull Request. Chaque fusion dans main déclenche automatiquement le déploiement en production. Ce modèle nécessite un niveau élevé d'automatisation des tests et de discipline d'équipe.

Dans GitHub Flow, il n'y a pas de branche develop. Toutes les branches feature sont créées directement à partir de main et, une fois terminées, sont fusionnées via une Pull Request. Chaque fusion dans main déclenche automatiquement le déploiement en production. Ce modèle nécessite un niveau élevé d'automatisation des tests et de discipline d'équipe.

Protection de la branche main

La protection de branche pour main est un paramètre obligatoire dans tout projet commercial. Sans elle, un push accidentel pourrait envoyer du code incomplet en production ou casser une application fonctionnelle pour tous les utilisateurs.

• Require pull request — le push direct vers main est interdit. Toutes les modifications via PR avec révision.
• Require approvals — minimum 2 approbations pour fusionner dans main (au cas où un réviseur manquerait quelque chose).
• Require status checks — toutes les vérifications CI/CD doivent être réussies avant la fusion.
• Require up-to-date — la PR doit être basée sur le dernier commit de main.
• Include administrators — la protection s'applique même aux propriétaires du dépôt.
• Require signed commits — tous les commits dans main doivent être signés avec une clé GPG.

Configurer les six règles est la norme pour les projets mobiles avec 10 000+ utilisateurs. Pour les petits projets, les trois premières règles suffisent.

Comparaison des niveaux de protection pour différents types de projets

Le niveau de protection de main dépend de l'échelle du projet. Une startup peut se contenter d'une protection minimale, tandis qu'une application d'entreprise nécessite des restrictions maximales.

Publications et étiquettes dans main

Le marquage est la pratique consistant à créer des références nommées vers des commits spécifiques dans main. Chaque étiquette correspond à une version de l'application publiée en production. Cela permet de basculer rapidement vers n'importe quelle version précédente pour le débogage ou les correctifs.

La norme de dénomination des étiquettes dans le développement mobile est SemVer (Versionnement Sémantique) : v1.2.3, où le premier numéro est la version majeure (changements cassants), le second est la version mineure (nouvelles fonctionnalités) et le troisième est le correctif (réparations).

Une étiquette est créée après la fusion de la branche release dans main. Ce commit est ensuite compilé dans CI/CD, signé et envoyé à la boutique d'applications. Si une erreur est trouvée dans l'étiquette, une branche hotfix est créée à partir de cette étiquette.

# Créer une étiquette de publication annotée
git tag -a v2.4.1 -m "Release version 2.4.1"

# Envoyer l'étiquette au serveur
git push origin v2.4.1

# Voir toutes les étiquettes dans le dépôt
git tag -l "v2.*"

# Créer une branche hotfix à partir d'une étiquette spécifique
git checkout -b hotfix/crash-fix v2.4.1

Hiérarchie des branches Git Flow

Comprendre la hiérarchie des branches dans Git Flow est la base pour organiser correctement le développement collaboratif. Chaque type de branche a sa propre source, son objectif et ses règles de fusion.

• Main (Niveau 1) — la branche racine, contient uniquement les versions de publication. Créée lors de l'initialisation d'un dépôt.
• Develop (Niveau 2) — créée à partir de main au début du projet. Contient le code d'intégration de toutes les fonctionnalités.
• Feature (Niveau 3) — créée à partir de develop. Développement isolé de fonctionnalités individuelles.
• Release (Niveau 2) — créée à partir de develop. Préparation d'une publication spécifique pour le lancement.
• Hotfix (Niveau 2) — créée à partir de main. Corrections urgentes d'erreurs critiques de production.

Règle importante : feature n'est jamais fusionnée directement dans main. feature → develop → release → main est la chaîne de fusion correcte. Enfreindre cette règle annule le but même du modèle Git Flow.

Exemples de commandes pour travailler avec main

Considérons un scénario : l'équipe a terminé la préparation de la publication v2.5.0. La branche release a été révisée et est prête à être fusionnée dans main. Après la fusion, une étiquette est créée et la publication est lancée.

# Basculer vers main et mettre à jour
git checkout main
git pull origin main

# Fusionner la branche release vérifiée
git merge --no-ff release/2.5.0

# Créer une étiquette de publication
git tag -a v2.5.0 -m "Release 2.5.0 - Payment integration"

# Envoyer main et l'étiquette au serveur
git push origin main --tags

Le drapeau --no-ff (sans avance rapide) garantit la création d'un commit de fusion, même si la fusion aurait pu être effectuée en déplaçant simplement le pointeur. Cela préserve l'information que les modifications provenaient d'une branche release, ce qui facilite l'analyse de l'historique.

Travailler avec hotfix via main

Si une erreur critique est découverte en production, le processus diffère d'une publication normale. Un hotfix est créé à partir de main et, après correction, est fusionné à la fois dans main et dans develop.

Si une erreur critique est découverte en production, le processus diffère d'une publication normale. Un hotfix est créé à partir de main et, après correction, est fusionné à la fois dans main et dans develop.

# Créer une branche hotfix à partir de main
git checkout main
git checkout -b hotfix/2.5.1-crash-fix

# Corriger et faire un commit
git add src/fix/
git commit -m "Fix crash on login screen"

# Fusionner hotfix de retour dans main
git checkout main
git merge --no-ff hotfix/2.5.1-crash-fix
git tag -a v2.5.1 -m "Hotfix 2.5.1"
git push origin main --tags

# Fusionner hotfix également dans develop
git checkout develop
git merge --no-ff hotfix/2.5.1-crash-fix
git push origin develop

# Supprimer la branche hotfix
git branch -d hotfix/2.5.1-crash-fix