tuto git » traite d’aspects plus avancés de l’utilisation des branches avec Git. Il traite notamment le maintient dans un état exploitable de lhistorique d’évolution d’un projet. Pré-requis: Les commandes de base, ainsi que la gestion des conflits et l’utilisation des branches avec Git sont assimilés. L’environnement de simulation multi-développeur est mis en place. Il fait suite à l’article « Utiliser les branches ».

1. Forcer l’historisation d’une branche.

Dans l’article précédent, nous avons traité du cas de figure où une branche est utilisée pour isoler les travaux en lien avec une évolution fonctionnelle importante. Cette évolution fonctionnelle faisant partie d’un découpage ifonctionnel identifié du projet, la trace de cette branche a été volontairement gardée dans l’historique. Dans le cas actuel il s’agit de traiter du cas où les travaux a effectuer sont de moindre importance et en tout cas ne faisant pas partie d’un découpage fonctionnel identifié. Ce cas peut être par exemple celui de la correction d’un bug ou celui d’une évolution mineure. Ces évolutions ne sont pas à garder, en tant que branche séparée, dans l’historique du projet. La raison est d’éviter d’avoir trop de dérivations dans l’évolution qui rendrait l’historique illisible, voire inexploitable. Pour l’illustration, on suppose que DEV2 doit corriger deux bugs de présentation identifiés dans le traitement de la conjugaison au passé composé. Pour cela il crée une branche pour isoler ses modifications:

git checkout -b bugfix

Cette commande est une contration (raccourci) des deux commandes de création et bascule vers une nouvelle branche. Suite à cela,; DEV2 édite le fichier parler_passe et corrige la ligne 4 comme suit (espace manquant entre “as” et “parlé”):

tu as parlé
au lieu de >>
tu asparlé

Ensuite DEV2 valide sa correction:

git commit -am "Correction de bug: espace entre 'as' et 'parlé'"

En même temps DEV1 (cd /pcdev1/conjparler), chargé de développer la conjugaison au future, effectue les modifications:

git checkout -b future
vi parler_future
vi conjugue_parler.sh

Le contenu de parler_future:

echo ""
echo -e "\t\tFUTURE"
echo -e "\t\t------"
echo -e "Je parlerai\t\tNous parlerons"
echo -e "Tu parleras\t\tVous parlerez"
echo -e "Il parlera\t\tIls parleront"

Le nouveau contenu de conjugue_parler.sh:

#!/bin/bash
source parler_present
echo ""
source parler_passe
echo ""
source parler_future

Suite à cela, DEV2 valide ses modifications et les publie:

git add parler_future
git commit -am "Ajouter la conjugaison au future simple"
git checkout master
git merge future --no-ff
git push

Remarquer le paramètre –no-ff de la commande merge. Ce paramètre permet de forcer l’historisation de la branche future. L’utilisation de ce paramètre est justifiée par le fait que master n’a pas changé depuis le moment de la création de la branche. Dans ces conditions un merge simple aurait été considéré comme une simple avancée de la branche master.

2. Eviter l’historisation d’une branche.

En même temps, DEV1 de son côté (cd /pcdev1/conjparler), corrige un deuxième bug en supprimant deux tirets en trop dans le soulignement du titre “PASSE”. Ensuite il valide, puis bascule sur la branche master:

vi parler_passe
git commit -am "Correction du soulignement du titre PASSE"
git checkout master

A ce niveau, les corrections de bug ayant pris du temps, DEV2 doit mettre à jour sa copie locale:

git pull

Il se rend compte alors que la branche master a évolué. Cela a pour conséquence que s’il effectue un merge simple la branche bugfix va être inscrite dans l’historique des évolutions. Ceci “pollue” cet historique inutilement. Pour éviter cela DEV2 doit utiliser la commande rebase avant le merge:

git rebase master bugfix
git checkout master
git merge bugfix
git push

La commande rebase a pour résultat de repositionner l’origine de la branche bugfix sur la dernière mise à jour récupéré du dépôt distant. Ce repositionnement évite l’inscription de cette branche dans l’historique et rend l’évolution parfaitement linéaire comme indiqué dans le graphe (git log –graph): Sans l’utilisation de la commande rebase, on aurait eu une troisième branche parallèle à “future”.

3. Suppression des branches inutiles

Une fois fusionnées les branches ne sont plus utiles. Il convient donc de les supprimer. DEV1 doit supprimer la branche bugfix qui est locale à sa copie:

git branch -D bugfix

DEV2 supprime de son côté la branche locale future:

git branch -D future

Le cas de la branche passecompose est différent car elle a été publiée sur le dépôt distant. DEV2 pourra la supprimer en local et sur le serveur avec les commandes:

git branch -d passecompose
git push --set-upstream origin passecompose

La première commande permet de supprimer la branche dans la copie locale (cf. l’article utiliser les branches). La deuxième permet de porter cette suppression sur le dépôt distant.]]>