Travailler avec Git, le workflow d'Opus Codium et ExperimentsLabs

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.

[github-user-card:opus-codium]

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