====== Git dev ======


===== Convention de nommage =====

**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

===== Gestion de branches pour le dev =====

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



===== Tuto =====

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