!

21

4. Utilisation de Git et TortoiseGit

Cette partie a pour objectif de présenter les commandes indispensables à l’utilisation de Git et TortoiseGit. Toutes les
commandes ne seront pas présentées. Il existe notamment plusieurs solutions pour atteindre un même objectif, mais dans
un soucis d’efficacité, seules certaines d’entre elles sont proposées ainsi que quelques recettes. Dans la plupart des cas, les
opérations seront présentées dans leur forme Git (ligne de commande) et TortoiseGit (menu contextuel). Si nécessaire, des
schémas illustreront les opérations. Des cas d’utilisation plus concrets seront présentés dans la partie suivante. Les
opérations sont présentés dans l’ordre logique d’utilisation d’un collaborateur. Cette partie part du principe que le repository
est déjà créé.

4.1. Cloner un repository existant en local

Lorsque vous souhaitez collaborer à un projet contrôlé avec Git, vous devez récupérer une copie du repository. La
commande à utiliser est «clone»4. L’ensemble du repository (toutes les versions de tous les fichiers) est recopié sur
votre disque dur. Cette commande crée automatiquement un dossier du même nom que votre repo sur votre
disque dur, recopie toutes les données, et fait un «checkout»5 de la dernière version.

$ git clone [url]


e.g. $git clone git://[Link]:/home/mon_uid/info/mon_repo.git

(le repo en local s’appelle mon_repo)

Git e.g. $git clone git://[Link]:/home/mon_uid/info/mon_repo.git

mon_repo_a_moi

(le repo en local s’appelle mon_repo_a_moi)


Créer le dossier dans lequel vous souhaitez stocker le

repository en local et votre version de travail.

Faites un clic droit sur ce dossier et cliquer sur «Git

TortoiseGit Clone...».

4 Les adeptes de Subversion pourront remarquer qu’il ne s’agit pas d’un checkout !

5 Le «checkout» de Git permet de choisir la version (ou la branche) qui sera votre copie de travail. Il est possible de changer
de version de travail à chaque fois qu’on le souhaite. Cette fonctionnalité ne sera pas traité plus en détails dans ce guide.

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!22

Dans la fenêtre de dialogue qui s’ouvre, rentrez l’url du

repository ([Link]
le_repo), le dossier dans lequel vous voulez le cloner.

TortoiseGit

La fenêtre suivante vous demande de rentrer votre mot

de passe (celui que vous utilisez sur les machines de
l’IUT, ou celui que vous avez rentré lorsque vous vous
êtes inscrit sur la forge), puis télécharge le repository.

4.2. Utilisation du repository local

Pour cette partie, il est vivement conseillé d’avoir compris les 3 états des fichiers en local et les 4 opérations avec
les fichiers en local.

4.2.1. Transférer les modifications des fichiers dans le repository local : (add +) commit6
Le commit est la commande la plus effectuée lors de l’utilisation d’un projet contrôlé et versionné par Git.
Les fichiers concernés et déjà versionnés doivent d’abord être placés dans la «staging area» dans le
repository local, puis ils sont (ainsi que leurs modifications) ensuite transférés (committed) vers le
repository local.

6 Il semble qu’il n’y a pas de différences avec l’étape suivante dans l’appel des commandes, mais j’ai préféré faire la diffé-
rence entre fichiers modifiés et nouveaux fichiers.

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!23

‣ajout d’un fichier modifié et de ses modifications du répertoire de travail vers la staging area :
$ git add file
e.g. $ git add [Link]
‣transfert des modifications des fichiers de la staging area vers le repository local :
$ git commit -m ”message explaining modifications”

Important : tous les fichiers de la staging area sont transférés vers le repository local au moment du
commit.
Git
Note : le message accompagnant le commit -m “message explaining modifications” n’est
pas obligatoire mais très fortement conseillé

Autre méthode plus rapide :

‣transfert des fichiers modifiés (et de leurs modifications) du répertoire de travail directement vers le
repository local sans passer par la staging area :
$ git commit -a -m ”message explaining modifications”


Un fichier «à jour» par rapport au repository local, i.e. qui

n’a pas été modifié depuis le dernier commit ou depuis la
dernière synchronisation (ATTENTION ! à jour par rapport
au repository local ne veut pas dire à jour par rapport au ! !
repository distant ! Il peut y avoir eu des soumissions
d’autres utilisateurs depuis. c.f. parties suivantes), est
marqué d’une pastille verte sympathique qui rassure.



Lorsque vous avez modifié un fichier, et qu’il n’est donc

TortoiseGit plus à jour par rapport au repository, il est marqué d’une

pastille rouge qui fait peur, pour indiquer qu’il est modifié,
et non soumis dans le repository local.

Un clic droit sur un fichier ou un dossier de votre répertoire

de travail et un clic sur «Git Commit -> «master»...» (le
master dépend de la branche sur laquelle vous êtes. c.f.
parties suivantes), ouvre une nouvelle fenêtre de dialogue.

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!24

Cette fenêtre vous permet de vérifier quels sont les fichiers

qui vont être transférés vers le repository local. Vous
pouvez encore les (dé)sélectionner grâce à la ListBox
«ChangesMade». Vous devez ensuite décrire votre commit
à l’aide d’un message que vous pouvez signer avec le
bouton «Sign» (si vous avez configuré correctement
TortoiseGit).

Une nouvelle fenêtre de dialogue s’ouvre vous illustrant la

progression du commit. Les fichiers modifiés sont
transférés vers le repository local (dans la branche
TortoiseGit «master»). !

Notez le bouton «Push» qui vous permet de transférer les

modifications du repository local vers le repository distant
(ce qui sera expliqué dans une des parties suivantes).

Le fichier est à nouveau à jour, il retrouve sa jolie pastille

verte.

Note : TortoiseGit rend totalement transparent le passage

par la staging area. !

4.2.2. Ajouter de nouveaux fichiers au repository local : add + commit

L’ajout de fichiers au repository local se fait en deux étapes : la commande add transfert des fichiers non
versionnés dans la «staging area» (état «staged») ; la commande commit transfert ces fichiers de la
«staging area» sur le repository local. Cette étape ressemble beaucoup à la précédente, mais l’intention
était différente, elle est traitée à part. De plus, elle se déroule légèrement différemment via TortoiseGit.

[Link]
depuis le dossier où le fichier est contenu :
$ git add [file]
e.g. $git add [Link]
([Link] est maintenant dans la staging area)

e.g. $git add *.cs
Git (Tous les fichiers *.cs de ce dossier sont maintenant dans la staging area)

2. commit
la commande suivante ajoute [Link] au repository local (ainsi que tous les autres fichiers de la
staging area).
$ git commit -m “added [Link]”


Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!25

1. add
La commande add se fait via le menu contextuel : clic
droit sur le(s) fichier(s) à ajouter -> Tortoise Git -> Add...
Une fenêtre de dialogue apparaît alors vous permettant
d’ajuster votre ajout en (dé)sélectionnant les fichiers à
ajouter.

!
Après avoir valider votre ajout, votre fichier est marqué
d’un gros + bleu, indiquant qu’il se trouve comme mo-
difié (staged) et sera ajouté au prochain commit.

TortoiseGit !
2. commit
La fenêtre de dialogue suivante vous permet d’ailleurs
de faire directement le commit. Même s’il est conseillé
de le faire une fois pour tous les fichiers ajoutés et mo-
difiés, voici tout de même la liste des commandes à
effectuer.
!

En cliquant sur «Commit ...», vous voyez apparaître la

fenêtre de dialogue suivante.
Notez qu’il est encore possible d’ajouter des fichiers
non encore ajoutés (et donc unstaged) dans la staging
area pour les ajouter au commit !
N’oubliez pas non plus d’ajouter le message pour les
collaborateurs.

En cliquant sur OK, vous lancez le commit, dont la

progression apparaît dans la fenêtre suivante (cf. partie
précédente).

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!26

4.2.3. Supprimer des fichiers du repository local : rm

Git permet de supprimer des fichiers du repository local. La suppression a réellement lieu au commit
suivant, et il reste bien entendu possible de retrouver les fichiers avant leur suppression en revenant sur
une version précédente. La suppression s’opère de la manière suivante : l’appel de rm sur un fichier le
retire de la staging area et donc des fichiers à versionner ; le commit suivant ne contient plus le fichier
dans la nouvelle version.

[Link]
depuis le dossier où le fichier est contenu :
$ git rm [file]
e.g. $git rm [Link]
([Link] n’est maintenant plus dans la staging area)

e.g. $git rm *.pdb
(Tous les fichiers *.pdb de ce dossier vont être supprimés du repository local)

Git Pour supprimer le fichier du repository mais le garder sur son disque dur, on peut aussi utiliser la
commande :
$ git rm --cached [file]

2. commit
la commande suivante opère la suppression : les fichiers supprimés ne seront plus cette nouvelle version
du repository.
e.g. $ git commit -m “deleted [Link] and all *.pdb files”


1. rm
La commande rm se fait via le menu contextuel : clic
droit sur le(s) fichier(s) à supprimer -> Tortoise Git ->
Delete ou Delete (keep local).
Les deux préparent la suppression du fichier au pro-
chain commit, mais le premier envoie en plus le fi-
chier à la corbeille (rm), alors que le second le laisse
en place sur le disque dur (rm --cached, il n’a plus
TortoiseGit aucune pastille). Le dossier contenant prend une
méchante pastille en forme de X rouge annonçant
qu’il y aura des suppressions au prochain commit.

! !

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!27

Via TortoiseGit, il est toutefois encore possible d’an-

nuler une suppression (avant le commit bien sûr)
grâce à la commande revert. Un clic droit sur le fi-
chier (s’il a été supprimé avec Delete (keep local)) ou
sur un dossier parent, puis TortoiseGit -> Revert...
permet de réaliser cette opération.

Il faut confirmer dans la boîte de dialogue qui s’ouvre

ensuite, en sélectionnant les fichiers à récupérer.

TortoiseGit

2. commit

Pour réaliser la suppression dans la version suivante

du repository local, on doit ensuite faire un commit
(pour comme add), sur un dossier parent. La réalisa-
tion de la phase commit a ensuite été décrite dans
les parties commit et add précédentes.

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!28

4.2.4. Déplacer ou renommer un fichier dans le repository local : mv + commit

Git utilise la même commande pour déplacer ou renommer un fichier (les mêmes opérations sont
réalisées). TortoiseGit les différencie mais fait la même chose.

1. Pour renommer un fichier :

$ git mv old_name new_name
1bis. Pour déplacer un fichier :
$ git mv file another_folder/file
Git (note : another_folder doit exister)

2. commit
la commande suivante réalise l’opération dans la prochaine version dans le repository local.
e.g. $ git commit -m “renamed old_named and moved file”

1. Pour renommer un fichier :

La commande mv se fait via le menu contextuel : clic droit
sur le fichier à renommer -> Tortoise Git -> Rename...

La boîte de dialogue ci-contre s’ouvre alors et permet de renommer le fichier. Celui-ci est maintenant
marqué par un gros + bleu, car git opère en interne, une copie, un add et un remove. Le fichier renommé
est donc ajouté. Il faut ensuite effectuer le commit comme pour un add.

1bis. Pour déplacer un (ou plusieurs) fichiers :

On peut utiliser la même commande via TortoiseGit pour
renommer ou déplacer des fichiers. C’est juste un peu
pénible et très répétitifs si on veut déplacer plusieurs
fichiers. Sinon, on peut aussi faire un «right-dragging» :
sélectionnez les fichiers à déplacer ; faites un clic droit
TortoiseGit dessus tout en gardant le bouton droit enfoncé ; déplacer
les fichiers vers le nouveau dossier parent et lâchez le
bouton droit. Le menu contextuel ci-contre apparaît, avec
!
4 options intéressantes :

‣ Git Move versioned item(s) here : déplace les fichiers versionnés dans le nouveau dossier (ils sont ajou-
tés et ceux d’origine sont détruits) ;
‣ Git Move and rename versioned item here : fait la même chose mais vous autorise à renommer les
fichiers avant ;
‣ Git Copy versioned item(s) here : fait la même chose que le premier mais sans détruire les fichiers dans
le dossier d’origine ;
‣ Git Copy and rename versioned item here : fait la même chose que le précédente mais vous autorise à
renommer les fichiers avant.
L’historique des versions des fichiers est à chaque fois conservé.

2. commit : cf. partie 2 du add.

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!29

4.2.5. Historique du repository local

Au fur et à mesure de l’avancement d’un projet, on a parfois besoin de regarder en arrière, voir ce qui a
été modifié par soi-même ou par ses collaborateurs. Pour cela, on regarde l’ensemble de l’historique du
repository.

$ git log
permet de visualiser l’historique du repository de manière assez moche. On retrouve les opérations
effectuées, l’auteur des modifications ainsi que le message qu’il a laissé.
exemple de résultat :
commit cf273ccca4acebdf67bdb43043409600f85cf800
Author: Marc Chevaldonné <[Link]@[Link]>
Date: Sun Aug 8 [Link] 2010 +0200
Git
deleting [Link]

commit 5a6471bcd67289e7d04541130902411691f1f0b6
Author: Marc Chevaldonné <[Link]@[Link]>
Date: Sun Aug 8 [Link] 2010 +0200

added [Link]

Pour visualiser l’historique du repository local, il vous

suffit de faire un clic droit sur le dossier parent et d’aller
chercher TortoiseGit -> Show log.
Ceci ouvre une nouvelle fenêtre de dialogue représen-
tant l’historique des modifications du repository sous
forme graphique.

TortoiseGit
!

Voici un exemple de l’historique d’un repository.

‣ La première ListBox donne des informations sur les différents commit :
•la colonne Graph représente les différentes branches et les fusions de branches,
•la colonne Actions schématise le type d’opérations qui ont été effectuées (modifications, ajouts, sup -
pressions, checkout...),
•la colonne Message diffuse les messages des commit,
•les colonnes Author et Date donnent les informations sur l’auteur, le jour et l’heure du commit.
‣ La seconde case donne des informations sur le code du commit, le type d’opérations.
‣ La dernière ListBox donne des détails sur les fichiers modifiés et le type des modifications.

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!30

TortoiseGit

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!31

4.3. Travailler avec les branches

Si vous utilisez Git pour un projet sur lequel vous travaillez seul, vous pouvez vivre sans branches. Dans ce cas,
vous n’utilisez d’ailleurs pas vraiment un système de contrôle de version distribué, mais plutôt un système de
contrôle de version local, avec sauvegardes sur un serveur distant. Toutefois, l’utilisation de branches pourrait déjà
vous être grandement utile. En revanche, dès que vous travaillez dans une équipe, même de 2 personnes, en
utilisant Git, le système de branches devient incontournable, en particulier pour la synchronisation avec le
repository distant. Cette partie présente le principe des branches et leur utilisation dans un repository Git local. La
partie suivante traite de l’utilisation des branches lors de la synchronisation avec le repository distant.

4.3.1. Principe
Le concept de branches de Git est indissociable de celui des
copies de travail. Pour bien comprendre ces principes, il faut se
représenter deux types d’entités : les commits et un système de
pointeurs sur commit. Par commit, nous entendons ici une
version du repository, i.e. un état (une photographie) du projet à
un instant donné. Ces commits seront représentés dans les
schémas suivants par une case avec Ci ou i est un indice qui
croît avec le temps. La branche principale s’appelle «master»7.
«HEAD» est un pointeur sur la branche courante (celle que vous
êtes en train d’utiliser), soit «master» tant que vous ne faites pas
de branches.

Considérez les images ci-contre. Votre repository local contient

quelques commits. Vous avez une idée pour la suite, mais vous
n’êtes pas encore certain de son intérêt ou de sa faisabilité.
Vous ne voulez donc pas faire de commits sur votre branche
«master» avec ce test. La branche est là pour vous aider : vous
créez une branche qui vous permet de bénéficier de l’historique
des commits de master, mais dont les commits futurs
divergeront à partir de la création de la branche.

7 c’est «un peu» l’équivalent du trunk de Subversion

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!32

Vous réalisez dès lors quelques commits sur

cette branche. Notez qu’au démarrage, les
pointeurs «master» et «idea» pointent sur la
même version du projet. «idea» étant la branche
active, le pointeur se déplace avec les nouveaux
commits, alors que «master» reste inchangé. De
plus, «idea» étant la branche active, votre
répertoire de travail local contient la version
correspondant à C5.

Pendant ce développement, vous découvrez (ou

votre binôme, votre enfant...) un horrible bug
qu’il faut vite corriger car la version pointée par
«master» était déjà utilisée par le client. Vous
vous replacez donc sur «master» à l’aide d’un
checkout, et la copie de travail locale redevient la
version correspondant à C3.

Vous créez une nouvelle branche pour résoudre

le bug 1 («debug#1»), sans modifier la branche
«master», tant que le bug n’est pas corrigé. La
branche «debug#1» devient la branche active, et
la copie de travail locale correspond toujours à C3 pour le moment.

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!33

Un commit suffit pour corriger ce bug. Cette

correction doit maintenant être réintégrée dans la
branche «master». La copie de travail locale est la
version correspondant à C6.

Pour cela, on opère une fusion des

branches «master» et
«debug#1» (merge). Cette fusion s’opère
assez bien puisque «master» n’a pas été
modifiée depuis la création de
«debug#1», créée à partir de «master».
«master» redevient la branche courante,
et la copie de travail locale devient la
version fusionnée correspondant à C78.

Le bub corrigé, vous pouvez revenir sur

le développement de votre idée, grâce à
un checkout sur la branche «idea». La
copie de travail locale redevient la
version correspondant à C5.

8 On pourrait également supprimer la branche ou faire un rebase. Mais ceci ne fait pas l’objet de ce document.

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!34

Votre développement nécessite encore

quelques commits. Vous découvrez que
cette idée s’avère géniale, et vous
décidez donc de la réintégrer dans la
branche «master». Cette fois-ci, la fusion
s’avère plus compliquée : l’ancêtre
commun à «idea» et «master» est C3.
Les deux branches ont depuis évolué :
«master» en C7 et «idea» en C8.



La fusion de «master» et «idea» s’opère
en C9. La branche active redevient
«master» et la copie de travail
locale correspondant à C9. La
différence avec la fusion
précédente est que cette nouvelle
fusion ne pourra certainement
pas être totalement automatique.
Elle nécessitera une intervention
manuelle, une gestion des
conflits, si des fichiers ont été
modifiés dans «master» et dans
«idea» depuis l’ancêtre commun
des deux branches.

4.3.2. Gestion des branches

Quand faut-il faire une branche ? Quand faut-il en fusionner ? Il n’y a pas de réponses à ces questions, il
n’y a que des suggestions. En voici quelques-unes...

‣ Branches de debug : ces branches sont généralement créées dans un but précis qui est celui de
corriger un bug en particulier et ont donc normalement une durée de vie limitée. Elles sont supposées
être réintégrées assez rapidement dans la branche qui les a vu naître.

‣ Branches de test : elles ont pour objectif de tester de nouvelles idées, pas forcément prévues au
démarrage du projet. Leur durée de vie est moyenne et leur réintégration dans la branche qui les a vu
naître dépend de l’idée elle-même.

‣ Branches de module : l’objectif de telles branches est de préparer une amélioration, un module,
complètement à part, et de ne l’intégrer qu’une fois terminer. Ces branches doivent donc être
réintégrées dans la branche «master». Leur durée de vie dépend de la taille du module à ajouter. Notons
toutefois que plus celle-ci est longue, plus le risque de problèmes lors de la fusion sera importante.

‣ Branches de développement : elles représentent tout un pan de votre projet, une version de
l’application. Ces branches vivent tout au long du projet et ne sont jamais réintégrées dans la branche
«master». On peut par exemple imaginer dans le cadre de notre jeu, la branche «Web» et la branche
«XBox».

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!35

4.3.3. Créer une branche

1. Créer la branche :
Note : $ git branch
$ git branch branch_name
renvoie la liste des branches du
e.g. $ git branch debug#1
repository. La branche avec un * est la

2. rendre la branche active : branche active.

Git $ git checkout branch_name

e.g.
e.g. $ git checkout debug#1 debug#1

Autre méthode plus rapide (crée la branche et la rend active) : idea

$ git checkout -b branch_name * master


e.g. $ git checkout -b debug#1

Faites un clic droit sur le dossier parent, puis choisissez Tortoi-

seGit -> Create branch...

Une boîte de dialogue s’ouvre pour vous aider à créer la

branche. Vous pouvez alors choisir :
TortoiseGit ‣ le nom de la branche,
‣ à partir de quelle branche celle-ci est créée (par défaut, la
branche active),
‣ d’ajouter un message,
‣ d’indiquer si la branche créée devient la branche active ou
non.
!

Si vous n’avez pas choisi de la rendre active automatiquement,

vous pouvez le faire à l’aide d’un checkout par la suite.
Si vous avez choisi de la rendre active, ceci est confirmé par le
message suivant : !

Enfin, lorsque vous voulez faire un commit, vous remarquerez que le click droit n’offre plus l’option «Git
Commit -> master...» mais «Git Commit -> debug#2...» indiquant par là que la branche active sur la-

quelle vous opérez est «debug#2». !

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!36

4.3.4. Switch/Checkout de branche ou de version

$ git checkout branch_name

e.g. pour retourner sur la branche debug#1 $ git checkout debug#1
Git
e.g. pour retourner sur la branche master $ git checkout master


Faites un clic droit sur le dossier parent, puis choisissez

TortoiseGit -> Switch/Checkout...

Une boîte de dialogue s’ouvre pour vous aider à changer

de branche ou de version. Vous pouvez alors choisir :
‣ la branche dans le menu déroulant ou à travers une
représentation en arbre (en cliquant sur le bouton «...»),
‣ le tag,
TortoiseGit
‣ la version (en la choisissant dans le menu déroulant ou
dans l’historique en cliquant sur le bouton «...»),
‣ une nouvelle branche (en indiquant son nom).

Enfin, vous pouvez vérifier sur quelle branche vous vous trouvez lorsque vous voulez faire un commit :
clic droit offre l’option «Git Commit -> branch_name...» ou branch_name est le nom de la branche active.

4.3.5. Fusionner des branches

La fusion de deux branches peut se passer bien ... ou mal. Entendons par là, peut se faire
automatiquement ou «à la main». Si les fichiers modifiés dans chacune des branches sont différents, alors
la fusion se passera «bien», automatiquement. Si vous avez modifié le même fichier dans les deux
branches qui fusionnent, il y aura des conflits à gérer, «à la main». Cette partie présente les commandes à
effectuer pour fusionner deux branches sans considérer les conflits, comme «master» et «debug#1» dans
le paragraphe d’introduction. La partie suivante introduit les outils de gestion des conflits.

1. se placer dans la branche qui «restera» après la fusion

$ git checkout main_branch e.g. «master» : $ git checkout master
2. fusionner l’autre branche sur la première
$ git merge merged_branch e.g. «debug#1» : $ git merge debug#1
Git
S’il n’y a aucun message d’avertissement, la fusion est réussie.

3. optionnel, détruire la branche fusionnée :

$ git branch -d merged_branch e.g. «debug#1» : $ git branch -d debug#1

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!37

1. Faites un clic droit sur le dossier parent, puis choisissez TortoiseGit -> Switch/Checkout...
Placez-vous dans la branche qui va recevoir la branche fusionnée (e.g. «master»).

2. Faites un clic droit sur le dossier parent, puis

choisissez TortoiseGit -> Merge...

3. Une boîte de dialogue s’ouvre. Dans

«From», choisissez la branche qui va fusion-
ner dans votre branche courante (e.g. «de-
bug#2»). N’oubliez pas le petit message
explicatif.

TortoiseGit

4. La dernière fenêtre montre la progression de

la fusion et indique si elle s’est bien dérou-
lée.

4.3.6. Gestion des conflits

Oui... parfois ça se passe mal. Juste quelques conflits en fait, mais qu’il faut éditer à la main.
Malheureusement, c’est même la plupart du temps comme ça. Imaginez un projet VisualStudio. Deux
collaborateurs du projet Git travaillent sur deux fichiers différents. A priori, il n’y a pas de soucis car les
fichiers sont différents, mais s’ils appartiennent au même projet, le projet lui-même risque fort d’être en
conflit.

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!38

Pour expliquer les opérations à réaliser, imaginons la situation suivante.

i. dans la branche «master», le fichier Tap_tappe.txt est créé et au commit C1, contient le texte
suivant :

<Onstage>
New York M C:
You want it right, direct from hell, Spinal Tap!
C1
--- Spinal Tap performs Tonight I'm Gonna Rock You Tonight ---

David: We are Spinal Tap from the UK you must be the USA!
#

ii. la branche «song_branch» est créée ; le fichier Tap_tappe.txt est modifié et au commit C2,
contient le texte suivant (en rouge le texte modifié) :

<Onstage>
New York M C:
You want it right, direct from hell, Spinal Tap!

--- Spinal Tap performs Tonight I'm Gonna Rock You Tonight ---

David: We are Spinal Tap from the UK you must be the USA!

--- Tonight I’m Gonna Rock You Tonight (lyrics) ---

Little girl, it's a great big world but there's only one of me
You can't touch 'cause I cost too much but
Tonight I'm gonna rock you (Tonight I'm gunna rock you)
Yeah tonight I'm gonna rock you (Tonight I'm gunna rock you)
Tonight!

You're sweet but you're just four feet

And you still got your baby teeth
You're too young and I'm too well hung
C2 Tonight I'm gonna rock you (Tonight I'm gunna rock you)
Yeah onight I'm gonna rock you (Tonight I'm gunna rock you)
Tonight!

Whoa yeah

You're hot, you take all we got, not a dry

seat in the house
Next day, we'll be on our way
Tonight we're gonna rock you (Tonight we're gunna rock you)
Yeah tonight we're gunna rock you (Tonight we're gunna rock #
you)
Tonight!

Chorus:
Little girl, it's a great big world, but there's
only one of - meeeee

--- end of the song ---

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!39

iii. on retourne sur la branche «master» ; le fichier Tap_tappe.txt est modifié à nouveau et au commit
C3, contient donc le texte suivant (en rouge le texte modifié) 9 :

<Onstage>
New York M C:
You want it right, direct from hell, Spinal Tap!

--- Spinal Tap performs Tonight I'm Gonna Rock You Tonight ---

David: We are Spinal Tap from the UK you must be the USA!

<Garden Interview I>

Marty: Let's...uh talk a little bit about the history of the
group. I understand Nigel you and David originally started
the band wuh...back in...when was it... 1964?
David: Well before that we were in different groups, I was in a
group called The Creatures and w-which was a skiffle group.
Nigel: I was in Lovely Lads.
C3 David: Yeah.
Nigel: And then we looked at each other and says well we might as
well join up you know and uh....
David: So we became The Originals.
Nigel: Right.
David: And we had to change our name actually....
Nigel: Well there was, there was another group in the East End
called The Originals and we had to rename ourselves.
David: The New Originals.
Nigel: The New Originals and then, uh, they became....
David: The Regulars, they changed their name back to The Regulars
and we thought well, we could go back to The Originals but
what's the point? #
Nigel: We became The Thamesmen at that point.

On veut maintenant fusionner la branche «song_branch» dans «master»

et faire le commit C4 ci-contre.

Si on tente une fusion comme dans la partie précédente, on obtient un

conflit. Voici comment le résoudre avec Git et avec TortoiseGit.

9 notez que le texte modifié en C2 n’est pas contenu ici puisqu’il est modifié dans une autre branche

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!40

1. on tente un merge
$ git checkout main_branch e.g. «master» : $ git checkout master
$ git merge merged_branch e.g. «song_branch» : $ git merge song_branch

on obtient une réponse semblable en cas de conflit :

Auto-merging Tap_tappe.txt
CONFLICT (content): Merge conflict in Tap_tappe.txt
Automatic merge failed; fix conflicts and then commit the result.

Git ne sait pas dans quel ordre il doit fusionner les modifications des deux branches (doit-il mettre
d’abord les paroles de Tonight ou la Garden Interview ?)

Si on ouvre le fichier, il contient des insertions lors du merge qu’il faut éditer. Par exemple, le fichier
Tap_tappe.txt ressemble désormais à :
<Onstage>
New York M C:
You want it right, direct from hell, Spinal Tap!

--- Spinal Tap performs Tonight I'm Gonna Rock You Tonight ---

David: We are Spinal Tap from the UK you must be the USA!

<<<<<<< HEAD
Git
<Garden Interview I>
Marty: Let's...uh talk a little bit about the history of the
group. I understand Nigel you and David originally started
the band wuh...back in...when was it... 1964?
David: Well before that we were in different groups, I was in a
group called The Creatures and w-which was a skiffle group.
Nigel: I was in Lovely Lads.
David: Yeah.
Nigel: And then we looked at each other and says well we might as
well join up you know and uh....
David: So we became The Originals.
Nigel: Right.
David: And we had to change our name actually....
Nigel: Well there was, there was another group in the East End
called The Originals and we had to rename ourselves.
David: The New Originals.
Nigel: The New Originals and then, uh, they became....
David: The Regulars, they changed their name back to The Regulars
and we thought well, we could go back to The Originals but
what's the point?
Nigel: We became The Thamesmen at that point.
=======
--- Tonight I'm Gonna Rock You Tonight (lyrics) ---

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!41

Little girl, it's a great big world but there's only one of me
You can't touch 'cause I cost too much but
Tonight I'm gonna rock you (Tonight I'm gunna rock you)
Yeah tonight I'm gonna rock you (Tonight I'm gunna rock you)
Tonight!

You're sweet but you're just four feet

And you still got your baby teeth
You're too young and I'm too well hung
Tonight I'm gonna rock you (Tonight I'm gunna rock you)
Yeah onight I'm gonna rock you (Tonight I'm gunna rock you)
Tonight!

Whoa yeah

You're hot, you take all we got, not a dry

seat in the house
Next day, we'll be on our way
Tonight we're gonna rock you (Tonight we're gunna rock you)
Yeah tonight we're gunna rock you (Tonight we're gunna rock you)
Git Tonight!

Chorus:
Little girl, it's a great big world, but there's
only one of - meeeee

--- end of the song ---

>>>>>>> song_branch

2. On voit que Git a inséré dans le fichier, le texte suivant :

‣la partie commune,
‣la ligne : <<<<<<< HEAD
‣ les modifications en conflit de la branche active,
‣la ligne : =======
‣les modifications en conflit de la branche à fusionner,
‣la ligne : >>>>>>> song_branch

À cause du conflit, l’auto-commit n’a pas été fait. Il nous faut éditer le conflit et faire le commit à la main.
Nous voulons par exemple mettre les paroles de la chanson avant la Garden Interview (avec des coupes
pour des raisons de place) et bien sûr enlever les lignes insérées par Git :

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!42

<Onstage>
New York M C:
You want it right, direct from hell, Spinal Tap!

--- Spinal Tap performs Tonight I'm Gonna Rock You Tonight ---

David: We are Spinal Tap from the UK you must be the USA!

--- Tonight I'm Gonna Rock You Tonight (lyrics) ---

Little girl, it's a great big world but there's only one of me
You can't touch 'cause I cost too much but
Tonight I'm gonna rock you (Tonight I'm gunna rock you)
Yeah tonight I'm gonna rock you (Tonight I'm gunna rock you)
Tonight!

[...]

Chorus:
Little girl, it's a great big world, but there's
only one of - meeeee
Git
--- end of the song ---

<Garden Interview I>

Marty: Let's...uh talk a little bit about the history of the
group. I understand Nigel you and David originally started
the band wuh...back in...when was it... 1964?
David: Well before that we were in different groups, I was in a
group called The Creatures and w-which was a skiffle group.

[...]

David: The Regulars, they changed their name back to The Regulars
and we thought well, we could go back to The Originals but
what's the point?
Nigel: We became The Thamesmen at that point.

3. On peut maintenant faire le commit :

$ git commit -a -m «merged song_branch»

Le conflit est résolu et la fusion réalisée et dans le nouveau commit C4.

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!43

1. On tente une fusion.

on obtient une réponse semblable en cas de conflit :
Auto-merging Tap_tappe.txt
CONFLICT (content): Merge conflict in
Tap_tappe.txt
Automatic merge failed; fix conflicts
and then commit the result.

Git ne sait pas dans quel ordre il doit fusionner les modifications des deux branches (doit-il mettre
d’abord les paroles de Tonight ou la Garden Interview ?).

Les fichiers en conflit sont marquées d’une pastille qui fait peur : !
TortoiseGit

2. Pour éditer les conflits, il faut éviter de faire comme

pour Git, sinon TortoiseGit fait un peu n’importe quoi. Il
vaut mieux passer par l’éditeur de conflits. Pour cela,
faites un clic droit sur le fichier à éditer, puis cliquer sur
TortoiseGit -> Edit conflicts...

L’éditeur de conflits par défaut s’ouvre. Il présente trois zones de texte :

à gauche, la version sur la branche à fusionner,
à droite, la version sur la branche active,
en bas, le résultat de votre édition.

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!44

TortoiseGit Les zones en rouge (également schématisées sur l’en-

semble du fichier dans la colonne de gauche), sont les
zones en conflits. On peut par exemple ensuite, choisir
de récupérer tout le bloc sur la branche à fusionner
d’abord, grâce à clic droit «Use text block from
‘theirs’ before ‘mine’», ‘theirs’ représente la branche
à fusionner et ‘mine’ la branche active.
!
On peut affiner l’édition. En effet, dans notre exemple,
la première ligne de chaque bloc était la même et a
donc été copiée deux fois. On peut éditer la zone de
texte du bas qui montre le résultat, à l’aide des com-
mandes classiques d’insertion, de copie, de collage,
etc...
!

Il ne faut surtout pas oublier de préciser ensuite que

l’édition des conflits est terminée en cliquant sur «Mark
as resolved» dans la barre de tâches.
!

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!45

Le fichier est alors considéré comme résolu et modifié. Il a perdu sa méchante pastille pour la pastille
rouge avec un point d’exclamation. Il peut être maintenant «commité».

TortoiseGit

3. commit comme précédemment.

note : il peut se faire depuis la fenêtre précédente, mais s’il y a plusieurs fichiers en conflit, il faudra
d’abord résoudre tous les conflits).

4.4. Synchronisation avec un repository distant

Pourquoi cette partie, qui semble si importante (il s’agit quand même du partage du travail avec les autres
collaborateurs !) arrive aussi tard dans ce document ? Pour deux raisons principales :
1. avec Git, la quasi-totalité des opérations se passent en local (y compris la création de branches),
2. la récupération du travail des collaborateurs se fait via les branches distantes de Git.

Il était donc nécessaire d’avoir compris la gestion de Git en local et la gestion des branches avant de parler de la
synchronisation avec le repository distant.

Cette partie présente comment soumettre son travail dans le cas où personne n’a rien soumis depuis votre
dernière mise à jour ; comment récupérer le travail des collaborateurs dans le cas où vous n’avez rien soumis
depuis votre dernière mise à jour ; comment soumettre et récupérer le travail des autres collaborateurs en cas de
conflits (vous avez fait des mises à jour et/ou quelqu’un a fait des mises à jour) grâce aux branches distantes et à la
fusion de branches10.

Pour l’ensemble de ces parties, nous utiliserons le cas suivant. Il existe un repository distant déjà créé contenant un
fichier sur la branche master. Ce fichier est modifié par deux utilisateurs : Derek Smalls et Nigel Tufnel.

10 Nous ne travaillerons ici qu’avec un seul repository distant, mais sachez qu’il est possible d’avoir plusieurs repositories
distants pour un même projet.

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!46

La synchronisation avec le repository distant se fait à l’aide de branches (remote branches). Par exemple, la
branche master du repository distant (origin) est représentée en local par origin/master. Attention, ce pointeur
origin/master, correspond à l’état de la branche du repository distant au moment de la dernière mise à jour. Dans
la suite de cet exemple, nous représenterons donc l’évolution des repository de Derk, de Nigel et distant. Au
démarrage, puisque les 2 utilisateurs sont à jour, les repositories ressemblent à ça.

repo distant repo de Derek repo de Nigel

! !

4.4.1. Soumettre son travail sur le repository distant

Derek Smalls modifie ce fichier sur son repository local. Il fait un commit sur sa branche «master» locale
(C2). Les repositories ressemblent donc à ça.

repo distant repo de Derek repo de Nigel

! !

Il souhaite partager son travail sur le repository distant. Pour cela, il fait un push. Le repository est mis à
jour, ainsi que la branche distante origin/master de Derek, mais pas celle de Nigel qui n’a rien fait.

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!47

repo distant repo de Derek repo de Nigel

! !

Pour faire un push, il faut utiliser la commande suivante :

$ git push [remote-name] [branch-name]
où remote-name correspond au serveur distant (e.g. origin est attribué automatiquement à votre
repository distant au moment du clone, mais comme il peut y avoir plusieurs repositorys, il faut pouvoir
préciser) et branch-name à votre branche locale que vous voulez «pousser» sur le repository distant.
Git e.g. $ git push origin master pour pousser la branche «master» sur le repository distant

Cette opération se passe bien s’il n’y a pas eu d’autres apports des autres collaborateurs (ici Nigel) sur le
repository. Dans le cas contraire, il faut d’abord mettre à jour votre repository, résoudre les éventuels
conflits, puis pousser à nouveau.


Pour faire un push, il faut faire un clic droit sur le

dossier versionné et cliquer sur Git Sync...
!
Dans la boîte de dialogue qui s’ouvre, il suffit de cliquer
sur Push, après avoir vérifié que la branche locale et la
branche distante sélectionnées sont bien celle depuis
laquelle on veut faire le Push (les données poussées
TortoiseGit
doivent avoir été commitées avant !) et celle qui doit
recevoir les données.

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!48

4.4.2. Récupérer le travail des collaborateurs

Nigel veut maintenant récupérer les modifications de Derek. Pour cela, il fait un fetch origin qui met à jour
la branche origin/master en local. Sa branche locale master, elle, ne bouge pas.

repo distant repo de Derek repo de Nigel

! !

Pour que sa branche master soit mise à jour, il doit fusionner les deux branches master et origin/master.
Cette fusion ne pose aucun problème puisque master pointe toujours sur un ancêtre de origin/master. En
d’autres termes, ça ne pose aucun problème parce que Nigel n’a pas fait de commits entre sa dernière
mise à jour et le fetch. Après la fusion, les repositories ressemblent donc à ça.

repo distant repo de Derek repo de Nigel

! !

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!49

2 étapes : fetch et merge

1. Pour faire un fetch, il faut utiliser la commande suivante :

$ git fetch [remote-name]
où remote-name correspond au serveur distant (e.g. origin est attribué automatiquement à votre
repository distant au moment du clone, mais comme il peut y avoir plusieurs repositories).
e.g. $ git fetch origin pour mettre à jour la branche «origin/master» en local

Git 2. Il faut ensuite fusionner les deux branches : pour cela, on se place d’abord dans la branche qui doit
recevoir (e.g. master) et on fusionne (puis commit) :
$ git merge [remote-branch]
e.g. $ git merge origin/master

Cette opération se passe bien s’il n’y a pas de conflits, c’est-à-dire si le collaborateur qui fait le fetch n’a
pas fait de modifications générant de conflits.


2 étapes : fetch et merge

1. Pour faire un fetch, il faut faire un clic droit sur le

dossier versionné et cliquer sur Git Sync...
!

Dans la boîte de dialogue qui s’ouvre, il suffit de

cliquer sur Fetch, après avoir vérifié que la branche
locale et la branche distante sélectionnées sont bien
celle depuis laquelle on veut transférer les données et
celle qui doit les recevoir.
TortoiseGit

2. fusion : celle-ci se passe comme présenté

précédemment. Il faut juste penser à sélectionner la
branche distante (une branche dont le nom est
précédé de remotes/ e.g. remotes/origin/master). Le
commit est fait automatiquement.

!

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!50

4.4.3. Gestion des conflits lors de l’utilisation d’un repository distant

Maintenant, Derek et Nigel modifient chacun de leur côté le fichier. Les repositories évoluent différemment.
En l’absence de push, le repository distant n’évolue pas.

repo distant repo de Derek repo de Nigel

! !

Nigel «pousse» son travail sur le serveur via un push. Le repository distant est modifié. Celui de Nigel
aussi et est à jour. En revanche, la branche origin/master de Derek n’est plus à jour mais il ne le sait pas
encore.

repo distant repo de Derek repo de Nigel

! !

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!51

Derek a terminé son travail et souhaite le pousser à son tour. Il fait un push mais se le voit refuser par le
serveur, qui lui demande de faire d’abord un fetch, de fusionner ses données, puis de faire un commit et
de repousser à nouveau.

Derek fait alors un fetch, et obtient le repository suivant.

repo distant repo de Derek repo de Nigel

Il obtient des conflits sur le fichier modifié par Nigel au commit C4 et ses propres modifications du commit
C3. Après avoir géré les conflits, fusionné les branches et fait le commit C5, son repository ressemble à :

repo distant repo de Derek repo de Nigel

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné

!52

Il peut cette fois-ci faire son push, puisqu’il est à jour avec le repository distant (C5 est bien un ancêtre de
C4).

repo distant repo de Derek repo de Nigel

! !

4.5. Autres fonctionnalités

Cette partie a pour but de présenter quelques fonctionnalités supplémentaires mais secondaires de Git. Elle sera
remplie dans des futures versions en fonction des besoins.

4.5.1. Tag
À suivre...

4.5.2. Rebase
À suivre...

4.5.3. Pull
À suivre...

Git et TortoiseGit - Quick Guide 1.3 Marc Chevaldonné