Git dev

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’autre feature

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

Pour la faire tester en dev

git checkout develop
git merge feat/nouvelle-fonctionnalité

Si on a un hotfix à faire

git checkout develop
git checkout -b fix/xxx

On peut appliquer directement le hotfix en prod

git checkout master
git merge fix/xxx
git branch -d fix/xxx

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

Mettre en prod sa feature, merger sa branche sur le master

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

On peut aussi rebase develop sur master pour être propre

git checkout develop
git rebase master

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

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