Workflow Git : développer des fonctionnalités en parallèle

Par Maxime Bréhin • Publié le 2 octobre 2017 • 3 min

Précédemment dans « Workflow Git »…

1. Objectifs et principes généraux
2. Développer des fonctionnalités en parallèle (cet article)
3. Livrer et maintenir des versions publiques
4. Corriger des bugs
5. Définir les conventions d’un projet

Développer des fonctionnalités en parallèle

Que nous travaillions seul ou à plusieurs, il est un réflexe important à acquérir et qui consiste à isoler systématiquement chaque ensemble de développement. Cet isolement se fait à l’aide des branches.

L’inconvénient que cela pose dans un workflow centralisé, c’est l’aspect mono-branche du dépôt partagé (souvent en SVN/CVS) qui rend difficile la parallélisation des tâches.
Admettons que nous ayons au sein d’une équipe des groupes de développeur·se·s travaillant chacun·e à un sous-ensemble fonctionnel du projet :

• Estelle et Xavier sur feature-1,
• Jonathan et Marie sur feature-2.

Avec un dépôt central mono-branche unique, avoir une version stable à un instant donné relève de l’impossible, puisque quand feature-1 sera terminée, il est fort probable que feature-2 soit encore en cours de développement et donc pollue le projet, empêchant un déploiement en production.

En isolant alors le développement de chaque lot sur une branche dédiée, on s’assure que les lots rapatriés sur la branche centrale/de production (ici master) seront terminés.
Ce principe est couramment appelé Feature Branching car il encourage la création d’une branche par fonctionnalité.

Création de la branche feature-1 par Estelle et partage via le dépôt distant :

git checkout -b feature-1 master
git push --set-upstream origin feature-1 # option courte : -u

Xavier récupère la nouvelle référence de branche pour pouvoir travailler dessus également :

git fetch origin
git checkout feature-1
# (développement de la tâche f1-X)
git commit -am ‘Message concis décrivant f1-X’
# (développement de la tâche f1-Y)
git commit -am ‘Message concis décrivant f1-Y’
# (une fois ses tâches terminées, en fin de journée ou quand le partage est nécessaire :)
git push

Estelle et Xavier réalisent alors des tâches sur cette branche, déclinant au besoin des sous-branches sur leur poste/en local.

En parallèle, Jonathan a également créé une branche.
Il commence à travailler dessus et produit quelques commits avant de la partager sur le dépôt central pour que Marie puisse également y participer :

git checkout -b feature-2 master
# (développement de la tâche f2-A)
git commit -am ‘Message concis décrivant f2-A’
# (partage à Estelle :)
git push --set-upstream origin feature-2 # option courte : -u

Marie récupère cette branche et y contribue :

git pull origin
git checkout feature-2
# (développement de la tâche f2-B)
git commit -am ‘Message concis décrivant f2-B’

Une fois le travail terminé par l’un des deux groupes, disons feature-2 par Marie et Jonathan, cette branche pourra être fusionnée sur sa branche de départ, à savoir master.
Marie se charge de ce travail :

git checkout master
git merge --no-ff feature-2
git push origin master

Elle en profite également pour supprimer l’étiquette de branche locale et son équivalent distant (cela ne supprime pas l’historique, juste l’emplacement du nom de branche) :

git push --delete origin feature-2
git branch --delete feature-2

La branche master est alors dans un état stable et ne contient que feature-2, pas feature-1.
Un déploiement de l’application est donc envisageable depuis la branche master.

Marie et Jonathan peuvent ensuite débuter de nouvelles tâches pour d’autres sous-ensembles fonctionnels sur des branches dédiées bien entendu.
Quant à Xavier et Estelle, ils pourront fusionner leur branche dans master quand celle-ci sera terminée. En cas de conflits avec les modifications apportées par feature-2, une fusion manuelle pourra s’avérer nécessaire. Heureusement, pour l’essentiel des différences, les algorithmes de Git effectueront un traitement automatique.

Note : l’option --no-ff force la conservation de la « bosse » de la branche feature-2dans l’historique (à savoir son point de départ et d’arrivée depuis et dans master), à l’instar du « fast-forward » , option par défaut (--ff). Cette option peut-être modifiée dans la configuration globale (git config --global merge.ff false) ou locale au projet (git config merge.ff false).

Bien nommer ses branches

Pour ne pas nous perdre dans nos schémas de branches il est important de définir des conventions de nommage tout comme nous l’avions vu précédemment pour nos commits.

Le dernier article de cette série vous aidera à formaliser ces besoins et définir vos conventions.

Et maintenant ?

Allez explorer le reste de cette série d’articles !

1. Objectifs et principes généraux
2. Développer des fonctionnalités en parallèle (cet article)
3. Livrer et maintenir des versions publiques
4. Corriger des bugs
5. Définir les conventions d’un projet