Différences

Ci-dessous, les différences entre deux révisions de la page.

--- prog:git [2025/11/24 10:03] – [Gestion des dépendances] : mise à jour root
+++ prog:git [2025/11/24 11:32] (Version actuelle) – Ajout de "Retravailler l'historique" root
@@ Ligne 703: / Ligne 703: @@
   - Travail supplémentaire pour maintenir les ports vcpkg. Dans le cas de vcpkg, il faut créer un port par branche de dev et l'utiliser en mode ''%%--head%%''.
   - Si on travaille sur des dépendances, ça oblige à commiter à chaque test et vcpkg doit tout recompiler.
+====Rebase / amend / force push====
+Faut-il autoriser les rebases ou non ? Il y a 2 parties irréconciliables : avoir un arbre git propre (et autoriser les rebases) et avoir un arbre qui mémorise l'évolution de l'écriture du code (et interdir les rebases).
+===Retravailler l'historique===
+  * Sur les branches de développement
+Je suis pour les modifications. C'est un espace de travail et de bac à sable qui peut être utilisé pour tester le code sur la CI. De plus, ça permet de sauvegarder le code quotidiennement et de voir l'état de la CI.
+⚠️ Autoriser de retravailler une branche interdit de se greffer sur une branche de développement d'un dépôt enfant. La branche de développement de l'autre dépôt peut aussi être retravaillée. On risque de se retrouver avec un historique des commits inutilisables dans la branche de developpement du dépôt parent.
+Par contre, il ne faut fusionner que les commits qui concerne une même tâche et ne pas fusionner tout l'historique (squash) pour avoir l'historique le plus petit possible.
+  * Modifier le commit de base d'une racine
+Lors d'un merge, il faut utiliser ''%%--no-ff%%'' afin de garder visuellement la branche dans l'arbre git.
+L'intérêt de modifier le commit de base est d'éviter d'avoir un arbre git qui ressemble à ça.
+{{:prog:git:git-large-tree.png?650|}}
+Mais plutôt d'avoir :
+{{:prog:git:git-thin-tree.png?427|}}
+Oui, c'est plus joli. Mais est-ce c'est nécessaire de l'imposer ?
+Si beaucoup de personnes travaillent en même temps sur le projet, l'imposer est ingérable. Peut-être l'imposer si le commit de base a plus d'une semaine / un mois par rapport au commit le plus récent dans la branche de destination ?
+S'il n'y a pas de conflit lors du merge, ne pas l'imposer.
+En cas de conflit lors du merge, il ne faut pas résoudre le conflit en local avant de merger. Sinon, la résolution des conflits seront dans le commit de merge et c'est contre-intuitif de lire le commit de merge pour lire les modifications.
+{{:prog:git:git-merge-conflict.png?808|}}
+Il faut appliquer la technique de Gitlab avec le double merge. On merge la branche de destination vers la branche de dev pour résoudre les conflits puis on merge la branche de dev vers la branche de destination. Il y a toujours un commit de merge qui contient la résolution des conflits mais il est séparé du commit de merge final.
+{{:prog:git:git-merge-conflict-2.png?419|}}
+On peut aussi faire des rebases régulièrement afin d'éviter d'avoir trop de conflits à gérer. Mais il peut être plus facile de résoudre tous les conflits en une fois.
 =====Messages d'erreur=====