A chaque message de commit doit être associé un préfixe :

• “feat” pour une nouvelle fonctionnalité / une évolution
• “fix” pour la correction d’un bug
• “docs” pour la mise à jour d’une documentation
• “style” pour les changements qui n’affectent pas le fonctionnement du code (espaces, formattage, point-virgule manquants, etc…)
• “refactor” pour une modification du code qui n’est ni un correctif, ni une évolution
• “perf” pour une modification de code qui améliore les performances
• “test” pour ajouter ou compléter un test
• “chore” pour les changements du process de build ou d’une librairie / d’un outil tiers

Juste après le préfixe, il est possible de préciser le nom de la fonctionnalité impactée entre parenthèses (non obligatoire).
Puis le séparateur “:” doit apparaître.
Et enfin vous devez entrer un message de commit.

Exemples de messages de commit respectant ces conventions :
feat(profile form): add birthdate field
fix(profile form): fix birthdate validity check
refactor: remove console.log

Le nom des nouvelles branches créées doit respecter les règles suivantes :

Commencer par un préfixe précisant le type : “feat/” ou “fix/”

• Le “slash” est important.
• Contenir l’identifiant de l’application de gestion des bugs et évolutions
• Les mots doivent être écrits en lettres minuscules
• Les mots doivent être séparés par un tiret : “-”
• Idéalement, utiliser l’anglais
• Exemples :
• feat/123456-my-new-feature
• fix/123456-my-bug-fix

Pourquoi mettre un “slash” après “feat” ou “fix” ?
Cela permet d’avoir un nom de branche lisible qui ressemble à une arborescence de répertoire. Certains logiciels comme Gitkraken utilisent cette arborescence pour regrouper les features et les fixes.

Pourquoi des tirets plutôt que des underscores ?
Dans les normes de nommage les plus utilisées (pour les fichiers par exemple), c’est le tiret qui est privilégié. On reproduit donc ces normes dans le nom des branches.

– source: https://medium.com/codeshake/git-placez-le-rebase-au-centre-de-votre-strat%C3%A9gie-de-versioning-9b295e78e6ff

Branche de prod : master

On crée une branche de développement

git checkout master
git checkout -b develop

Pour une nouvelle fonctionnalité, on crée une branche feat/xx en partant de master pour éviter d’embarquer d’autres features qui serait en court de test sur develop

git checkout master
git checkout -b feat/nouvelle-fonctionnalité

Pour la faire tester en dev

git checkout develop
git merge --no-ff feat/nouvelle-fonctionnalité

Lorsque la feature est terminé, on la merge sur develop et master puis on supprime la branche

git checkout develop
git merge --no-ff feat/nouvelle-fonctionnalité
git checkout master
git merge --no-ff feat/nouvelle-fonctionnalité
git branch -d feat/nouvelle-fonctionnalité

Même principe pour les branches hotfix

Si vous avez poussé les branches sur le dépôt distant, n’oubliez pas de les supprimer. Vérifier la liste des branches

git branch -a

Supprimer une branche

git branch -d feat/nouvelle-fonctionnalité

Supprimer une branche sur le dépôt

git push origin --delete feat/nouvelle-fonctionnalité

Renommer une branche

git checkout feat/nouvelle-fonctionnalité
git branch -m feat/new
git push origin -u feat/new
git push origin --delete feat/nouvelle-fonctionnalité

Voir toutes les branches (locales et distantes)

git branch -a

Je veux revenir en arrière de plusieurs commit sur une branche

git checkout feat/new
git reset --hard <numéro de commit>
git push --force

On pourrait utiliser rebase mais vu que ça réécrit les commits, ça devient le bazard avec le dépôt distant et ça génère beaucoup de conflit

Et on rebase la branch develop pour qu’elle soit raccord avec la prod

git checkout develop
git rebase master

Si on veut mettre à jour sa branche feat/xxx, on l’a rebase par rapport à master

git checkout feat/nouvelle-fonctionnalité
git rebase master
ou
git rebase -i master

On peut aussi rebase develop sur master pour être propre

git checkout develop
git rebase master

40 problèmes / solutions : https://youtu.be/WhlkrA8emQk?si=GOIyHnzDEAzJmUqy