Pr.

HNIDA Meriem

ATELIER GIT (en mode commande)

Le 02/12/2022

L'objectif de cet atelier est de maitriser les commandes de base du système de gestion distribué GIT. Il est également
possible d’utiliser le plugin intégré dans la majorité des IDEs (Environnement Intégré de Développement). Ces
derniers cachent la complexité des commandes et vous facilitent la tâche. L’objectif de cet atelier est de vous guider,
pas à pas à la compréhension des commandes de base de Git telles que commit, création de branche,
positionnement sur une branche, merge, rebase et tant d’autres.

Démarrage

 Installer le client git https://git-scm.com/downloads

 Interpréter le numéro de version du client Git, que signifie le 2, 29, puis 2 ?
 Que signifie le mot clé instantané ou Snapshot dans GIT?

Partie 1 : les commandes de base

 Créez un dossier appelé «SharedProject » sur votre disque dur, et initialiser un dépôt git dans ce répertoire
en utilisant la commande git init. Pour le moment vous avez combien de dépôt (appelé aussi référentiel ou
repository)
 Quel est l’état des fichiers obtenus en initialisant dépôt ou en clonant un dépôt pour la première fois ? (git
help pour obtenir de l’aide sur la commande à utiliser).
 Vous êtes sur quelle branche ?
 Créer un nouveau fichier dans le dossier «SharedProject», par exemple un programme en hello.py affichant
un «Hello World ». Est-ce que le fichier hello.py est suivi en version ? vérifier son statut ?
 Quel est l’état du fichier après avoir exécuté la commande git add hello.py ( ou git add *)
 Modifier votre programme, ajouter par exemple une ligne de code. Vérifiez ensuite le nouvel état de votre
fichier. Qu’est-ce que vous constatez ?
 Que signifie le statut «Changes not staged for commit»
 Pour indexer le fichier utiliser la commande git add à nouveau sur le fichier ? Vérifier l’état du fichier ?
Qu’est-ce que vous constatez par rapport à la commande précédente?
 Ajouter deux autres fichiers à votre copie de travail puis lancer la commande git status.
 Utiliser git add –i pour indexer simultanément les deux fichiers. Dans quel cas utiliserez-vous cette
commande ?

 A présent tous les fichiers sont indexés et feront partie du prochain commit. Supposons que vous avez
oublié d’ajouter une ligne de code.
Modifier le code et vérifier à nouveau le statut du fichier, que constatez-vous ?

1
  Comment se fait-il que le fichier est marqué sous deux statuts ? si vous lancez un commit quelle version
sera envoyée, avant modifier ou après modification ?

 Relancer la commande git add pour prendre en compte l’état actuel dans la copie de travail.
Faire votre premier commit ( git commit).
o Sur quelle branche vous avez commité ?
o Quel est le numéro du commit ?
o Combien de fichier ont été commité ?
o Quelles statistiques affichées sur les lignes modifiées ?

 Que signifie le message « working tree clean » lorsque vous lancez la commande git status ?
 Lancer la commande «gitk –all » ou «git citool», que fait cette commande ?
 Afficher l’historique de la branche master ( Menu repository -> visualize all branch history).

Partie 2 : les branches

 Créer une nouvelle branche appelée «FixBug » en utilisant la commande git branch
 Modifier le fichier « hello.py » en ajoutant une nouvelle ligne et faites un commit.
 Sur quelle branche vous avez envoyé la modification ?
 Positionnez-vous sur la branche «FixBug » en utilisant la commande git checkout FixBug.
 Créer un nouveau fichier « bug.py» et faites un commit à nouveau sur la nouvelle branche FixBug
 Afficher l’historique dans le client Git en mode graphique, vous devriez avoir une vue ressemble à :

A ce stade, vous avez deux branches que vous pouvez faire avancez, il suffit de se positionner sur la branche
avant d’envoyer les modifications. Par exemple, vous avez créé la branche FixBug pour corriger une erreur
sans interrompre les activités de développement. Pour intégrer les modifications apportées aux codes de
la branche «Fixbug » dans la branche de développement, vous allez utiliser la commande Merge.

En se positionnant toujours sur la branche Fixbug, lancer la commande git merge master.

Que constatez-vous ? Quelle est la branche principale de développement ?

Commande Merge (Merger master dans ma branche ou l’inverse ? voyons voir)

 Faites une nouvelle branche appelée correctif à partir de la branche master (Se postionner d’abord
sur master pour créer la nouvelle branche)
 Positionnez-vous sur la branche correctif
 Ajouter un fichier appelé «Correctif.py »
 Faites un commit
 Retournez sur la branche master (commande git checkout master)
 Modifier le fichier «hello.py » puis commit
 Fusionnez la branche correctif dans master avec git merge correctif.
 Positionnez-vous dans la branche d’origine master.Quel est le résultat de la méthode git merge
correctif ?

2
  Master pointe maintenant sur un nouveau commit. Combien y a-t-il de parent pour le dernier
commit ?
 Est-ce que master contient tout le travail du dépôt ?
 Faites un nouveau commit sur master.

La commande Rebase

 Auparavant, vous avez utilisé la commande Merge pour intégrer les modifications d’une branche dans
une autre. Une autre façon de faire serait d’utiliser la commande rebase. En utilisant merge, vous créer
une branche parallèle et vous pouvez ajouter des commits sur deux branches différentes. Nous
voudrions transférer notre travail de la branche 'bugFix' directement sur le travail existant dans
'master'. Ainsi on aurait l'impression que ces deux travaux ont été développés séquentiellement alors
qu'en réalité ils ont été réalisés en parallèle.

Pour comprendre comment cela fonctionne exécuter la série des commandes suivantes :

 Positionnez-vous (checkout) sur la branche nommée bugFix, modifier le fichier «bug.py»

 Faites un commit.
 Retournez sur master, modifier le fichier «hello.py» et faites un nouveau commit.
 Positionnez-vous à nouveau sur bugFix et faites un rebase sur master
 Désormais, le travail de la branche 'bugFix' est juste en haut de la branche 'master' et vous obtenez
une séquence linéaire de commits.
 Le seul problème est que master n'a pas été mis à jour, se positionner à nouveau sur la branche master.

 Dans quel cas serait-il dangereux de faire un rebase ?

Se déplacer comme tarzan entre les commits

 Le mot clé HEAD fait référence symbolique à la branche courante . Jusqu’à présent HEAD pointe
toujours sur le plus récent commit. Pour le détacher, essayer de faire pointer HEAD sur un Commit
particulier 1 Par exemple. Spécifiez le commit par son identifiant (hash) puis utiliser la commande git
checkout pour se positionner sur un commit.

Visuellement cela donne :

3
 Retenir les identifiants des commits serait difficile. Ainsi, il est plus facile de se déplacer en utilisant des
références relatives.

-
Revenir de plusieurs en arrière avec ~<num> , L'opérateur tilde est suivi d’un numéro
qui spécifie le nombre de parents que vous souhaitez remonter
 Essayez la commande suivante : git checkout master~1

Annulation d’un commit en local

git reset annule des changements en déplaçant la référence en arrière dans le temps sur un commit plus ancien.
En ce sens, on peut considérer cela comme une façon de "réécrire l'histoire"; git reset fait remonter une branche
en arrière comme si le(s) commit(s) n'avait jamais eu lieu.

 Tester la commande suivante: git reset HEAD~1

Annulation d’un commit et partage sur le dépôt

La commande reset fonctionne our les commits faits dans le répository local. Pour pouvoir annuler des
changements et partager ces annulations avec d'autres : git revert. Avec revert, vous pouvez diffuser (push)
vos modifications et les partager avec tout le monde.

Déplacer le travail (moving work around)

Imaginons que vous avez deux branches (FixBug) et (Master) et que vous voulez copier dans master une partie
du travail que vous avez effectué dans la branche Fixbug. La commande cherry-pick permet de dire qu'on
voudrait copier une série de commits en-dessous de notre emplacement actuel (HEAD).

 Essayez de copier quelques commits en-dessous du HEAD.

Mercurial, Git et subversion ont tous la possibilité de «sélectionner» à la main «cherry-picking» un ensemble de
modification dans une branche et l’appliquer sur une autre, mais c’est assez risqué

Supposons que le HEAD se positionne sur le dernier commit de la branche «master», que fait la commande git
cherry-pick fixbug~1 ?

A la recherche de qui a causé le bug ?

Bisect est une commande qui permet de mettre directement le doigt sur le bug et plus généralement sur
ce qui a été changé. On lance la commande biset sur une révision dont on sait qu’elle n’a pas de bug et sur
une révision contenant ce bug. Par processus itératif et questionnement de l’utilisateur, la commande
bisect est capable de trouver la révision qui a introduit le bug.

4
Pour aller plus loin

Remisage (git stash)

Imaginons le scénario suivant: vous êtes en train sur une branche, vous avancez pas mal dans votre travail.
Votre binôme vous demander de l’aider à corriger un bug sur une autre branche. Vous avez effectué des
modifications mais vous n’êtes pas prêt à les publier.

Vous allez remiser vos modifications, changer de branche, corriger le bug, revenir sur la branche où vous
étiez et reprendre les modifications de la remise pour reprendre votre travail où vous en étiez.

Si vous préférez le challenge, visitez le lien suivant: https://learngitbranching.js.org/. Ce site nous a inspiré pour
la réalisation de cet atelier.