Comment réinitialiser ou rétablir un fichier dans une révision spécifique?


4519

J'ai apporté quelques modifications à un fichier qui a été validé plusieurs fois dans le cadre d'un groupe de fichiers, mais je souhaite maintenant réinitialiser / rétablir les modifications qu'il contient dans une version précédente.

J'ai fait un git logavec un git diffpour trouver la révision dont j'ai besoin, mais je n'ai aucune idée de comment ramener le fichier à son ancien état dans le passé.


11
Après le retour, n'oubliez pas --cachedlors de la vérification git diff. lien
Geoffrey Hale

5
J'ai trouvé votre question quand j'ai googlé la mienne. Mais après avoir lu la solution, j'ai vérifié mon journal et j'ai découvert que j'avais fait des changements de thouse en tant que commit autonome, alors j'ai fait git revenir pour ce commit, et tout le reste est resté comme je le voulais. Pas une solution, juste une autre façon de le faire parfois.
sudo97

Réponses:


6140

En supposant que le hachage du commit que vous voulez est c5f567:

git checkout c5f567 -- file1/to/restore file2/to/restore

La page de manuel git checkout donne plus d'informations.

Si vous souhaitez revenir à la validation avant c5f567, ajoutez ~1(où 1 est le nombre de validations que vous souhaitez revenir en arrière, cela peut être n'importe quoi):

git checkout c5f567~1 -- file1/to/restore file2/to/restore

En guise de remarque, j'ai toujours été mal à l'aise avec cette commande car elle est utilisée à la fois pour les choses ordinaires (changement entre les branches) et pour les choses inhabituelles et destructrices (suppression des modifications dans le répertoire de travail).


12
@shadowhand: Y a-t-il un moyen d'inverser cela, c'est donc la version juste après?
aliteralmind

16
@aliteralmind: Non, malheureusement, la notation de raccourci de l'historique Git ne fait que reculer dans l'histoire.
Greg Hewgill

46
Si vous allez utiliser un nom de branche pour abcde (par exemple develop), vous voudrez git checkout develop -- file/to/restore(notez le double tiret)
Ohad Schneider

8
@aliteralmind: En fait, oui, il existe un moyen de le faire: "git log --reverse -1 --ancestry-path yourgitrev..master", puis utilisez les options appropriées pour obtenir juste le git rev. --ancestry-path "tracera une ligne" entre deux commits et -1 vous montrera une seule version, et --reverse s'assurera que la première entrée émise est la plus ancienne.
Chris Cogdon

6
Personnellement, je trouve HEAD ^ plus facile à taper que HEAD ~ 1 :)
juzzlin

606

Vous pouvez rapidement consulter les modifications apportées à un fichier à l'aide de la commande diff:

git diff <commit hash> <filename>

Ensuite, pour rétablir un fichier spécifique à ce commit, utilisez la commande reset:

git reset <commit hash> <filename>

Vous devrez peut-être utiliser le --hard option si vous avez des modifications locales.

Un bon flux de travail pour gérer les points de cheminement consiste à utiliser des balises pour marquer proprement les points de votre chronologie. Je ne comprends pas très bien votre dernière phrase, mais ce que vous voudrez peut-être, c'est de diverger d'une branche d'un point dans le temps. Pour ce faire, utilisez la commande de paiement pratique:

git checkout <commit hash>
git checkout -b <new branch name>

Vous pouvez ensuite rebaser cela sur votre ligne principale lorsque vous êtes prêt à fusionner ces modifications:

git checkout <my branch>
git rebase master
git checkout master
git merge <my branch>

7
La commande 'git checkout <commit hash>' m'a rendu ma version la plus ancienne du projet exactement celle pour laquelle je cherchais Merci Chris.
vidur punj

48
Pour rétablir le fichier git checkout <commit hash> <filename>a mieux fonctionné pour moi quegit reset
Motti Strom

3
Je voulais une première version d'un seul fichier car j'avais écrasé 150 lignes avec un copier / coller mal choisi. git checkout <commit hash> <filename>travaillé pour moi. Cela ne devrait pas être la réponse acceptée, à mon humble avis. git resetnon.
harperville

24
ne peut pas utiliser git resetpour réinitialiser un seul fichier, vous obtiendrez une erreurfatal: Cannot do hard reset with paths
slier

13
Quel slier a dit: vous ne pouvez pas git reset --hard <commit hash> <filename>. Ce sera une erreur avec fatal: Cannot do hard reset with paths.ce que Motti Strom a dit: utilisationgit checkout <commit hash> <filename>
Hawkeye Parker

366

Vous pouvez utiliser n'importe quelle référence à un commit git, y compris le SHA-1 si cela vous convient le mieux. Le fait est que la commande ressemble à ceci:

git checkout [commit-ref] -- [filename]


22
Quelle est la différence entre cette réponse, qui a --, et la réponse acceptée qui ne l'est pas?
2rs2ts

80
Dans git, un '-' devant la liste des fichiers indique à git que tous les arguments suivants doivent être interprétés comme des noms de fichiers, pas comme des noms de branche ou autre chose. C'est parfois un désambiguïsateur utile.
foxxtrot

49
Le '-' n'est pas seulement une convention git, mais quelque chose que vous trouvez à divers endroits sur la ligne de commande * nix. rm -- -f(supprimer un fichier nommé -f) semble être l'exemple canonique. Plus de détails ici
Hawkeye Parker

7
Ajoutez simplement à ce que @HawkeyeParker a dit, la rmcommande utilise getopt (3) pour analyser ses arguments. getoptest la commande pour analyser les arguments de commande. gnu.org/software/libc/manual/html_node/Getopt.html
Devy

2
@ Honey Oui, c'est ce que je veux dire, et oui, probablement pas du tout courant. J'ai vu cet exemple à divers endroits, peut-être juste pour le rendre mémorable: rm -f est bien connu pour être effrayant / dangereux. Mais le fait est que dans * nix, un nom de fichier peut commencer par un «-», ce qui confondra divers interprètes de ligne de commande qui, lorsqu'ils voient un «-», s'attendent à ce qu'une option de commande suive. Il peut s'agir de n'importe quel fichier commençant par '-'; par exemple, "-mySpecialFile".
Hawkeye Parker

288
git checkout -- foo

Cela sera réinitialisé foosur HEAD. Vous pouvez également:

git checkout HEAD^ foo

pour une révision en arrière, etc.


12
Je suggère d'utiliser la syntaxe git checkout -- foopour éviter toute erreur si fooquelque chose de spécial (comme un répertoire ou un fichier appelé -f). Avec git, si vous n'êtes pas sûr, préfixez toujours tous les fichiers et répertoires avec l'argument spécial --.
Mikko Rantalainen

8
Une note supplémentaire au commentaire de Mikko: --n'est pas une commande git et n'est pas spéciale à git. C'est un bash intégré pour signifier la fin des options de commande. Vous pouvez également l'utiliser avec de nombreuses autres commandes bash.
matthaeus

14
@matthaeus n'est pas non plus spécifique à bash ni à une fonction shell du tout. C'est une convention implémentée dans de nombreuses commandes différentes (et prise en charge par getopt).
Greg Hewgill

2
Non, ce --n'est pas un mot spécial intégré dans bash. Mais c'est une convention commune prise en charge par de nombreux analyseurs de ligne de commande et utilisée par de nombreuses CLI, y compris git.
Emil Lundberg

123

Et pour revenir à la dernière version validée, qui est le plus souvent nécessaire, vous pouvez utiliser cette commande plus simple.

git checkout HEAD file/to/restore

2
quelle est la différence entre ceci (git checkout HEAD file / to / restore) et git reset --hard file / to / restore ???
Motti Shneor du

2
1) plus facile à retenir de manière plus générale 2) aucun souci d'appuyer sur Entrée avant d'entrer le nom du fichier
Roman Susi

105

J'ai eu le même problème tout à l'heure et j'ai trouvé cette réponse plus facile à comprendre ( commit-refest la valeur SHA de la modification dans le journal que vous souhaitez revenir):

git checkout [commit-ref] [filename]

Cela mettra cette ancienne version dans votre répertoire de travail et à partir de là, vous pouvez la valider si vous le souhaitez.


91

Si vous savez combien de commits vous devez revenir en arrière, vous pouvez utiliser:

git checkout master~5 image.png

Cela suppose que vous êtes sur la masterbranche, et la version que vous souhaitez est 5 validée.


80

Je pense que je l'ai trouvé .... sur http://www-cs-students.stanford.edu/~blynn/gitmagic/ch02.html

Parfois, vous voulez simplement revenir en arrière et oublier chaque changement après un certain point, car ils ont tous tort.

Commencer avec:

$ git log

qui affiche une liste des validations récentes et leurs hachages SHA1.

Ensuite, saisissez:

$ git reset --hard SHA1_HASH

pour restaurer l'état d'une validation donnée et effacer définitivement toutes les nouvelles validations de l'enregistrement.


24
Git n'enlève jamais rien. Vos anciens commits sont toujours là, mais à moins qu'une pointe de branche ne les pointe, ils ne sont plus accessibles. git reflog les affichera jusqu'à ce que vous nettoyiez votre dépôt avec git-gc.
Bombe

1
@Bombe: Merci pour l'information. J'avais extrait une ancienne version d'un fichier. Après avoir lu votre commentaire, j'ai pu utiliser "gitref" pour rechercher le hachage SHA1 partiel, et utiliser "checkout" pour revenir à la version la plus récente. D'autres utilisateurs de git pourraient trouver ces informations utiles.
Winston C. Yang

4
éventuellement suivi d'ungit push --force
bshirley

4
Si vous avez des modifications non validées, vous les perdrez si vous effectuez une réinitialisation git --hard
Boklucius

5
@Bombe - "Git ne supprime jamais rien. Vos anciens commits sont toujours là mais à moins qu'une pointe de branche ne les pointe, ils ne sont plus joignables." - mais les commits comme celui-ci sont élagués après un certain temps, donc "Git ne supprime jamais rien" est faux.
Bulwersator

61

Cela a fonctionné pour moi:

git checkout <commit hash> file

Validez ensuite le changement:

git commit -a

54

Vous devez être prudent lorsque vous dites "rollback". Si vous aviez auparavant une version d'un fichier dans la validation $ A, puis que vous avez ensuite apporté deux modifications dans deux validations distinctes $ B et $ C (vous voyez donc la troisième itération du fichier), et si vous dites " Je veux revenir au premier ", tu le penses vraiment?

Si vous voulez vous débarrasser des changements à la fois la deuxième et la troisième itération, c'est très simple:

$ git checkout $A file

puis vous validez le résultat. La commande demande "Je veux extraire le fichier de l'état enregistré par le commit $ A".

D'un autre côté, vous vouliez vous débarrasser du changement apporté par la deuxième itération (c'est-à-dire commit $ B), tout en conservant ce que $ C a fait dans le fichier, vous voudriez revenir sur $ B

$ git revert $B

Notez que celui qui a créé le commit $ B peut ne pas avoir été très discipliné et avoir commis des modifications totalement indépendantes dans le même commit, et cette annulation peut toucher des fichiers autres que le fichier que vous voyez des changements offensants, vous pouvez donc vouloir vérifier soigneusement le résultat après avoir fait donc.


Je l'ai fait, mais un "fichier journal git" indiquerait que j'étais sur le commit d'origine, HEAD. Il semblait que "git checkout" échouait. Cependant, un état git a montré que le fichier a été réellement modifié et un "fichier git diff - staged" montrerait les changements réels. En outre, un "état git" a également montré que le fichier avait changé. N'utilisez donc pas "git log" ici pour suivre les fichiers modifiés.
Frederick Ollinger

37

Curieusement, git checkout foocela ne fonctionnera pas si la copie de travail se trouve dans un répertoire nommé foo; Cependant, à la fois git checkout HEAD fooet git checkout ./foosera:

$ pwd
/Users/aaron/Documents/work/foo
$ git checkout foo
D   foo
Already on "foo"
$ git checkout ./foo
$ git checkout HEAD foo

26
ougit checkout -- foo
knittl

32

Voici comment ça rebasemarche:

git checkout <my branch>
git rebase master
git checkout master
git merge <my branch>

Supposons que vous ayez

---o----o----o----o  master
    \---A----B       <my branch>

Les deux premières commandes ... commit git checkout git rebase master

... consultez la branche des modifications que vous souhaitez appliquer à la masterbranche. La rebasecommande prend les validations de <my branch>(qui ne se trouvent pas dans master) et les réapplique au chef de master. En d'autres termes, le parent du premier commit dans <my branch>n'est plus un commit précédent dans l' masterhistorique, mais le responsable actuel de master. Les deux commandes sont les mêmes que:

git rebase master <my branch>

Il pourrait être plus facile de se souvenir de cette commande car les branches "base" et "modify" sont explicites.

. Le résultat final de l'historique est:

---o----o----o----o   master
                   \----A'----B'  <my branch>

Les deux dernières commandes ...

git checkout master
git merge <my branch>

... effectuez une fusion rapide pour appliquer toutes les <my branch>modifications master. Sans cette étape, la validation de rebase n'est pas ajoutée à master. Le résultat final est:

---o----o----o----o----A'----B'  master, <my branch>

masteret les <my branch>deux références B'. De plus, à partir de ce moment, il est possible de supprimer la <my branch>référence.

git branch -d <my branch>

26

Depuis git v2.23.0, il existe une nouvelle méthode de restauration git qui est supposée assumer une partie de ce qui git checkoutétait responsable (même la réponse acceptée mentionne ce qui git checkoutest assez déroutant). Voir les faits saillants des changements sur le blog github .

Le comportement par défaut de cette commande est de restaurer l'état d'une arborescence de travail avec le contenu provenant de la source paramètre (qui dans votre cas sera un hachage de validation).

Donc, selon la réponse de Greg Hewgill (en supposant que le hachage de validation est c5f567), la commande ressemblerait à ceci:

git restore --source=c5f567 file1/to/restore file2/to/restore

Ou si vous souhaitez restaurer le contenu d'un commit avant c5f567:

git restore --source=c5f567~1 file1/to/restore file2/to/restore

24

Première réinitialisation de la tête du fichier cible

git reset HEAD path_to_file

Deuxième extraction de ce fichier

git checkout -- path_to_file

4
+1, mais pas sûr de l'intention de réinitialiser HEAD. Il peut être nécessaire ou non. Dans ma situation, je ne voulais que restaurer un fichier particulier dans la version du référentiel (ce qui gardait les modifications locales restantes intactes. L'exécution de la deuxième étape ci-dessus était suffisante pour moi
fkl

Oui, il me suffit d'exécuter la 2e commande. Comme -> shellhacks.com/git-revert-file-to-previous-commit
javaPlease42

22

git-alias, awk et shell-fonctions à la rescousse!

git prevision <N> <filename>

<N>est le nombre de révisions du fichier à restaurer pour le fichier <filename>.
Par exemple, pour extraire la révision précédente immédiate d'un seul fichier x/y/z.c, exécutez

git prevision -1 x/y/z.c

Comment fonctionne git prevision?

Ajoutez ce qui suit à votre gitconfig

[alias]
        prevision = "!f() { git checkout `git log --oneline $2 |  awk -v commit="$1" 'FNR == -commit+1 {print $1}'` $2;} ;f"

La commande essentiellement

  • effectue une git log sur le fichier spécifié et
  • sélectionne le commit-id approprié dans l'historique du fichier et
  • exécute un git checkoutà l'ID de validation pour le fichier spécifié.

Essentiellement, tout ce que l'on ferait manuellement dans cette situation,
enveloppé dans un beau et efficace git-alias - git-prevision


20

Je dois brancher EasyGit ici, qui est un wrapper pour rendre git plus accessible aux novices sans dérouter les utilisateurs chevronnés. L'une des choses qu'il fait est de donner plus de sens àgit revert . Dans ce cas, vous diriez simplement:

eg revert foo/bar foo/baz


1
Ça devrait l'être eg revert --in REVISON -- FILENAME. C'est --inimportant. Pour les utilisateurs de Windows: Ouvrez git bash. Exécutez echo %PATH. Le premier chemin doit être dans votre répertoire utilisateur se terminant par bin. Créez ce chemin. Conserver par exemple là-bas. Nommez-le eg. Non eg.txt.
koppor

20

Dans le cas où vous souhaitez restaurer un fichier à une validation précédente (et le fichier que vous souhaitez rétablir déjà validé), vous pouvez utiliser

git checkout HEAD^1 path/to/file

ou

git checkout HEAD~1 path/to/file

Ensuite, mettez en scène et validez la "nouvelle" version.

Armé de la connaissance qu'un commit peut avoir deux parents dans le cas d'une fusion, vous devez savoir que HEAD ^ 1 est le premier parent et HEAD ~ 1 est le deuxième parent.

L'un ou l'autre fonctionnera s'il n'y a qu'un seul parent dans l'arbre.


19

De nombreuses suggestions ici, la plupart dans le sens de git checkout $revision -- $file. Quelques alternatives obscures:

git show $revision:$file > $file

Et aussi, je l'utilise beaucoup juste pour voir temporairement une version particulière:

git show $revision:$file

ou

git show $revision:$file | vim -R -

(OBS: $filedoit être préfixé ./s'il s'agit d'un chemin relatif pourgit show $revision:$file travailler)

Et le plus étrange encore:

git archive $revision $file | tar -x0 > $file

1
C'est une bonne alternative si vous n'êtes pas sûr de la version de validation que vous souhaitez et que vous devez "jeter un œil" sans écraser votre répertoire de travail.
wisbucky

18

Notez toutefois que git checkout ./fooet git checkout HEAD ./foo ne sont pas exactement la même chose; cas d'espèce:

$ echo A > foo
$ git add foo
$ git commit -m 'A' foo
Created commit a1f085f: A
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 foo
$ echo B >> foo
$ git add foo
$ echo C >> foo
$ cat foo
A
B
C
$ git checkout ./foo
$ cat foo
A
B
$ git checkout HEAD ./foo
$ cat foo
A

(La deuxième addétape du fichier dans l'index, mais il n'est pas validé.)

Git checkout ./foosignifie revenir au chemin ./foode l' index ; l'ajout HEADindique à Git de rétablir ce chemin dans l'index à sa HEADrévision avant de le faire.


14

Pour moi, aucune des réponses ne semblait vraiment claire et je voudrais donc ajouter la mienne qui semble super facile.

J'ai un commit abc1et après cela j'ai fait plusieurs (ou une modification) dans un fichier file.txt.

Maintenant, disons que j'ai foiré quelque chose dans le fichier file.txtet que je veux revenir à un commit précédent abc1.

1 git checkout file.txt.: cela supprimera les modifications locales, si vous n'en avez pas besoin

2 git checkout abc1 file.txt.: cela amènera votre fichier à votre recherche version

3 git commit -m "Restored file.txt to version abc1".: cela entraînera votre réversion.

  1. git push : cela poussera tout sur le référentiel distant

Entre les étapes 2 et 3, bien sûr, vous pouvez faire git statuspour comprendre ce qui se passe. Habituellement, vous devriez voir le file.txtdéjà ajouté et c'est pourquoi il n'y a pas besoin d'un git add.


2
OK donc je suppose que les étapes 1. et 2. s'excluent mutuellement: si abc1 est votre dernier commit il n'y a pas besoin de 2. et s'il y a eu d'autres commits après abc1 vous pouvez directement faire 2.
Jean Paul

13
  1. Git revert file to a specific commit
git checkout Last_Stable_commit_Number -- fileName

2.Git restaurer le fichier dans une branche spécifique

git checkout branchName_Which_Has_stable_Commit fileName

11

Pour accéder à une version de validation précédente du fichier, obtenez le numéro de validation, dites eb917a1 puis

git checkout eb917a1 YourFileName

Si vous avez juste besoin de revenir à la dernière version validée

git reset HEAD YourFileName
git checkout YourFileName

Cela vous amènera simplement au dernier état validé du fichier


10

git checkout ref | commitHash - filePath

par exemple

git checkout HEAD~5 -- foo.bar
or 
git checkout 048ee28 -- foo.bar

10

De nombreuses réponses ici prétendent utiliser git reset ... <file>ou, git checkout ... <file>mais ce faisant, vous perdrez toutes les modifications sur<file> la validation après la validation que vous souhaitez annuler.

Si vous souhaitez annuler les modifications d'un commit sur un seul fichier, comme vous le git revertferiez mais pour un seul fichier (ou dire un sous-ensemble des fichiers de commit), je suggère d'utiliser les deux git diffet git applycomme ça (avec <sha>= le hachage du vous vous engagez à revenir):

git diff <sha>^ <sha> path/to/file.ext | git apply -R

Fondamentalement, il générera d'abord un patch correspondant aux modifications que vous souhaitez annuler, puis appliquera le patch à l'envers pour supprimer ces modifications.

Bien sûr, cela ne fonctionnera pas si les lignes inversées ont été modifiées par un commit entre <sha1>et HEAD(conflit).


Cela devrait être la réponse approuvée. Puis-je suggérer une version légèrement simplifiée:git show -p <sha> path/to/file.ext|git apply -R
Amaury D

vous pouvez utiliser à la <sha>^!place de<sha>^ <sha>
cambunctious

8

Utilisez git logpour obtenir la clé de hachage pour une version spécifique, puis utilisezgit checkout <hashkey>

Remarque: N'oubliez pas de taper le hachage avant le dernier. Le dernier hachage indique votre position actuelle (HEAD) et ne change rien.


7

De toute évidence, quelqu'un doit soit écrire un livre intelligible sur git, soit git doit être mieux expliqué dans la documentation. Face à ce même problème j'ai deviné que

cd <working copy>
git revert master

annulerait le dernier commit qui semble le faire.

Ian


7

Vous pouvez le faire en 4 étapes:

  1. annuler la validation entière avec le fichier que vous souhaitez restaurer spécifiquement - cela créera une nouvelle validation sur votre branche
  2. réinitialisation logicielle qui valide - supprime la validation et déplace les modifications dans la zone de travail
  3. sélectionner les fichiers à la main pour les restaurer et les valider
  4. déposez tous les autres fichiers dans votre zone de travail

Ce que vous devez saisir dans votre terminal :

  1. git revert <commit_hash>
  2. git reset HEAD~1
  3. git add <file_i_want_to_revert> && git commit -m 'reverting file'
  4. git checkout .

bonne chance


cela ne revient-il pas à TOUS les changements?
arcee123

1
@ arcee123 Oui, mais la réinitialisation suivante annule la restauration de toutes les modifications. Le problème est que cela git-revertne fonctionne que sur l'ensemble du repo, donc pour compenser, nous devons annuler tout le reste.
Timothy

2
Je recommande d'utiliser: 1. git revert --no-commit <commit_hash>2. git reset HEADCela enregistre un commit supplémentaire flottant et n'effectue toutes les modifications que dans votre répertoire de travail.
Timothy

La réponse de @greg-hewgill est meilleure et précise. Celui-ci est moche et ne doit pas être utilisé.
Daniel Tranca

C'est exactement ce qui est nécessaire pour un véritable retour de fichiers spécifiques. J'avais besoin d'annuler les modifications apportées à quelques fichiers d'une validation antérieure qui avaient déjà été transférés vers le référentiel distant. J'ai annulé, réinitialisé et validé le résultat: git revert _oldcommit_ --no-commit git reset -- _unchanged1_ _unchanged2_ ... git commit -m "branch without changes to specific files"le nouveau conseil de branche reflétait toutes les modifications, à l'exception des fichiers restaurés.
Suncat2000

7

Il s'agit d'une étape très simple. Extraire le fichier de l'ID de validation que nous voulons, ici un ID de validation avant, puis juste git commit modifier et nous avons terminé.

# git checkout <previous commit_id> <file_name>
# git commit --amend

C'est très pratique. Si nous voulons apporter n'importe quel fichier à n'importe quel ID de validation précédent en haut de la validation, nous pouvons facilement le faire.


5
git revert <hash>

Annulera un commit donné. Il semble que vous git revertn'affectiez que le commit le plus récent.

Cela ne résout pas votre problème, si vous souhaitez annuler une modification dans un fichier spécifique et que la validation a changé plus que ce fichier.


5

si vous validez un mauvais fichier lors de vos dernières validations, suivez les instructions:

  1. arborescence open source, passez à ce commit

arbre open source

  1. changer les lignes et trouver votre commit que le mauvais fichier envoyé comme commit

entrez la description de l'image ici

  1. vous pouvez voir la liste de vos modifications dans ce commit liste des fichiers dans l'arborescence source
  2. sélectionnez-le puis cliquez sur ... boutons à droite ... cliquez sur fichier inversé
  3. alors vous pouvez le voir sur l'onglet d'état du fichier en bas à gauche, puis cliquez sur unstage:

onglet d'état du fichier

  1. ouvrez votre code Visual Studio et revenez en arrière en validant vos fichiers supprimés
  2. après tous, vous pouvez voir les résultats de votre dernier commit dans l'arborescence source

entrez la description de l'image ici

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.