====== 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'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


====== rebase ======

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

===== Tuto =====

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