Thème : Utilisation du GIT pour suivi des modifications et de la contrôle de version

But : Travailler avec Git Localement. Travailler avec les branches Git localement. Travailler
avec Git et un référentiel distant
A retenir :
Le rapport doit être fait en format électronique (format doc ou pdf) et doit être uploader sur l’affectation
du TP1. Répondre dans le rapport à tous les demandes écrites avec la couleur rouge foncé.
La soutenance doit se faire le 21 septembre 2018, l’envoi préalable du rapport est indispensable. Chaque
semaine de retard est pénalisé avec (-2) de la note pour la soutenance.
Les absences aux TP sont récupérées après la confirmation de payement au décanat sur l’horaire de
consultations prévues.

Installation :
Pour installer Git
Dans cette tâche de laboratoire, vous allez installer Git sur votre ordinateur. Trois sections distinctes couvrent
l’installation sous Windows, Mac et Linux. Choisissez le jeu d'étapes correspondant à votre système d'exploitation.

Installez Git sur Windows

1. Pour installer sur Windows, vous pouvez utiliser le programme d'installation binaire disponible sur le site Web
de git.
2. Visitez http://git-scm.com/download/win et le téléchargement devrait commencer automatiquement

Installer Git sur un Mac

Dans cette tâche, vous allez installer Git sur un ordinateur Mac. Ces étapes couvriront l'installation à partir d'un outil de
ligne de commande Xcode.

Si Xcode n'est pas installé sur votre machine, vous pouvez l'installer depuis l'App Store.

1. Ouvrez l'application Terminal sur votre Mac

2. Tapez la commande git. Si Git n'est pas déjà installé, vous devez être invité à l'installer.

REMARQUE: L'étape 2 suppose que Xcode est installé sur votre Mac. Si ce n'est pas le cas, vous devrez ouvrir l'App Store
et installer Xcode, qui est gratuit auprès d'Apple.

Une alternative consiste à utiliser le programme d'installation binaire disponible à l'adresse http://git-
scm.com/download/mac. Cependant, il peut être nécessaire de modifier vos Préférences Système pour permettre
l'installation de logiciels de tiers.

Installez Git sur Linux

Dans cette tâche, vous allez installer Git sous Linux. Nous couvrirons yum et apt-get, selon la distribution que vous
utilisez.

1. Pour installer Git en utilisant yum, ouvrez un terminal et entrez la commande suivante :
sudo yum install git-all
2. Pour installer Git en utilisant apt-get (trouvé sur les distributions basées sur Debian), ouvrez un terminal et
entrez la commande suivante :
sudo apt-get install git-all
3. Suivez toutes les invites de l'installateur et Git sera automatiquement installé sur votre système

I. Travailler avec Git Localement

Nous allons créer notre premier référentiel Git et utiliser l'interface de ligne de commande de Git pour gérer les mises à
jour d'un fichier. Un référentiel est un endroit où les choses sont stockées. Dans le cas de Git, nous stockons notre code
ou nos fichiers et l'historique des modifications que nous effectuons. Nous travaillerons dans un référentiel de code
source local (repo) et, pour ce premier exercice, nous utiliserons un simple fichier texte. Commençons!

1. À l'aide d'une invite de commande ou d'une fenêtre de terminal sur votre ordinateur, créez un dossier
contenant tout le travail nécessaire à cet exercice. Appelons ça local-repo:
$ mkdir local-repo
2. Lorsque vous avez créé local-repo, naviguez dans le répertoire avec la commande cd local-repo.
3. L'une des premières commandes à apprendre lors de l'utilisation de Git est la commande status qui indique
l'état de notre référentiel. Alors, allons-y et tapez la commande suivante à l'invite et appuyez sur Entrée.
$ git status
Oups !, cette commande génère l'erreur suivante:
fatal: Not a git repository (or any of the parent directories): .git

Question 1: Qu'est-ce qui a causé l'erreur que nous venons de voir lorsque nous avons tapé git status
dans notre dossier?
4. À l'invite de commandes, exécutez la commande suivante pour initialiser le dossier en tant que référentiel git.
$ git init
Si tout s'est bien passé, vous recevrez un message indiquant qu'un référentiel Git vide a été initialisé dans votre
dossier. Essayons à nouveau l'état de Git.
5. Sur la ligne de commande, tapez la commande suivante et appuyez sur Entrée.
$ git status
Cette fois, vous devriez voir une sortie similaire à la capture d'écran suivante.

Ce que la sortie précédente nous dit, c'est que nous avons maintenant un dépôt et que nous sommes dans la branche
master de ce dépôt.

La branche par défaut est appelée master et dans cet exercice, nous ne traiterons que de cette branche unique
pour garder les choses simples.

Nous pouvons résumer ce que nous avons fait jusqu'à présent avec le diagramme suivant. Nous voyons ici que git
init convertit essentiellement un dossier standard, représenté par le rectangle jaune de gauche, en un dépôt Git
représenté par le cercle bleu à droite

Si vous affichez les fichiers cachés dans ce répertoire en utilisant ls -a (sous Linux / macOS) ou dir /a (sous
Windows), vous remarquerez un dossier appelé .git. Il est caché pour une bonne raison. Il contient la sauce secrète qui
fait de votre répertoire un référentiel et fait fonctionner Git. Vous verrez ce dossier dans chaque repo que vous créez. Je
l'appelle pour que vous sachiez que c'est là, mais vous aurez rarement besoin de toucher quoi que ce soit à l'intérieur.

6. Créez un nouveau fichier texte vide dans notre dossier local-repo. Nommez le fichier hello.txt.
7. Exécutez à nouveau le git status. Vous devriez voir la réponse suivante :

À ce stade, Git a détecté un nouveau fichier dans notre dossier et nous dit clairement que Git ne suit pas
actuellement ce fichier.
Du point de vue de Git, les fichiers peuvent se trouver dans l'un de ces états :
untracked: Git ne suit pas encore ce fichier, indiquant généralement que le fichier est nouveau.
tracked: le fichier fait partie de l'instantané Git et Git suit ses modifications.
unstaged: un fichier suivi a des modifications mais il n'a pas été mis en scène pour une validation.
staged: le fichier est prêt à être commis.
deleted: le fichier a été supprimé et doit être supprimé de Git.
Nous pouvons représenter ces états et comment un fichier les transforme comme suit:

Dans notre cas, notre fichier est nouveau et nous devons dire à Git de commencer à le suivre. Dans le diagramme ci-
dessous, nous montrons le fichier hello.txt à côté de l'état non suivi pour représenter son état actuel.
Donc, la prochaine chose à faire est de déplacer le fichier dans l'état Git staged, ce qui en fait un fichier mis en scène.
Nous faisons cela en utilisant la commande git add.

Question 2: Quelle commande Git devons-nous exécuter pour vérifier l'état d'un référentiel?
8. Dans le command prompt, tapez la commande suivante:
git add hello.txt
Il s’agit d’une commande assez silencieuse, ce qui signifie qu’il n’ya pas beaucoup d’impression dans la console
lorsque nous l’appelons. Cependant, un appel rapide à git status nous montre ce qui est arrivé à notre fichier
lorsque nous avons appelé cette commande, comme le montre la capture d'écran suivante.

Vous remarquerez peut-être que le message parle de modifications à commettre, mais vous venez de faire un
ajout. Ne laissez pas cela vous confondre. La commande add ne valide pas les mises à jour du dépôt, elle les met
simplement en scène.
Ainsi, notre fichier hello.txt se trouve dans la zone de transfert et est prêt à être validé dans le référentiel,
comme illustré dans le diagramme suivant.
9. Le format de la commande pour valider les modifications apportées à une branche est git commit -m "<message
de validation>" où vous remplacez <message de validation> par une description significative de la modification
apportée. Dans notre cas, engageons nos modifications avec la commande suivante.
git commit -m "add a new file that will eventually contain my name"
Le résultat sera le suivant :

Lorsque nous exécutons à nouveau git status, nous voyons que le message nothing to commit,
working tree clean, ce qui signifie que nous avons tout commis.
Le diagramme d'état suivant montre hello.txt dans l'état suivi après cette validation.
10. Jusqu'à présent, nous avons un fichier vide engagé dans notre branche. C'était un moyen simple de démontrer
les commandes de base de git. Maintenant, ajoutons du texte à notre fichier et suivons les mêmes étapes pour
valider la modification dans notre branche. Ouvrez hello.txt dans votre éditeur favori, ajoutez votre nom dans le
fichier et enregistrez-le. Dans la capture d'écran suivante, vous pouvez voir que j'ai ouvert le fichier dans VS
Code.
Le fichier passe de l'état suivi à l'état non synchronisé ou modifié, car Git le suit et remarque ces mises à jour.
Ceci est montré dans le diagramme suivant.

11. Dans la fenêtre du terminal ou l'invite de commande, vérifiez à nouveau l'état de votre dépôt après ces
modifications à l'aide du git status. Nous voyons ici que Git nous dit que le fichier hello.txt a été modifié.
Question 3: Quelle commande Git devons-nous exécuter pour ajouter nos changements?
12. Lancez git add hello.txt pour mettre en scène les modifications que nous avons apportées. Une fois
cette opération terminée, essayez à nouveau git status.
Cette fois, nos changements ont été mis en place et nous sommes prêts à les engager dans notre branche.
Comme le montre le diagramme d'état suivant, le fichier est à nouveau dans l'état intermédiaire.

13. Commitons nos modifications avec la commande suivante.

git commit -m "add my name to hello.txt"
14. Vous avez créé votre premier dépôt Git sur votre machine, y avez ajouté un fichier, modifié le fichier et effectué
plusieurs actions de validation et de validation. Si vous voulez un bon résumé de ce que vous avez fait pendant
cet exercice, tapez la commande suivante:
git log

II. Travailler avec les branches Git localement

Le diagramme suivant illustre le concept de branchement. Ici, nous avons un tronc principal, appelé maître.
C'est notre branche principale. Lorsque nous voulons travailler sur un corpus de code en toute sécurité loin de
master, nous créons une branche de fonctionnalités qui est un instantané de master au moment de sa création,
ainsi que les modifications que nous apportons. Lorsque nous sommes satisfaits de la fonctionnalité et que nous
sommes prêts à nous engager à expédier le code, nous mettons le code en maître et supprimons la branche. Ce
processus est répété tout au long du cycle de développement.

Branching n'est pas un nouveau concept dans le monde des systèmes de contrôle de version, mais il est facile de
travailler avec Git. Comme nous le verrons bientôt, les branches sont peu coûteuses à créer et la fusion des
modifications dans votre branche principale est relativement simple. Commençons à explorer!

1. La première commande à apprendre est git branch. Il nous indique quelle branche nous sommes
actuellement. Revenons à l'exemple local-repo précédente et tapez git branch. Mettre dans le rapport le
résultat.
 2. La commutation entre les branches dans Git s'appelle checking out a branch et nous utilisons la commande
git checkout. Pour créer une nouvelle branche, nous exécutons la commande avec l'argument -b.
Essayons cela avec la commande suivante:
git checkout -b new-feature
3. Le message résultant dans la console indique Switched to a new branch 'new-feature'. Nous pouvons
confirmer cela en lançant git branch à nouveau. Mettre dans le rapport le résultat.
4. Créez un nouveau fichier texte et appelez-le new-feature-file.txt.
5. Lister tous les fichiers du répertoire (ls sous macOS ou Linux, dir sous Windows). Vous devriez voir le fichier
répertorié.
6. Mettons en scène ce changement sur notre branche comme suit :
git add new-feature-file.txt
7. Vérifiez le statut de notre branche avec un appel à git status. Mettre dans le rapport le résultat
8. Avec nos modifications engagées dans la branche new-feature, passons au master avec git checkout
master
9. List all files in the directory (ls in macOS or Linux, dir on Windows). Mettre dans le rapport le résultat
10. Confirmez que vous êtes de nouveau sur master avec la commande git checkout master.
11. Pour voir quelles branches ne sont pas fusionnées avec master, tapez la commande suivante :
git branch --no-merged
12. Sur la ligne de commande, fusionnez notre branche en utilisant la commande suivante. C'est le même
commutateur utilisé dans l'opération de validation et nous permet d'ajouter un commentaire à notre fusion.
git merge --no-ff new-feature -m "merge new-feature branch"
13. Sur la branche master, listez tous les fichiers du répertoire et confirmez que new-feature-file.txt est
maintenant visible.
14. En règle générale, une fois que nous avons fusionné les propriétés d'une branche dans master, nous
supprimons la branche. Cela peut être fait avec la commande suivante:
git branch -D new-feature
Mettre dans le rapport le résultat
Dans le diagramme suivant, nous résumons les opérations effectuées dans cette leçon.

III. Travailler avec Git et un référentiel distant

Dans les exemples précédents, nous avons ajouté un fichier texte directement à la branche principale du
référentiel dans GitHub, tout en utilisant l'interface utilisateur GitHub. Le vrai pouvoir de la gestion de notre
source en utilisant un service comme GitHub qui s'exécute sur Git est que tout le monde dans une équipe peut
récupérer un instantané du code localement, travailler sur une mise à jour, puis repasser sur le serveur distant.
Voyons cela en action ensuite.

Cette partie suppose que vous avez un compte GitHub. S'il vous plaît créez un compte gratuit GitHub avant.

Vous devez déjà connaitre les comamndes suivantes :

 git status - checks the state of a repo

 git add - stages updates
 git commit - commits updates
 git checkout - switches branch
 git branch - lists existing branches
 git log - shows commit history

Un référentiel distant est un référentiel Git créé sur un serveur. Semblable à un partage de fichiers, il permet à
plusieurs personnes d'accéder au dépôt. Dans une équipe logicielle, chaque développeur peut accéder au
référentiel distant pour apporter des modifications. Bien qu'il soit possible d'aller directement sur le serveur et
d'apporter des modifications au dépôt, généralement nous retirons le dépôt local sur notre machine, apportons
des modifications et repoussons. Ceci est illustré dans le diagramme suivant. Nous avons ici un repo appelé our-
repo hébergé sur GitHub. Chaque membre de l'équipe fait un clone de ce repo sur sa machine locale. Ils
apportent des modifications à leur copie locale du dépôt et les développeurs effectuent une mise à jour des
modifications de la copie locale vers la télécommande. Bien sûr, avec tant d’activités dans la base de code, les
développeurs doivent maintenir leur clone local de la mise à jour à jour avec toutes les modifications apportées
par tous au serveur. Ils le font en effectuant un pull à intervalles réguliers et en fusionnant (merging) si
nécessaire. Nous pouvons démontrer ce flux de base en utilisant GitHub et un dépôt à distance dans cette leçon.

1. Dans votre compte GitHub, créez un nouveau dépôt avec les paramètres suivants:

 Name = devFI181
 Description = remote for TIDPP labs
 Public or Private: Public
 Initialize this repository with a README: check
2. Une fois le dépôt créé vous devez avoir une liste des commandes qui vous permet à l’accéder :
3. Exécuter les lignes du block … or create a new repository on the command line ou suivez l’étape 4
Par suite vous devez arriver sur la une page semblable à :
4. Sur la page principale de votre repo nouvellement créé sur GitHub, sélectionnez le bouton déroulant Cloner ou
télécharger, puis appuyez sur, puis sélectionnez l'action Copier vers le presse-papiers comme indiqué dans la
capture d'écran suivante.
git clone [URL]
Remplacez [URL] en collant depuis le presse-papiers. Vous pouvez également remplacer [URL] dans la
commande ci-dessus par une URL au format https://github.com/<votre_github_username_here>/hello-
remote.git.
Dans le shell vous devez avoir une réponse pareil à:
$ git clone https://github.com/RVIOREL/devFI181.git
Cloning into 'devFI161'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
L'opération de clonage copie le repo distant sur votre machine dans un dossier portant le même nom que le
référentiel, comme illustré dans la capture d'écran précédente.
Mettre dans le rapport le résultat.
5. Accédez au répertoire devFI181. Il devrait contenir le fichier README.md unique et, bien sûr, le dossier .git
caché habituel.
6. Vérifions le statut de notre repo avec le git status. Mettre dans le rapport le résultat. Commenter les
résultats affichés utilisant cette commande.
7. Toujours dans notre clone local du dossier, ajoutons un fichier texte vide appelé demo.txt.
8. Ajouter le nouveau fichier au notre répertoire git utilisant:
git add demo.txt
9. Valider le nouveau fichier sur master avec la commande :
git commit -m "ajoute un fichier texte"
10. Vérifiez l'état de notre repo local avec la commande git status. Mettre dans le rapport le résultat.
Commenter les résultats affichés utilisant cette commande.
11. Pour envoyer nos mises à jour au repo distant, nous utilisons la commande push ou, pour être plus précis:
 git push -u origin master
Le paramètre -u indique à Git de définir origin/master comme référentiel en amont et signifie que nous n'avons
plus besoin de le spécifier à partir de maintenant. Mettre dans le rapport le résultat.
12. Vérifions le statut de notre repo avec le git status. Mettre dans le rapport le résultat. Commenter les
résultats affichés utilisant cette commande.
13. Accédez à votre dépôt sur GitHub. Confirmez que le fichier que vous avez ajouté est dans le dépôt. Mettre dans
le rapport la capture écran.
14. Sélectionnez demo.txt dans la liste, puis l'icône en forme de crayon, mise en évidence dans la capture d'écran
suivante :

15. Dans la fenêtre <> Edit file, entrez du texte dans le fichier demo.txt.
Faites défiler jusqu'au bas de la page d'édition et sélectionnez Commit changes. Le message de validation par
défaut ("Update demo.txt") est suffisant ici et il n'est pas nécessaire de le modifier. À ce stade, nous avons
effectué une mise à jour de demo.txt sur le dépôt. Cependant, nous l'avons fait sur le serveur, voyons donc
l'état de notre repo local. Mettre dans le rapport la capture écran.
16. A partir de la ligne de commande, utilisez git status pour vérifier l'état de notre repo local. Vous devriez
voir le message Your branch is up-to-date with 'origin/master'. Cela peut paraître surprenant au
début, mais rappelez-vous au début de cette leçon, nous avons dit que cela signifie que la branche est à jour
avec le clone de master d’origin. Alors, comment vérifier si des modifications ont été apportées sur le serveur?
17. Pour cela, nous utiliserons git fetch. Sur votre ligne de commande, entrez la commande suivante:
git fetch origin
18. La commande fetch met à jour essentiellement votre branche de suivi à distance, dans ce cas d'origine.
Mettre dans le rapport le résultat.
L'exécution d'une commande git remote –v dans votre ligne de commande indiquera que l'origine pointe
vers votre dépôt à distance devFI161 sur github.com.
19. Vérifions le statut de notre repo avec le git status. Mettre dans le rapport le résultat. Commenter les
résultats affichés utilisant cette commande.
20. Dans la ligne de commandes, tapez ce qui suit:
git pull
Mettre dans le rapport le résultat.
 Cette commande incorpore les modifications d'un référentiel distant dans la branche en cours. Quand-même,
nous n'avons pas spécifié le référentiel distant à partir duquel incorporer les modifications, il utilise la valeur par
défaut qui est l'origine, c'est-à-dire notre référentiel distant.
21. Ouvrez le fichier demo.txt dans votre éditeur favori et vérifiez que les modifications apportées sur le serveur
sont désormais disponibles dans la copie locale.
Modifiez demo.txt, enregistrez les modifications et validez les modifications localement. Mettre dans le rapport
les actions (commandes) et les résultats.
22. Vérifions le statut de notre repo avec le git status. Mettre dans le rapport le résultat. Commenter les
résultats affichés utilisant cette commande.
23. Sur la ligne de commande, publiez vos commits sur votre compte github avec la commande suivante:
git push
Vérifiez que les modifications sont bien sur votre compte github.
24. Changez avec un de vos collègues entre vous les URLs de vos comptes github. Créez des clones de ceux-ci en
local. Ajoutez des modifications sur les fichiers existantes. Publiez les modifications sur le compte de votre
collègue. Mettre dans le rapport les actions (commandes) et les résultats. Est-ce que vous avez rencontré des
problèmes ? Comment les avez-vous solutionnés ?

IV. Adopter un modèle de versionnement efficace avec Git

Lorsque nous commençons un projet, nous mettons toujours en place un dépôt central qui fait office de référence. Bien
que Git soit un outil décentralisé, la mise en place d’un dépôt “maître” s’avère indispensable si vous travaillez à
plusieurs. Chaque participant au projet va donc cloner le projet à partir de ce dépôt et c’est également sur ce dépôt que
seront envoyées les modifications faîtes.

1. Une branche de production saine et cloisonnée

Sur notre dépôt, nous avons besoin de pouvoir gérer le code en production ainsi que les développements en cours.
Il est donc pertinent de considérer que la branche “master” représente l’état du code en production.
Il nous suffit maintenant de créer une branche supplémentaire “develop” qui permet de gérer les développements pour
les versions à venir, c’est ce qu’on appelle souvent la branche d’intégration :

$ git branch develop

$ git checkout develop

On peut donc dès maintenant contribuer au code et le commiter dans la branche “develop” sans que cela impacte notre
code de production, voilà qui permet d’avancer en toute sérénité sans craindre que quelqu’un déploie du code non-
testé ou validé.

Mettre dans le rapport les actions (commandes) et les résultats.

2. Une branche pour développer les fonctionnalités futures

Dans “develop” nous allons donc faire de multiples commits pour agrémenter notre logiciel de nouvelles
fonctionnalités. Cette branche peut d’ailleurs être utilisée en pré-production pour que vos testeurs et clients puissent
profiter des avancements du projet et vous faire des retours.
Mais attention, “develop” n’est pas un fourre-tout et ne devrait être utilisé que pour les petites modifications simples
ayant peu d’impact et ne demandant pas plus de 30 min de travail. En effet si vous travaillez directement sur “develop”
pour une fonctionnalité estimée à 1 mois de développement, il y a fort à parier que vous aller ennuyer vos collégues
avec vos commits qui s’incrustent entre 2 commits légitimes sans pour autant apporter une fonctionnalité finalisée.
Si vous êtes dans ce cas de figure, il vous faut créer une branche dédiée au développement de votre fonctionnalité.

3. Des branches spécifiques pour les développements lourds

Ces branches de développement (feature) permettent de travailler de manière détachée du reste de l’équipe en onant
vos modifications ce qui permet de ne les appliquer sur “develop” qu’une fois satisfait et par la même occasion de ne
pas polluer les collègues.
On peut vouloir commencer à développer une fonctionnalité qui ne sera appliquée qu’à la release N+1, la branche de
feature est donc dans ce cas l’unique solution puisque tout ce qui est dans develop est considéré comme faisant partie
intégrante de la prochaine release.
Une branche de développement est créée à partir de “develop” et sera, une fois terminée, mergée dans “develop”. Ce
type de branche reste généralement locale à la machine du développeur qui fini par la merger dans “develop” le
moment voulu. Il reste toutefois des cas où ces branches de feature sont partagées sur le dépôt central pour une revue
par les autres développeurs.

Voici comment procéder :

$ git checkout -b feature/foo develop

On a donc notre nouvelle branche “feature/foo” basée sur l’état actuel de “develop”. Nous pouvons donc coder et
commiter autant de fois que nécessaire. Une fois fini, il faut intégrer cette branche dans “develop” :

$ git checkout develop

Switched to branch 'develop'

$ git merge --no-ff feature/foo

Updating ea1b82a..05e9557
(Summary of changes)

$ git branch -d feature/foo

Deleted branch myfeature (was 05e9557).

$ git push origin develop

Mettre dans le rapport les actions (commandes) et les résultats.

On est donc retourné dans la branche “develop” dans laquelle on demande à git de merger notre branche de feature.
L’option --no-ff permet de forcer la création d’un commit même si les changements peuvent être intégrés en fast-
forward. Ceci permet de garder une trace dans l’historique du développement dans une branche dédiée. Une fois
mergée, nous supprimons la branche de feature devenue inutile et on push les modifications sur le serveur central.

4. Passage en production

Lorsque “develop” atteint un état satisfaisant pour créer un nouvelle release et déployer, il faut merger “develop” dans
“master”, bumper la version, ajouter un tag de version, mettre à jour un README, … Enfin le code peut être déployé en
production.
On pourrait imaginer qu’à chaque commit dans “master”, un hook soit déclenché pour déployer en production.
Nous allons donc, lors d’une release, créer une branche de support à la release. Les releases sont créées sur la base de la
branche “develop” et doivent être mergées dans “master” et “develop”.
Cette branche ne servira qu’à faire des modifications mineures liées à la création de la release :

$ git checkout -b release/v1.2 develop

Switched to a new branch "release/v1.2"

On peut maintenant bumper la version, mettre à jour le changelog, etc

$ git commit -a -m "Bumped version number to 1.2"

[release/v1.1.2 74d9424] Bumped version number to 1.2
1 files changed, 1 insertions(+), 1 deletions(-)

Il ne nous reste plus qu’à merger cette release dans master pour qu’elle prenne effet :

$ git checkout master

Switched to branch 'master'

$ git merge --no-ff release/v1.2

Merge made by recursive.
(Summary of changes)
$ git tag -a v1.2

On souhaite également récupérer ces informations de release dans “develop” :

$ git checkout develop

Switched to branch 'develop'

$ git merge --no-ff release/v1.2

Merge made by recursive.
(Summary of changes)

Notre release est donc intégrée en production (master) et en intégration (develop), on peut supprimer la branche :

$ git branch -d release/v1.2

Deleted branch release/v1.2 (was ff452fe).

Mettre dans le rapport les actions (commandes) et les résultats.

5. Dépanner les bugs critiques en production

Il vous arrivera certainement de faire face à un bug critique passé en production. Que faire dans ce cas ? Comment est-il
géré dans le workflow ? Vous pensez peut-être qu’on doit nécessairement passer par une nouvelle release mais ce n’est
pas le cas, ce n’est d’ailleurs même pas souhaitable puisque vous intégreriez au passage des fonctionnalités dans
“develop” qui ne sont pas encore prête pour la production.
Dans ce cas de figure, il s’agit de faire ce qu’on appelle un “hotfix”. Un hotfix est un patch qui va s’appliquer directement
à la branche de production (master) et qui sera ensuite également appliqué sur la branche d’intégration (develop). On
peut maintenant déployer la version de production corrigée mais aussi jouir de ces corrections dans “develop”.
Pour se faire, comme toujours nous passerons par l’utilisation d’une branche pour avoir un historique sain :

$ git checkout -b hotfix/v1.2.1 master

Switched to a new branch "hotfix-1.2.1"

On crée une branche basée sur master et on bump la version du projet :

$ git commit -a -m "Bumped version number to 1.2.1"

[hotfix/v1.2.1 41e61bb] Bumped version number to 1.2.1
1 files changed, 1 insertions(+), 1 deletions(-)

On peut maintenant corriger le bug :

$ git commit -m "Fix huge production bug"

[hotfix/v1.2.1 abbe5d6] Fix huge production bug
5 files changed, 32 insertions(+), 17 deletions(-)

Et intégrer la correction en production :

$ git checkout master

Switched to branch 'master'

$ git merge --no-ff hotfix/v1.2.1

Merge made by recursive.

(Summary of changes)

$ git tag -a v1.2.1

mais également en intégration pour ne pas perdre le fix au passage :

$ git checkout develop

Switched to branch 'develop'

$ git merge --no-ff hotfix/v1.2.1

Merge made by recursive.
(Summary of changes)
Le patch étant intégré en production et en développement, on peut supprimer la branche de hotfix devenue inutile :

$ git branch -d hotfix/v1.2.1

Deleted branch hotfix/v1.2.1 (was abbe5d6).

Mettre dans le rapport les actions (commandes) et les résultats.

Tous les cas d’usages typiques ont été couverts et on voit qu’en suivant ce workflow, on peut maintenir un dépôt sain
avec un historique clair et parfaitement adapté à la manipulation si d’aventure on devait revenir en arrière ou faire
sauter une fonctionnalité.
C’est propre et carré mais assez fastidieux n’est-ce pas ? Suivre ce modèle au quotidien demande concentration et
discipline, pour tous les développeurs. Heureusement, une bonne âme nous simplifie le travail grâce à un ensemble
d’extensions pour Git qui permettent de simplifier l’application de ce workflow.

6. Git-flow

Git-flow est un ensemble d’extensions pour Git livré sous forme de shell-scripts très simples d’accès.
Git-flow va permettre de suivre le workflow présenté précédemment sans avoir à tout retenir, surtout si vous êtes un
peu perdu avec toutes les commandes et options de Git.

Initialisation

$ git flow init

va permettre de paramétrer votre dépôt pour une utilisation via git-flow. Notez que tout ceci est local ce qui veut dire
que vous pouvez très bien utiliser git-flow alors que vos collègues ne l’utilisent pas.
Je vous conseille vivement d’utiliser les valeurs par défaut qui sont quasiment des conventions.
Une fois terminé, vous êtes automatiquement positionné sur la branche “develop”, vous pouvez commencer à
travailler.

Mettre dans le rapport les actions (commandes) et les résultats.

7. Créer une branche de feature

$ git flow feature start foo

Vous êtes désormais dans la branche “feature/foo” dans laquelle vous pouvez développer tranquillement votre
fonctionnalité. Vous pouvez bien évidemment repartir dans d’autres branches, créer plusieurs branches de feature en
parallèle, etc.
Une fois vos modifications terminées et prêtent à être intégrées dans “develop”, vous pouvez finaliser cette branche :

$ git flow feature finish foo

Votre branche “feature/foo” va être mergée dans “develop” puis effacée et vous vous retrouverez à nouveau sur la
branche “develop”.

Mettre dans le rapport les actions (commandes) et les résultats.

8. Mise en production

Lorsque “develop” représente l’état souhaité en production, vous pouvez passer à la release :

$ git flow release start v1.0.0

Une branche “release/v1.0.0” est créée, vous pouvez donc bumper la version de l’appli et faire les dernières
modifications avant release. Une fois paré, vous pouvez finaliser la release :

$ git flow release finish v1.0.0

Ceci aura pour effet de merger “develop” dans “master”, de taguer la release, puis de back-merger ces modifications
dans “develop”. La branche de release sera ensuite supprimée et vous retournerez sur la branche “develop”.

Mettre dans le rapport les actions (commandes) et les résultats.

9. Hotfix

Si vous avez besoin de patcher urgemment la production, vous utiliserez la commande dédiée aux hotfixes :

$ git flow hotfix start typo

Une branche “hotfix/typo” est créée et vous pouvez commencer à patcher. Une fois fini, il suffira de finaliser la branche:

$ git flow hotfix finish typo

Ceci aura pour effet d’appliquer votre fix sur master et develop, d’ajouter un tag puis de supprimer la branche de hotfix.
À ce propos, n’oubliez pas de bumper la version avant de finaliser le hotfix.

Mettre dans le rapport les actions (commandes) et les résultats.