Vers un meilleur workflow Git

Nous avons rassemblé des méthodes pour utiliser Git plus efficacement.

0. Structure du dépôt
   • Git étant un système de gestion de versions distribué, il peut être organisé de différentes façons : centralisée, à la GitHub/GitLab, hiérarchique, etc.
1. Structure des branches
   • GitHub Flow : on garde une branche Main, puis on crée des branches de fonctionnalité ou de correction de bug avant de les fusionner après retour.
   • Git Flow : mieux adapté à un développement traditionnel qu’à des déploiements fréquents.
     • Créer une branche Feature puis la fusionner dans la branche Develop
     • Lorsqu’une branche Develop est suffisamment mûre, on crée une branche Release (Stage), sur laquelle on ne fait que des corrections de bugs avant de la fusionner plus tard dans Develop et Master
     • Quand la release est prête, on la fusionne dans la branche Master, qui ne reçoit ensuite que des hotfixes
   • GitLab Flow : une forme intermédiaire entre Git Flow, complexe, et GitHub Flow, trop simple.
     • À la place de la branche Release temporaire de Git Flow, on utilise une branche Stage maintenue en continu
     • Les hotfixes sont appliqués à Production et Stage, et les corrections de bugs à Stage et Develop
   • Perforce Stream : avantageux lorsqu’il faut gérer plusieurs releases.
     • Si un bug est corrigé dans Release, la correction est propagée vers Main-Develop
     • Si une fonctionnalité est développée dans Develop, on résout les conflits puis on la répercute dans Main
   • Basé sur le trunk : une tentative d’utiliser Main (Master) plus efficacement, surtout adoptée par les grandes entreprises tech.
     • Main est conservée durablement, et on ne fait pas de corrections de bugs séparées dans les branches de release
     • Les fonctionnalités sont fusionnées désactivées via des flags afin de garder en permanence le code le plus récent
2. Commits
   • Convention : la convention Angular est souvent utilisée, mais il est aussi possible d’adopter des emojis ou autre selon l’accord de l’équipe
   • Granularité : il faut viser la plus petite unité possible, mais l’équipe doit aussi se mettre d’accord sur ce que signifie cette unité minimale
     • Il est possible de segmenter les changements en hunks pour les mettre en staging plus finement
     • C’est pratique si l’on peut comparer les changements au niveau des deltas
   • Commits spéculatifs et historique linéaire : une manière de committer souvent pour conserver le contexte tout en gardant un historique linéaire
     • Sauvegarder le travail chaque fois que nécessaire, par exemple avec stash ou lors d’essais de prototype
     • Faire un checkout partout où c’est nécessaire, continuer à committer, puis conserver un historique linéaire via rebase
     • L’outil git-branchless peut être utile
     • git sl : visualise bien l’historique des commits en suivant les branches anonymes
     • git prev et git next : facilitent le checkout à l’unité précédente/suivante
     • git sync : rebase sur Main
     • git move : permet de déplacer un commit où l’on veut
     • git restack : restaure l’ordre de l’historique lorsque rebase ou commit --amend l’ont perturbé
     • git undo : permet d’annuler
3. Fusion
   • Patch Stack : une façon de faire de la revue en découpant en fonctionnalités[1/3], fonctionnalités[2/3], fonctionnalités[3/3], etc.
   • Conflits de premier ordre : Jujutsu, compatible avec Git, enregistre les conflits dans les commits, ce qui réduit la réapparition ultérieure de conflits déjà résolus
   • 3 Way Diff : dans le cas de Jujutsu, lorsqu’un conflit survient, Base-Ours est affiché sous forme de diff et Theirs comme snapshot, ce qui est intuitif. En revanche, on peut avoir besoin de la coloration syntaxique de l’IDE/de l’éditeur ou de consulter un diff Base-Theirs
   • Conflits binaires : Git laisse généralement l’utilisateur se débrouiller lorsqu’un conflit survient sur un fichier binaire, mais l’auteur a personnellement créé un petit outil pour générer les fichiers Base et Their
   • Patches et e-mail : présentation d’une méthode de fusion plus traditionnelle (?)
     • git request-pull est une commande pour créer une pull request
     • Avec git send-mail, on peut envoyer des patches par e-mail, puis les appliquer avec git am
4. Autres méthodes de gestion
   • Worktree : en partageant l’historique Git, il est possible de checkout seulement les fichiers de travail à plusieurs endroits, comme avec les branches SVN, afin d’avancer sur plusieurs tâches en parallèle
   • Git LFS : une méthode pour gérer les fichiers volumineux
   • Clone partiel et checkout partiel : cloner partiellement pour réduire le temps de téléchargement, puis checkout partiellement pour ne travailler que sur les répertoires voulus
   • Scalar : facilite la gestion de dépôts gigantesques grâce aux efforts de Microsoft