Qu'est-ce que HEAD dans Git?


Réponses:


775

Vous pouvez considérer la HEAD comme la "branche actuelle". Lorsque vous changez de branche avec git checkout, la révision HEAD change pour pointer vers la pointe de la nouvelle branche.

Vous pouvez voir ce que HEAD pointe en faisant:

cat .git/HEAD

Dans mon cas, la sortie est:

$ cat .git/HEAD
ref: refs/heads/master

Il est possible que HEAD fasse référence à une révision spécifique qui n'est pas associée à un nom de branche. Cette situation est appelée une tête détachée .


53
Donc, git HEAD dépend du contexte de quelle branche vous êtes, n'est-ce pas? Encore plus loin, vous en tant que développeur? Je suppose que je demande, est-ce que Git HEAD va être une chose globale à l'échelle du référentiel, ou individuelle pour chaque développeur?
bobobobo

91
@bobobobo: C'est vrai, HEAD est comme un pointeur qui pointe vers la branche courante. Lorsque vous extrayez une branche différente, HEAD change pour pointer vers la nouvelle. Le HEAD actuel est local à chaque référentiel, et est donc individuel pour chaque développeur.
Greg Hewgill

16
@Meng Celui-ci m'a aidé, j'espère que cela aide: marklodato.github.com/visual-git-guide/index-en.html
raphael

54
@ 動靜 能量: HEAD peut pointer vers n'importe quel commit, il n'a pas besoin d'être le dernier commit d'une branche. (Lorsque HEAD pointe vers une validation qui n'est pas la dernière validation dans une branche, c'est une "HEAD détachée").
Greg Hewgill

127
HEAD n'est pas "la branche actuelle". Is est le nom donné à la validation à partir de laquelle l'état actuel de l'arborescence de travail a été initialisé. En termes plus pratiques, il peut être considéré comme une référence symbolique au commit extrait.
Ben Collins

184

Pour citer d' autres personnes :

Une tête est simplement une référence à un objet commit. Chaque tête a un nom (nom de branche ou nom de tag, etc.). Par défaut, il y a une tête dans chaque référentiel appelé master. Un référentiel peut contenir n'importe quel nombre de têtes. À tout moment, une tête est sélectionnée comme «tête actuelle». Cette tête est aliasée à HEAD, toujours en majuscules ".

Notez cette différence: une «tête» (en minuscules) fait référence à l'une des têtes nommées dans le référentiel; «HEAD» (majuscule) se réfère exclusivement à la tête actuellement active. Cette distinction est fréquemment utilisée dans la documentation Git.

Une autre bonne source qui couvre rapidement le fonctionnement interne de git (et donc une meilleure compréhension des têtes / HEAD) peut être trouvée ici . Les références (ref :) ou les têtes ou les branches peuvent être considérées comme des notes post-it collées sur les commits dans l'historique des commit. Habituellement, ils pointent vers la pointe d'une série de validations, mais ils peuvent être déplacés avec git checkoutou git resetetc.


De cela: "Chaque tête a un nom". Et "une tête est sélectionnée comme" tête actuelle ". Cette tête est aliasée à HEAD ". J'en conclus donc que "HEAD" ne fait pas référence à la situation de "détaché HEAD".
gxyd

1
@gxyd si c'est le cas que HEAD ne pointe pas vers une "tête", c'est une HEAD détachée. Il pointe vers l'ID de validation du commit que vous avez spécifié (en utilisant, par exemple, git checkout HEAD~2), qui n'est pas l'ID de validation d'une tête connue. Voir l'article sur eagain.net/articles/git-for-computer-scientists pour une explication plus approfondie.
Silfheed

1
@Silfheed: En général, je pense que cette réponse est conceptuellement plus solide que celle acceptée (même si l'utilisation de "tête" en minuscules pour désigner une branche déroute beaucoup de gens). Cependant, ce git revertn'est pas un bon exemple de déplacer une branche pour qu'elle ne soit pas à la pointe, car elle git revertcrée simplement de nouveaux commits et laisse toujours la branche actuelle à la (nouvelle) pointe.
LarsH

1
"qui n'est pas l'ID de validation d'une tête connue" - En fait, une HEAD détachée peut pointer vers un ID de validation qui est également l'ID de validation d'une tête connue (ou plusieurs têtes). Ce qui le rend détaché, c'est que la HEAD pointe directement vers l'ID de validation, pas vers une tête. Cela affectera le comportement des futurs commits, resets, etc.
LarsH

1
@LarsH: Bon point sur un HEAD détaché pointant sur un ID de validation au lieu d'une référence. Vous pouvez réellement vérifier cela en regardant .git / HEAD. S'il est détaché, il contiendra le hachage d'une validation, même s'il s'agit du même commit qu'une tête connue. S'il est attaché, il contiendra le chemin vers la tête (c'est-à-dire «ref: refs / heads / bob»). Quant à la commande revert, après 8 ans, je n'ai jamais attrapé cette faute de frappe. Git reset est ce qui vous permet d'ajuster une tête particulière pour pointer vers un commit particulier.
Silfheed

62

Je recommande cette définition du développeur de github Scott Chacon [ référence vidéo ]:

Head est votre branche actuelle. C'est une référence symbolique. C'est une référence à une branche. Vous avez toujours HEAD, mais HEAD pointera vers l'un de ces autres pointeurs, vers l'une des branches sur lesquelles vous vous trouvez. C'est le parent de votre prochain commit. C'est ce qui devrait être le dernier extrait dans votre répertoire de travail ... C'est le dernier état connu de votre répertoire de travail.

La vidéo entière donnera une introduction équitable à l'ensemble du système git, donc je vous recommande également de tout regarder si vous en avez le temps.


34
Donc la vraie déf. Est "le parent de votre prochain commit"
nicolas

1
et aussi "la chose pointant vers la prochaine branche qui bougera"
nicolas

@nicolas - Je ne pense pas que ce soit vrai. HEAD peut pointer sur n'importe quel commit, il ne doit pas nécessairement pointer sur une branche - quand ce n'est pas le cas, vous êtes en mode "HEAD détaché".
scubbo

23
La vidéo est géniale, mais malheureusement, elle constitue une réponse mal adaptée à Stack Overflow. Et si la vidéo est retirée dans le futur? Ensuite, votre lien ne pointera vers rien. Une meilleure réponse comprendrait une transcription de ce que Scott dit dans la vidéo.

2
Scott dit que HEAD est un pointeur vers une succursale. Mais HEAD peut également signaler d'anciens commits. C'est tellement déroutant.
Fixee

60

HEAD est juste un pointeur spécial qui pointe vers la branche locale sur laquelle vous vous trouvez actuellement.

Dans le livre Pro Git , chapitre 3.1 Git Branching - Branches in a Nutshell , dans la section Création d'une nouvelle branche :

Que se passe-t-il si vous créez une nouvelle succursale? Eh bien, cela crée un nouveau pointeur pour vous déplacer. Supposons que vous créez une nouvelle branche appelée testing. Pour ce faire, utilisez la commande git branch:

$ git branch testing 

Cela crée un nouveau pointeur au même commit que vous êtes actuellement

entrez la description de l'image ici

Comment Git sait-il dans quelle branche vous vous trouvez actuellement? Il garde un pointeur spécial appelé HEAD. Notez que cela est très différent du concept de HEAD dans d'autres VCS auxquels vous pouvez être habitué, tels que Subversion ou CVS. Dans Git, il s'agit d'un pointeur vers la branche locale sur laquelle vous vous trouvez actuellement. Dans ce cas, vous êtes toujours maître. La commande git branch n'a créé qu'une nouvelle branche - elle n'a pas basculé vers cette branche.

entrez la description de l'image ici


4
Nice, pourrait utiliser une photo montrant le boîtier HEAD détaché
Don Hatch

@DonHatch, bonne explication de HEAD détaché stackoverflow.com/a/35301963/1074179
Alexandr

3
Bonne réponse. Les branches ne sont rien d'autre que des validations étiquetées, lorsque vous effectuez de nouvelles validations, cette étiquette est déplacée vers la nouvelle nouvelle validation. Lorsque vous extrayez un commit qui n'a pas d'étiquette, il est dans l'état HEAD détaché. Cela signifie que HEAD pointe vers un commit qui n'a pas d'étiquette de branche. Si vous extrayez l' 34ac2exemple ci-dessus, maintenant HEAD pointerait vers ce commit et il s'appelle un HEAD détaché. Dans cet état, vous pouvez également apporter des modifications, expérimenter et valider des modifications, mais une fois que vous avez extrait une branche différente, vous perdriez toutes vos modifications, à moins bien sûr de créer une nouvelle branche.
sleepwalkerfx

1
@sleepwalkerfx mais vous pouvez extrayez une commettras qui a une étiquette de branche et toujours en état de la tête détachée parce que votre tête est sans pointe plus à l'étiquette de la branche , mais la branche de commettre id
Marc

1
@sleepwalkerfx Je pense que nous parlons de sémantique à ce stade. Vous avez raison, une étiquette de branche est une référence textuelle à un commit particulier. Ce n'est cependant pas un commit. Donc, si vous avez fait un git loget obtenu quelque chose comme commit ad0265... HEAD -> foo ...ça, la foobranche est une référence pour valider l'ID ad0265. Faire une extraction de la référence de texte foon'est pas une tête détachée. Faire une extraction de l'ID de validation ad0265entraînerait une tête détachée. Peut-être que je manque une subtilité de ce que vous communiquez. J'espère que ce mur de texte permet de découvrir où je suis perdu.
Marc

40

En supposant qu'il ne s'agit pas d'un cas spécial appelé "tête détachée", alors, comme indiqué dans le livre O'Reilly Git, 2e édition, p.69, HEADsignifie:

HEADfait toujours référence au commit le plus récent sur la branche actuelle. Lorsque vous changez de branche, HEADest mis à jour pour faire référence au dernier commit de la nouvelle branche.

donc

HEADest la "pointe" de la branche actuelle .

Notez que nous pouvons utiliser HEADpour faire référence au commit le plus récent, et utiliser HEAD~comme commit avant la pointe, et HEAD~~ou HEAD~2comme commit encore plus tôt, et ainsi de suite.


27

Il y a une idée fausse, peut-être subtile, mais importante dans un certain nombre de ces réponses. J'ai pensé ajouter ma réponse pour clarifier les choses.

Qu'est-ce que c'est HEAD?

LA TÊTE, c'est VOUS

HEADest une référence symbolique pointant où que vous soyez dans votre historique de commit. Il vous suit partout où vous allez, quoi que vous fassiez, comme une ombre. Si vous faites un commit,HEAD se déplacera. Si vous réglez quelque chose, HEADse déplacera. Quoi que vous fassiez, si vous avez déménagé quelque part de nouveau dans votre historique de commit, HEADvous avez déménagé avec vous. Pour remédier à une idée fausse commune: vous ne pouvez pas vous en détacher HEAD. Ce n'est pas ce qu'est un état HEAD détaché. Si vous vous retrouvez à penser: "oh non, je suis dans un état de TÊTE détaché! J'ai perdu ma TÊTE!" Rappelez-vous, c'est votre tête. HEAD c'est vous. Vous ne vous êtes pas détaché de la TÊTE, vous et votre TÊTE vous êtes détachés d'autre chose.

À quoi HEAD peut-il s'attacher?

HEADpeut pointer vers un commit, oui, mais ce n'est généralement pas le cas. Permettez-moi de le répéter. Ne pointe généralement HEADpas vers une validation. Il pointe vers une référence de branche. Elle est attachée à cette branche, et lorsque vous faites certaines choses (par exemple, commitou reset), la branche attachée se déplace avecHEAD . Vous pouvez voir ce qu'il indique en regardant sous le capot.

cat .git/HEAD

Normalement, vous obtiendrez quelque chose comme ceci:

ref: refs/heads/master

Parfois, vous obtiendrez quelque chose comme ceci:

a3c485d9688e3c6bc14b06ca1529f0e78edd3f86

C'est ce qui arrive quand HEADpointe directement sur un commit. C'est ce qu'on appelle un HEAD détaché, car il HEADpointe vers autre chose qu'une référence de branche. Si vous faites un commit dans cet état, mastern'étant plus attaché à HEAD, vous ne bougerez plus avec vous. Peu importe où se trouve cet engagement.Vous pouvez être sur le même commit que votre branche principale, mais si HEADpointe sur le commit plutôt que sur la branche, il est détaché et un nouveau commit ne sera pas associé à une référence de branche.

Vous pouvez regarder ceci graphiquement si vous essayez l'exercice suivant. À partir d'un référentiel git, exécutez ceci. Vous obtiendrez quelque chose de légèrement différent, mais les bits clés seront là. Quand il est temps de vérifier le commit directement, utilisez simplement le hachage abrégé que vous obtenez de la première sortie (le voici a3c485d).

git checkout master
git log --pretty=format:"%h:  %d" -1
# a3c485d:   (HEAD -> master)

git checkout a3c485d -q # (-q is for dramatic effect)
git log --pretty=format:"%h:  %d" -1   
# a3c485d:   (HEAD, master)

OK, il y a donc une petite différence dans la sortie ici. Vérifier directement le commit (au lieu de la branche) nous donne une virgule au lieu d'une flèche. Que pensez-vous, sommes-nous dans un état détaché HEAD? HEAD fait toujours référence à une révision spécifique associée à un nom de branche. Nous sommes toujours sur la branche maître, n'est-ce pas?

Maintenant essaye:

git status
# HEAD detached at a3c485d

Nan. Nous sommes dans un état de «tête détachée».

Vous pouvez voir la même représentation de (HEAD -> branch)vs (HEAD, branch)avec git log -1.

En conclusion

HEADest toi. Il indique ce que vous avez vérifié, où que vous soyez. Ce n'est généralement pas un commit, c'est une branche. Si le HEAD fait le point à un commit (ou tag), même si elle est la même commit (ou tag) qu'une branche aussi des points à, vous (et HEAD) ont été détachés de cette branche. Comme vous n'avez pas de branche attachée à vous, la branche ne vous suivra pas lorsque vous effectuez de nouveaux commits. HEADcependant.


1
J'aime cette réponse, car si la documentation décrit la vérité, le logiciel définit la vérité. .git/HEADest ce que le logiciel considère comme HEAD.
Don Branson

2
Pour sa seule définition conceptuelle, cela devrait être la réponse acceptée.
ata

22

HEADfait référence à la validation actuelle vers laquelle pointe votre copie de travail, c'est-à-dire la validation que vous avez actuellement extraite. De la documentation officielle du noyau Linux sur la spécification des révisions Git :

HEAD nomme la validation sur laquelle vous avez basé les modifications dans l'arborescence de travail.

Notez, cependant, que dans la prochaine version 1.8.4 de Git, @peut également être utilisé comme raccourci pourHEAD , comme l'a noté le contributeur Git Junio ​​C Hamano dans son blog Git Blame :

Au lieu de taper "HEAD", vous pouvez dire "@" à la place, par exemple "git log @".

L'utilisateur de Stack Overflow VonC a également trouvé des informations intéressantes sur les raisons@ été choisi comme raccourci dans sa réponse à une autre question .

Il est également intéressant de noter que dans certains environnements, il n'est pas nécessaire de capitaliser HEAD, en particulier dans les systèmes d'exploitation qui utilisent des systèmes de fichiers insensibles à la casse, en particulier Windows et OS X.


17

Jetez un œil à Créer et jouer avec les branches

HEAD est en fait un fichier dont le contenu détermine où la variable HEAD fait référence:

$ cat .git/HEAD
ref: refs/heads/master
$ cat .git/refs/heads/master
35ede5c916f88d8ba5a9dd6afd69fcaf773f70ed

Dans ce référentiel, le contenu du fichier HEAD fait référence à un second fichier nommé refs / heads / master . Le fichier refs / heads / master contient le hachage du commit le plus récent sur la branche master.

Le résultat est que HEAD pointe vers la validation de la branche master à partir du fichier .git / refs / heads / master .

entrez la description de l'image ici


1
Attention: le lien gitguys.com semble pointer vers un domaine parqué.
MKesper

14

Je voudrais juste détailler certaines choses dans la réponse acceptée de Greg Hewgil. Selon le Git Pocket Guide

Branche:

la branche elle-même est définie comme tous les points accessibles dans le graphe de commit à partir du commit nommé (le «tip» de la branche).

TETE: Un type spécial de Réf

La référence spéciale HEAD détermine sur quelle branche vous vous trouvez ...

Réfs

Git définit deux types de références, ou pointeurs nommés, qu'il appelle «refs»:

  • Une référence simple, qui pointe directement vers un ID d'objet (généralement une validation ou une balise)
  • Une référence symbolique (ou symref), qui pointe vers une autre référence (simple ou symbolique)

Comme Greg l'a mentionné, HEAD peut être dans un "état détaché". Ainsi, HEAD peut être soit une simple référence (pour une HEAD détachée), soit une symref.

si HEAD est une référence symbolique pour une branche existante, alors vous êtes «sur» cette branche. Si, d'un autre côté, HEAD est une simple référence nommant directement un commit par son ID SHA-1, alors vous n'êtes pas «sur» une branche, mais plutôt en mode «HEAD détaché», ce qui se produit lorsque vous en vérifiez quelques-uns plus tôt s'engager à examiner.


Merci, @mike! Il s'agit de la première réponse qui clarifie ce qui se passe lorsque vous extrayez un commit antérieur. En regardant le livre sur le site Web de Git, j'ai eu l'impression qu'une "TÊTE détachée" était un état pathologique dans lequel vous ne vous trouviez que si vous faisiez quelque chose de rebasant bizarre. Mais vérifier une validation antérieure n'est pas une chose étrange à faire, et lorsque vous faites cela, HEAD n'est pas "la pointe de la branche actuelle". C'est donc la première fois que j'ai l'impression de vraiment comprendre.
Nat Kuhn

7

Je pense que "HEAD" est le check-out actuel. En d'autres termes, 'HEAD' pointe vers le commit qui est actuellement extrait.

Si vous venez de cloner et de ne pas avoir vérifié, je ne sais pas à quoi cela correspond, probablement un emplacement non valide.


Oui, la référence spéciale HEADcorrespond à la validation que vous avez actuellement extraite. Voir le manuel pour plus de détails (le paragraphe correspondant suit immédiatement la figure 3.4).
Calrion

1
Si vous clonez un référentiel, git vérifiera par défaut la masterbranche - donc HEAD pointera vers master.
sleske

1
@sleske si vous clonez un référentiel sans options spéciales, git vérifiera la tête distante. c'est généralement le cas master, mais ce n'est pas toujours le cas. Voirremote set-head
De Novo

Mon commentaire précédent était correct à l'exception de la référence à remote set-head, qui n'impacte que la branche par défaut locale et ne changera pas la valeur par défaut sur le serveur.
De Novo

5

Head pointe vers la pointe de la branche actuellement extraite.

entrez la description de l'image ici

Dans votre référentiel, il y a un dossier .git. Ouvrez le fichier à cet emplacement: .git \ refs \ heads. Le code (de hachage sha-1) dans ce fichier (maître dans la plupart des cas) sera le commit le plus récent, c'est-à-dire celui vu dans la sortie de la commande git log. Plus d'informations sur le dossier .git: http://gitready.com/advanced/2009/03/23/whats-inside-your-git-directory.html


1
C'est une idée fausse que le bout de la branche actuelle pointe vers le commit le plus récent. Généralement, c'est vrai, mais ce n'est pas rare non plus git reset HEAD^, et le dernier commit (l'ancien tip) n'est plus pointé par le tip de la branche.
LarsH

4

Un excellent moyen de ramener à la maison le point soulevé dans les bonnes réponses est de courir git reflog HEAD, vous obtenez un historique de tous les endroits que HEAD a indiqués.


4

Après avoir lu toutes les réponses précédentes, je voulais toujours plus de clarté. Ce blog sur le site officiel de git http://git-scm.com/blog m'a donné ce que je cherchais:

HEAD: pointeur sur le dernier instantané de validation, parent suivant

Le HEAD dans Git est le pointeur vers la référence de branche actuelle, qui est à son tour un pointeur vers le dernier commit que vous avez fait ou le dernier commit qui a été extrait dans votre répertoire de travail. Cela signifie également que ce sera le parent du prochain commit que vous ferez. Il est généralement plus simple de penser à cela car HEAD est l'instantané de votre dernier commit.


1
L'instantané HEAD: last commit, le parent suivant n'est pas précis. HEADn'est pas un commit; il en indique un.
jub0bs

Pas besoin de sarcasme; avant votre montage, même si la citation était exacte, les grosses lettres en gras étaient une simplification et un peu trompeuses. Maintenant c'est mieux.
jub0bs

1
SI vous lisez la ligne suivante: le HEAD dans Git est le pointeur vers la référence de branche actuelle, qui est à son tour un pointeur vers le dernier commit que vous avez fait ou le dernier commit qui a été extrait dans votre répertoire de travail. - Veuillez noter l'utilisation du mot "pointeur" ici.
user3751385

Bien que la description du «dernier instantané de validation» donne une idée conceptuelle de la façon dont HEAD est généralement censé être utilisé, elle n'est vraiment pas exacte. Si je fais un commit, puis passe à une autre branche, HEAD ne pointe plus vers le dernier instantané de commit. Il pointe vers le dernier instantané de validation sur la branche vers laquelle je viens de basculer. Si je checkout HEAD^, maintenant, HEAD ne pointe même pas vers le dernier instantané de validation sur une branche.
LarsH

"Le parent de votre prochain commit (si vous deviez le faire maintenant)" est plus précis, mais il y a beaucoup d'autres opérations dans git en plus du commit qui sont affectées par HEAD. Vraiment, à la fin, HEAD est la tête, et sa nature est définie par la façon dont elle affecte les commandes comme commit, merge, rebase, log, etc. Mais sur le plan conceptuel peut - être « (pointeur) la position actuelle » est un bon résumé.
LarsH

3

C'est comme ça HEAD soit juste une balise pour le dernier commit que vous avez extrait.

Cela peut être la pointe d'une branche spécifique (telle que "maître") ou une validation intermédiaire d'une branche ("tête détachée")


1

En plus de toutes les définitions, la chose qui m'est restée à l'esprit était que lorsque vous effectuez une validation, GIT crée un objet de validation dans le référentiel. Les objets de validation doivent avoir un parent (ou plusieurs parents s'il s'agit d'une validation de fusion). Maintenant, comment git connaît-il le parent du commit actuel? Donc, HEAD est un pointeur vers la (référence du) dernier commit qui deviendra le parent du commit actuel.


0

Ces deux peuvent vous dérouter:

tête

Pointant vers des références nommées, une branche a récemment soumis. Sauf si vous utilisez la référence du package, les têtes sont généralement stockées dans $ GIT_DIR / refs / heads /.

TÊTE

La branche actuelle ou votre arbre de travail est généralement généré à partir de l'arborescence vers laquelle pointe HEAD. HEAD doit pointer vers une tête, sauf que vous utilisez une tête détachée.


0

Jetez un œil à http://git-scm.com/book/en/Git-Branching-What-a-Branch-Is

Figure 3-5. Fichier HEAD pointant vers la branche sur laquelle vous vous trouvez.


4
Les réponses de lien uniquement sont généralement mal vues sur Stackoverflow, veuillez inclure les informations pertinentes dans votre réponse.
HaskellElephant

2
Ce n'est pas tout à fait correct. Ce qui HEADfait référence dépend de si vous parlez d'un dépôt nu vs non repo. Dans le contexte d'un dépôt non nu, il fait effectivement référence à la validation actuellement extraite, qui ne nécessite pas qu'une branche lui soit attachée (c'est-à-dire lorsqu'il est à l' HEADétat détaché ).

0

Une branche est en fait un pointeur qui contient un ID de validation tel que 17a5 . HEAD est un pointeur sur une branche sur laquelle l'utilisateur travaille actuellement.

HEAD a un filw de référence qui ressemble à ceci:

réf:

Vous pouvez vérifier ces fichiers en accédant à ceux .git/HEAD .git/refsqui se trouvent dans le référentiel dans lequel vous travaillez.


0

Gitest une question de commits.
Et Headpointe sur le commit que vous avez actuellement extrait.

$ git cat-file -t HEAD
commit

Chaque fois que vous extrayez une branche, le HEAD pointe vers le dernier commit sur cette branche. Le contenu de HEAD peut être vérifié comme ci-dessous (pour la branche principale):

$ cat .git/refs/heads/master
  b089141cc8a7d89d606b2f7c15bfdc48640a8e25

-5

En tant que concept, la tête est la dernière révision d'une branche. Si vous avez plus d'une tête par branche nommée, vous l'avez probablement créée lorsque vous effectuez des validations locales sans fusionner, créant ainsi une branche sans nom.

Pour avoir un référentiel "propre", vous devez avoir une tête par branche nommée et toujours fusionner avec une branche nommée après avoir travaillé localement.

Cela est également vrai pour Mercurial .


4
C'est vrai pour Mercurial, mais pas pour Git.
Reinstate Monica - notmaynard
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.