Différences

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

--- prog:git [2025/11/21 13:24] – Réorganisation complète root
+++ prog:git [2025/11/24 11:32] (Version actuelle) – Ajout de "Retravailler l'historique" root
@@ Ligne 185: / Ligne 185: @@
 ====Supprimer un submodule====
-  * ''git submodule deinit <path_to_submodule>''
+<code bash>
-  * ''git rm <path_to_submodule>''
+git submodule deinit <path_to_submodule>
-  * ''git commit-m %%"Removed submodule"%%''
+git rm <path_to_submodule>
-  * ''rm -rf .git/modules/<path_to_submodule>''
+git commit -m "Removed submodule"
+rm -rf .git/modules/<path_to_submodule>
+</code>
 [[https://gist.github.com/myusuf3/7f645819ded92bda6677#gistcomment-2650640|How effectively delete a git submodule?]] {{ :prog:git:how_effectively_delete_a_git_submodule._github_2019-10-22_13_32_38_.html |Archive du 18/07/2018 le 22/10/2019}}
@@ Ligne 682: / Ligne 684: @@
 Exemple [[https://github.com/boostorg/boost/tree/master/libs|Boost]]. Les librairies n'ont pas de submodule.
-Avantages :
-  - Si 2 librairies dépendent d'une 3ème, la 3ème est forcément à la même version.
-  - Il est difficile pour chaque dépôt de connaitre la version de ses dépendances.
 Inconvénients :
-  - Nécessite un super projet pour compiler. Au choix : soit un super projet qui clone tout, soit un super projet par projet à compiler.
+  - Nécessite un super projet pour compiler. Au choix : soit un super projet qui clone tout (Boost), soit un super projet par projet à compiler.
-  - Risque de dépendances circulaires entre projets.
+  - Dépendances circulaires difficilement détectables entre projets.
   * Submodule dans chaque projet
-Avantages et inconvénients inversés par rapport à la solution précédente.
+Inconvénients :
+  - Clonage récursif infini si dépendances circulaires.
+  - Si 2 librairies dépendent d'une même 3ème, la 3ème peut être a des versions différentes sur les 2 premières librairies.
   * Gestionnaire externe (vcpkg)
@@ Ligne 701: / Ligne 701: @@
 Inconvénients :
-  - Nécessite de gérer la version des paquets. Peut être pénible pendant la phase de developpement ou nécessite de créer un port pour chaque branche et de l'utiliser en mode ''%%--head%%''.
+  - 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.
-Avantages :
+{{:prog:git:git-merge-conflict-2.png?419|}}
-  - Version commune des dépendances entre tous les dépôts.
+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=====