Legal stuff about this site and your private life:

  • We use a cookie to keep your preferences (language, NSFW status, login status) during navigation.
  • We use your local storage to save the announces you closed (like this one).
  • We don't save informations you don't give
  • We don't share your email address if you comment or register
  • There is no tracker of any kind.

If you're not OK with this, move your way.

Depuis deux ans maintenant, je travaille régulièrement avec l'équipe d'Opus Codium. Nous avons un workflow concernant la gestion de nos dépôts Git que je souhaitais partager avec vous.

Principes de base:

  • Rien n'est mergé nulle part sans revue
  • Rien n'est mergé si la MR ne passe pas le CI
  • Rien n'est mergé si des discussions sont en cours sur une MR (non résolues)
  • Personne ne pousse directement sur master (ni sur aucune branche sensible)
  • Une MR est ouverte au plus tôt
  • Nos dépôts avancent en "fast-forward only": pas de merge commits (question de goût)
  • Nous commitons en anglais (et nous codons en anglais) : sur des projets opensource, les contributions doivent venir de n'importe où.

Workflow: le collaborateur a le droit de créer des branches sur le dépôt

  • Récupération de la branche de départ
  • Création d'une branche de travail
    git checkout <branch>
    git pull
    git checkout -b new-feature
    # ou, si on en a besoin:
    git fetch --all
    git checkout -b new-feature origin/<branch>
    
  • Ouverture d'une MR en "WIP"
    • envoi de la branche
      git push -u origin new-feature
      
    • Ouverture de la MR sur gitlab (via le lien donné lors du push, ou via l'interface)
    • Assignation de la MR à soi même
    • Labels or not labels, that's the question
  • Travail local:
    • Micro commits, des fois à l'arrache (le rebasage interactif sera ton ami)
      git add --patch # -p pour les intimes
      git commit --message='message' # -m 'message'
      
    • Pousser de temps en temps:
      git push
      git push --force # -f pour les pressés
      
      • le CI donne une idée de ce qui ne va pas sans empêcher de travailler en local
      • les collègues peuvent passer s'il ont deux minutes et voir ce qu'il se passe

Une fois le travail terminé (= la feature/le fix est fini, le CI passe):

  • Rebase interactive pour nettoyer ses commits
    git rebase --interactive <source-branch>
    # ou
    git rebase --interactive origin/<source-branch>
    
  • Rebase sur la branche cible avant de pousser (et correction des conflits si nécessaire)
    git fetch --all
    git rebase origin/<branch>
    
  • Pousser les commits propres
  • Assignation de la MR à quelqu'un pour révision
  • Revue par les pairs
    • Résoudre les problèmes relevés (nouveaux commits ou correction des commits précédents)
    • Merge de la MR dans la branche cible (et la branche source est supprimée)
  • \o/

Workflow: le collaborateur n'a pas accès au dépôt en écriture:

  • Fork du dépôt
  • Ajout du dépôt "upstream" en remote du dépôt localement cloné (pour les rebases)
  • Création d'une MR entre son dépôt et le dépot d'origine
  • Le collaborateur est encouragé à suivre les guidelines précédentes, de toutes façons, si il ne les suit pas, son travail ne sera pas mergé
  • \o/

Notes

  • On ne pousse pas de vieux code commenté : Git est là pour l'historique, git blame est là pour retrouver ses petits
  • git add ., c'est le mal. git add -p c'est bien.
  • Git est votre ami; ce n'est pas seulement un "moyen de sauvegarder" son code ; il raconte l'histoire du projet :
    • un historique propre et lisible est plus souvent relu et parcouru
    • des commits qui font ce qu'ils disent permettent de limiter les problèmes de conflits aux fonctionnalités ciblées ("mais pourquoi c'est là ça ?").
    • un commit compréhensible hors contexte est un plus pour l'équipe : pas besoin de regarder ce qui est modifié pour savoir ce qui est fait.
    • si tout le monde fait attention à sa façon de commiter, le projet s'en trouve renforcé, et les humains heureux de comprendre ce qui est fait.
  • Préférez les petits commits qui ne font qu'une seule chose: c'est plus facile à réviser
  • Trouvez un moyen de nommer vos commits de façon unie:
    • https://chris.beams.io/posts/git-commit/
    • nous préfixons le message par un contexte. ex:
      • Users: add password support
      • Posts: fix title rendering
    • pour les commits un peu complexes, un message supplémentaire est le bienvenu. ex:
      Posts: fix title rendering
      
      Title headers were displayed outside of the frame, due to incorrect markup and CSS.
      cf: https://gitlab.ourcompany.com/.../issues/1
      source: http://howto.com/create-html-headers
      

Git add -p ou --patch, késako ?

Un git add . va ajouter tous les fichiers modifiés (et les fichiers non suivis) en staging. Hors souvent, on a des fichiers modifiés avec des changements qui pourraient être explosés dans plusieurs commits, ou même encore que l'on ne veut pas voir commités.

Utiliser git add -p va permettre de choisir dans les fichiers modifiés ce que l'on souhaite passer en staging (et donc mettre dans notre prochain commit).

Un example de sortie:

diff --git a/app/assets/stylesheets/_variables.scss b/app/assets/stylesheets/_variables.scss
index f8ce65c..3043d4a 100644
--- a/app/assets/stylesheets/_variables.scss
+++ b/app/assets/stylesheets/_variables.scss
@@ -31,7 +31,7 @@ $color-borders: transparentize($color-base, .9);
 $color-in-card-borders: transparentize($color-base, .8);
 
 // Links
-$link-color: $color-grey-800;
+$link-color: $color-grey-700;
 $link-color-hover: $color-grey-600;
 
 // User content colors
Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? y <------- là je choisis de "stager" cette modif
@@ -45,6 +45,7 @@ $content-upload-bg: $color-white;
 // Classifiers
 $language-bg: $color-green-100;
 $license-bg: $color-orange-200;
+// $some-useless-change: #333;
 $tag-bg: $color-blue-100;
 $user-bg: $color-blue-grey-100;
 
Stage this hunk [y,n,q,a,d,K,g,/,e,?]? n <------- là je choisis de ne pas "stager" cette modif

Les modifications non acceptées restent dans l'index : elles ne sont pas perdues et pourront par exemple faire partie d'un nouveau commit.

Attention cependant : git add -p proposera uniquement d'ajouter les modifications des fichiers suivis par git (les "nouveaux" fichiers ne seront pas proposés). Il faut donc être vigilant et bien vérifier le status du dépôt avec git status avant de faire un git commit.

Remerciements

Merci à l'équipe d'Opus Codium pour la première relecture.

Leave a comment

You want to react to this content or ask something to the author? Just leave a comment here!

Note that the comments are not publicly visible, so don't worry if you don't see yours.

All the information you give will only be visible to the author. We don't share anything with anyone.

Don't fill this field if you want this form to be saved.