Notions de base sur Git

Si vous ne pouvez lire qu'une seule page pour commencer à utiliser Git, c'est celle-ci. Cette page couvre toutes les commandes de base dont vous avez besoin pour faire la grande majorité des choses que vous passerez éventuellement votre temps à faire avec Git. À la fin de cette page, vous devriez être capable de configurer et d'initialiser un dépôt, de commencer et d'arrêter le suivi des fichiers, et de préparer et de valider les modifications. Nous vous montrerons également comment configurer Git pour ignorer certains fichiers et modèles de fichiers, comment annuler les erreurs rapidement et facilement, comment parcourir l'historique de votre projet et afficher les modifications entre les validations, et comment envoyer et extraire des dépôts à distances.

Obtenir un dépôt Git

Vous obtenez généralement un dépôt Git de deux manières :

• Vous pouvez prendre un répertoire local n'étant actuellement pas sous contrôle de version et le transformer en dépôt Git, ou
• Vous pouvez cloner un dépôt Git existant depuis un autre endroit.

Dans les deux cas, vous vous retrouvez avec un dépôt Git sur votre machine locale, prêt à fonctionner.

Initialisation d'un dépôt dans un répertoire existant

Si vous avez un répertoire de projet n'étant actuellement pas sous contrôle de version et que vous souhaitez commencer à le contrôler avec Git, vous devez d'abord accéder au répertoire de ce projet. Si vous n'avez jamais fait cela, cela semble un peu différent selon le système d'exploitation que vous utilisez :

et tapez :

Cela crée un nouveau sous-répertoire nommé .git contenant tous les fichiers de votre dépôt nécessaires, un squelette de dépôt Git. À ce stade, rien dans votre projet n'est encore suivi.

Si vous souhaitez commencer à contrôler les versions des fichiers existants (par opposition à un répertoire vide), vous devez probablement commencer à suivre ces fichiers et effectuer une validation initiale. Vous pouvez y parvenir avec quelques commandes git add spécifiant les fichiers que vous souhaitez suivre, suivies d'une validation git :

Nous allons voir ce que font ces commandes dans une minute. À ce stade, vous disposez d'un dépôt Git avec des fichiers suivis et un commit initial.

Cloner un dépôt existant

Si vous souhaitez obtenir une copie d'un dépôt Git existant, par exemple un projet auquel vous souhaitez contribuer, la commande dont vous avez besoin est git clone. Si vous connaissez d'autres VCS tels que Subversion, vous remarquerez que la commande est «clone» et non «checkout». Il s'agit d'une distinction importante : au lieu d'obtenir simplement une copie de travail, Git reçoit une copie complète de presque toutes les données dont dispose le serveur. Chaque version de chaque fichier de l'historique du projet est extraite par défaut lorsque vous exécutez git clone. En fait, si le disque de votre serveur est corrompu, vous pouvez souvent utiliser presque tous les clones sur n'importe quel client pour remettre le serveur dans l'état dans lequel il se trouvait lors du clonage (vous risquez de perdre certains hooks côté serveur et autres, mais toutes les données versionnées seront là - voir Obtenir Git sur un serveur pour plus de détails).

Vous pouvez cloner un dépôt avec git clone url. Par exemple, si vous souhaitez cloner la bibliothèque Git linkable appelée libgit2, vous pouvez le faire comme ceci:

Cela crée un répertoire nommé libgit2, initialise un répertoire .git à l'intérieur, récupère toutes les données de ce dépôt et extrait une copie de travail de la dernière version. Si vous accédez au nouveau répertoire libgit2 venant d'être créé, vous y verrez les fichiers du projet, prêts à être traités ou utilisés.

Si vous souhaitez cloner le dépôt dans un répertoire portant un nom autre que libgit2, vous pouvez spécifier le nom du nouveau répertoire comme paramètre supplémentaire :

Cette commande fait la même chose que la précédente, mais le répertoire cible s'appelle mylibgit.

Git propose un certain nombre de protocoles de transfert différents que vous pouvez utiliser. L'exemple précédent utilise le protocole https://, mais vous pouvez également voir git:// ou user@server:path/to/repo.git, utilisant le protocole de transfert SSH. L'installation de Git sur un serveur présentera toutes les options disponibles que le serveur peut configurer pour accéder à votre dépôt Git, ainsi que les avantages et les inconvénients de chacune.

Enregistrement des modifications apportées au dépôt

À ce stade, vous devez disposer d'un dépôt Git authentique sur votre machine locale et d'une copie d'extraction ou de travail de tous ses fichiers devant vous. En règle générale, vous souhaiterez commencer à apporter des modifications et à valider des instantanés de ces modifications dans votre dépôt chaque fois que le projet atteint un état que vous souhaitez enregistrer.

N'oubliez pas que chaque fichier de votre répertoire de travail peut être dans l'un des deux états suivants : suivi ou non suivi. Les fichiers suivis sont des fichiers se trouvant dans le dernier instantané, ainsi que tous les fichiers nouvellement mis en scène ; ils peuvent être non modifiés, modifiés ou mis en scène. En bref, les fichiers suivis sont des fichiers que Git connaît.

Les fichiers non suivis sont tout le reste : tous les fichiers de votre répertoire de travail ne se trouvant pas dans votre dernier instantané et ne se trouvant pas dans votre zone de préparation. Lorsque vous clonez un dépôt pour la première fois, tous vos fichiers seront suivis et non modifiés, car Git vient de les extraire et vous n'avez rien modifié.

Lorsque vous modifiez des fichiers, Git les considère comme modifiés, car vous les avez modifiés depuis votre dernier commit. Au fur et à mesure que vous travaillez, vous organisez de manière sélective ces fichiers modifiés, puis vous validez toutes ces modifications, et le cycle se répète.

Vérification de l'état de vos fichiers

L'outil principal que vous utilisez pour déterminer quels fichiers se trouvent dans quel état est la commande git status. Si vous exécutez cette commande directement après un clonage, vous devriez voir quelque chose comme ceci :

on obtiendra un résultat ressemblant à ceci :

Cela signifie que vous disposez d'un répertoire de travail propre; en d'autres termes, aucun de vos fichiers suivis n'est modifié. Git ne voit pas non plus de fichiers non suivis, sinon ils seraient répertoriés ici. Enfin, la commande vous indique sur quelle branche vous vous trouvez et vous informe qu'elle n'a pas divergé de la même branche sur le serveur. Pour l'instant, cette branche est toujours master, étant la valeur par défaut ; vous ne vous en soucierez pas ici.

Remarque : GitHub a changé le nom de branche par défaut de master à main à la mi-2020, et d'autres hôtes Git ont emboîté le pas. Vous constaterez donc peut-être que le nom de branche par défaut dans certains dépôt nouvellement créés est main et non master. De plus, le nom de branche par défaut peut être modifié, vous pouvez donc voir un nom différent pour la branche par défaut.

Supposons que vous ajoutez un nouveau fichier à votre projet, un simple fichier README. Si le fichier n'existait pas auparavant et que vous exécutez git status, vous voyez votre fichier non suivi comme ceci :

on obtiendra un résultat ressemblant à ceci :

Vous pouvez voir que votre nouveau fichier README n'est pas suivi, car il se trouve sous l'entête «Untracked files» dans votre sortie d'état. Non suivi signifie essentiellement que Git voit un fichier que vous n'aviez pas dans l'instantané précédent (commit), et n'ayant pas encore été mis en scène ; Git ne commencera pas à l'inclure dans vos instantanés de commit jusqu'à ce que vous lui disiez explicitement de le faire. Il le fait pour que vous ne commenciez pas accidentellement à inclure des fichiers binaires générés ou d'autres fichiers que vous n'aviez pas l'intention d'inclure. Vous voulez commencer à inclure README, alors commençons à suivre le fichier.

Suivi des nouveaux fichiers

Pour commencer à suivre un nouveau fichier, vous utilisez la commande git add. Pour commencer à suivre le fichier README, vous pouvez exécuter ceci :

Si vous exécutez à nouveau votre commande d'état, vous pouvez voir que votre fichier README est désormais suivi et préparé pour être validé :

on obtiendra un résultat ressemblant à ceci :

Si vous validez à ce stade, la version du fichier au moment où vous avez exécuté git add est celle étant dans l'instantané historique suivant. Vous vous souvenez peut-être que lorsque vous avez exécuté git init plus tôt, vous avez ensuite exécuté git add files?-?c'était pour commencer à suivre les fichiers dans votre répertoire. La commande git add prend un nom de chemin pour un fichier ou un répertoire ; s'il s'agit d'un répertoire, la commande ajoute tous les fichiers de ce répertoire de manière récursive.

Mise en scène des fichiers modifiés

Modifions un fichier étant déjà suivi. Si vous modifiez un fichier précédemment suivi appelé CONTRIBUTING.md et que vous exécutez à nouveau votre commande git status, vous obtenez quelque chose ressemblant à ceci :

on obtiendra un résultat ressemblant à ceci :

Le fichier CONTRIBUTING.md apparaît dans une section nommée «Changes not staged for commit» - ce qui signifie qu'un fichier suivi a été modifié dans le répertoire de travail mais n'a pas encore été préparé. Pour le préparer, exécutez la commande git add. git add est une commande polyvalente - vous l'utilisez pour commencer à suivre les nouveaux fichiers, préparer les fichiers et faire d'autres choses comme marquer les fichiers en conflit de fusion comme résolus. Il peut être utile de le considérer davantage comme «ajouter précisément ce contenu à la prochaine validation» plutôt que «ajouter ce fichier au projet». Exécutons maintenant git add pour préparer le fichier CONTRIBUTING.md, puis exécutons à nouveau git status :

on obtiendra un résultat ressemblant à ceci :

Les deux fichiers sont mis en scène et seront inclus dans votre prochain commit. À ce stade, supposons que vous vous souveniez d'une petite modification que vous souhaitez apporter à CONTRIBUTING.md avant de le valider. Vous l'ouvrez à nouveau et effectuez cette modification, et vous êtes prêt à valider. Cependant, exécutons git status une fois de plus :

on obtiendra un résultat ressemblant à ceci :

Que se passe-t-il ? Maintenant, CONTRIBUTING.md est répertorié comme étant à la fois mis en scène et non mis en scène. Comment est-ce possible ? Il s'avère que Git met en scène un fichier exactement tel qu'il est lorsque vous exécutez la commande git add. Si vous effectuez un commit maintenant, la version de CONTRIBUTING.md telle qu'elle était lors de la dernière exécution de la commande git add est celle apparaissant dans le commit, et non la version du fichier telle qu'elle apparaît dans votre répertoire de travail lorsque vous exécutez git commit. Si vous modifiez un fichier après avoir exécuté git add, vous devez exécuter git add à nouveau pour mettre en scène la dernière version du fichier :

on obtiendra un résultat ressemblant à ceci :

État court

Bien que la sortie de git status soit assez complète, elle est également assez verbeuse. Git dispose également d'un indicateur d'état court pour que vous puissiez voir vos modifications de manière plus compacte. Si vous exécutez git status -s ou git status --short, vous obtenez une sortie beaucoup plus simplifiée de la commande :

on obtiendra un résultat ressemblant à ceci :

Les nouveaux fichiers n'étant pas suivis ont un ?? à côté d'eux, les nouveaux fichiers ayant été ajoutés à la zone de préparation ont un A, les fichiers modifiés ont un M, etc. La sortie comporte deux colonnes : la colonne de gauche indique l'état de la zone de préparation et la colonne de droite indique l'état de l'arborescence de travail. Ainsi, par exemple, dans cette sortie, le fichier README est modifié dans le répertoire de travail mais pas encore mis en préparation, tandis que le fichier lib/simplegit.rb est modifié et mis en préparation. Le Rakefile a été modifié, mis en préparation puis modifié à nouveau, il y a donc des modifications étant à la fois mises en préparation et non mises en préparation.

Ignorer les fichiers

Souvent, vous aurez une classe de fichiers que vous ne voulez pas que Git ajoute automatiquement ou même vous montre comme étant non suivis. Il s'agit généralement de fichiers générés automatiquement tels que des fichiers journaux ou des fichiers produits par votre système de construction. Dans de tels cas, vous pouvez créer un modèle de liste de fichiers pour les faire correspondre, nommé .gitignore. Voici un exemple de fichier .gitignore :

on obtiendra un résultat ressemblant à ceci :

La première ligne indique à Git d'ignorer tous les fichiers se terminant par «.o» ou «.a» (fichiers objets et archives pouvant être le produit de la construction de votre code). La deuxième ligne indique à Git d'ignorer tous les fichiers dont le nom se termine par un tilde (~), utilisé par de nombreux éditeurs de texte tels qu'Emacs pour marquer les fichiers temporaires. Vous pouvez également inclure un répertoire log, tmp ou pid, une documentation générée automatiquement,... Il est généralement judicieux de configurer un fichier .gitignore pour votre nouveau dépôt avant de commencer afin de ne pas valider accidentellement des fichiers que vous ne voulez pas vraiment dans votre dépôt Git.

Les règles relatives aux modèles que vous pouvez placer dans le fichier .gitignore sont les suivantes :

• Les lignes vides ou les lignes commençant par # sont ignorées.
• Les modèles globales standard fonctionnent et seront appliqués de manière récursive dans toute l'arborescence de travail.
• Vous pouvez commencer les modèles par une barre oblique (/) pour éviter la récursivité.
• Vous pouvez terminer les modèles par une barre oblique (/) pour spécifier un répertoire.
• Vous pouvez nier un modèle en le commençant par un point d'exclamation (!).

Les modèles globaux sont comme des expressions régulières simplifiées que les interpréteurs de commandes utilisent. Un astérisque (*) correspond à zéro ou plusieurs caractères ; [abc] correspond à tout caractère entre crochets (dans ce cas a, b ou c) ; un point d'interrogation (?) correspond à un seul caractère ; et les crochets encadrant des caractères séparés par un tiret ([0-9]) correspondent à tout caractère entre eux (dans ce cas 0 à 9). Vous pouvez également utiliser deux astérisques pour faire correspondre des répertoires imbriqués ; a/**/z correspondrait à a/z, a/b/z, a/b/c/z,...

Voici un autre exemple de fichier .gitignore :

Astuce : GitHub maintient une liste assez complète de bons exemples de fichiers .gitignore pour des dizaines de projets et de langages sur https://github.com/github/gitignore si vous souhaitez un point de départ pour votre projet.

Remarque : Dans le cas simple, un dépôt peut avoir un seul fichier .gitignore dans son répertoire racine, s'appliquant de manière récursive à l'ensemble du dépôt. Cependant, il est également possible d'avoir des fichiers .gitignore supplémentaires dans des sous-répertoires. Les règles de ces fichiers .gitignore imbriqués s'appliquent uniquement aux fichiers sous le répertoire où ils se trouvent. Le dépôt source du noyau Linux contient 206 fichiers .gitignore.

Afficher vos modifications mises en scène et non mises en scène

Si la commande git status est trop vague pour vous (vous voulez savoir exactement ce que vous avez modifié, pas seulement quels fichiers ont été modifiés), vous pouvez utiliser la commande git diff. Nous aborderons git diff plus en détail plus tard, mais vous l'utiliserez probablement le plus souvent pour répondre à ces deux questions : qu'avez-vous modifié mais pas encore mis en scène ? Et qu'avez-vous mis en scène et que vous êtes sur le point de valider ? Bien que git status réponde à ces questions de manière très générale en listant les noms de fichiers, git diff vous montre les lignes exactes ajoutées et supprimées (le correctif, en quelque sorte).

Supposons que vous éditiez et mettiez en scène à nouveau le fichier README, puis que vous éditiez le fichier CONTRIBUTING.md sans le mettre en scène. Si vous exécutez votre commande git status, vous voyez à nouveau quelque chose comme ceci :

on obtiendra un résultat ressemblant à ceci :

Pour voir ce que vous avez modifié mais pas encore mis en scène, tapez git diff sans aucun autre paramètre :

on obtiendra un résultat ressemblant à ceci :

Cette commande compare ce qui se trouve dans votre répertoire de travail avec ce qui se trouve dans votre zone de préparation. Le résultat vous indique les modifications que vous avez apportées et que vous n'avez pas encore préparées.

Si vous souhaitez voir ce que vous avez préparé et qui sera inclus dans votre prochain commit, vous pouvez utiliser git diff --staged. Cette commande compare vos modifications préparées à votre dernier commit :

on obtiendra un résultat ressemblant à ceci :

Il est important de noter que git diff n'affiche pas toutes les modifications apportées depuis votre dernier commit, mais uniquement celles n'étant pas encore mises en scène. Si vous avez mis en scène toutes vos modifications, git diff ne vous donnera aucun résultat.

Autre exemple : si vous mettez en scène le fichier CONTRIBUTING.md, puis le modifiez, vous pouvez utiliser git diff pour voir les modifications du fichier qui sont mises en scène et celles n'étant pas mises en scène. Si notre environnement ressemble à ceci :

on obtiendra un résultat ressemblant à ceci :

Vous pouvez maintenant utiliser git diff pour voir ce qui n'est toujours pas mis en scène :

on obtiendra un résultat ressemblant à ceci :

et git diff --cached pour voir ce que vous avez mis en scène jusqu'à présent (--staged et --cached sont des synonymes) :

on obtiendra un résultat ressemblant à ceci :

Git Diff dans un outil externe : Nous continuerons à utiliser la commande git diff de diverses manières tout au long du reste de cette page. Il existe une autre façon de consulter ces différences si vous préférez un programme de visualisation de différences graphique ou externe. Si vous exécutez git difftool au lieu de git diff, vous pouvez afficher n'importe laquelle de ces différences dans des logiciels comme emerge, vimdiff et bien d'autres (y compris des produits commerciaux). Exécutez git difftool --tool-help pour voir ce qui est disponible sur votre système.

Valider vos modifications

Maintenant que votre zone de préparation est configurée comme vous le souhaitez, vous pouvez valider vos modifications. N'oubliez pas que tout ce qui n'est pas encore validé (c'est-à-dire tous les fichiers que vous avez créés ou modifiés et que vous n'avez pas exécutés git add on depuis que vous les avez modifiés) n'entrera pas dans cette validation. Ils resteront sous forme de fichiers modifiés sur votre disque. Dans ce cas, disons que la dernière fois que vous avez exécuté git status, vous avez vu que tout était validé, vous êtes donc prêt à valider vos modifications. La manière la plus simple de valider est de taper git commit :

Cela lance l'éditeur de votre choix.

Remarque : cela est défini par la variable d'environnement EDITOR de votre interpréteur de commande, généralement vim ou emacs, bien que vous puissiez le configurer comme vous le souhaitez en utilisant la commande git config --global core.editor comme vous l'avez vu dans la page Les premiers pas.

L'éditeur affiche le texte suivant (cet exemple est un écran Vim) :

Vous pouvez voir que le message de validation par défaut contient la dernière sortie de la commande git status commentée et une ligne vide au-dessus. Vous pouvez supprimer ces commentaires et saisir votre message de validation, ou vous pouvez les laisser là pour vous aider à vous souvenir de ce que vous validez.

Remarque : pour un rappel encore plus explicite de ce que vous avez modifié, vous pouvez passer l'option -v à git commit. Cela place également le diff de votre modification dans l'éditeur afin que vous puissiez voir exactement les modifications que vous validez.

Lorsque vous quittez l'éditeur, Git crée votre validation avec ce message de validation (avec les commentaires et le diff supprimés).

Vous pouvez également saisir votre message de validation en ligne avec la commande commit en le spécifiant après un drapeau -m, comme ceci :

on obtiendra un résultat ressemblant à ceci :

Vous avez maintenant créé votre premier commit ! Vous pouvez voir que le commit vous a donné quelques informations sur lui-même : dans quelle branche vous avez effectué le commit (master), quelle somme de contrôle SHA-1 le commit possède (463dc4f), combien de fichiers ont été modifiés et des statistiques sur les lignes ajoutées et supprimées dans le commit.

N'oubliez pas que le commit enregistre l'instantané que vous avez configuré dans votre zone de préparation. Tout ce que vous n'avez pas préparé est toujours là, modifié ; vous pouvez faire un autre commit pour l'ajouter à votre historique. Chaque fois que vous effectuez un commit, vous enregistrez un instantané de votre projet auquel vous pouvez revenir ou le comparer plus tard.

Ignorer la zone de préparation

Bien qu'elle puisse être incroyablement utile pour créer des commits exactement comme vous le souhaitez, la zone de préparation est parfois un peu plus complexe que ce dont vous avez besoin dans votre flux de travail. Si vous souhaitez ignorer la zone de préparation, Git fournit un raccourci simple. L'ajout de l'option -a à la commande git commit permet à Git de préparer automatiquement chaque fichier déjà suivi avant d'effectuer le commit, vous permettant d'ignorer la partie git add :

on obtiendra un résultat ressemblant à ceci :

Notez que vous n'avez pas besoin d'exécuter git add sur le fichier CONTRIBUTING.md dans ce cas avant de valider. C'est parce que le drapeau -a inclut tous les fichiers modifiés. C'est pratique, mais soyez prudent ; parfois, cet indicateur vous amènera à inclure des modifications indésirables.

Suppression de fichiers

Pour supprimer un fichier de Git, vous devez le supprimer de vos fichiers suivis (plus précisément, le supprimer de votre zone de préparation), puis valider. La commande git rm fait cela, et supprime également le fichier de votre répertoire de travail afin que vous ne le voyiez pas comme un fichier non suivi la prochaine fois.

Si vous supprimez simplement le fichier de votre répertoire de travail, il apparaît dans la zone «Modifications non préparées pour validation» (c'est-à-dire non préparées) de votre sortie d'état git :

on obtiendra un résultat ressemblant à ceci :

Ensuite, si vous exécutez git rm, il met en scène la suppression du fichier :

on obtiendra un résultat ressemblant à ceci :

Vous regarder que tout est en ordre :

on obtiendra un résultat ressemblant à ceci :

La prochaine fois que vous validez, le fichier disparaîtra et ne sera plus suivi. Si vous avez modifié le fichier ou l'avez déjà ajouté à la zone de préparation, vous devez forcer la suppression avec l'option -f. Il s'agit d'une fonction de sécurité pour empêcher la suppression accidentelle de données n'ayant pas encore été enregistrées dans un instantané et ne pouvant pas être récupérées à partir de Git.

Une autre chose utile que vous pouvez faire est de conserver le fichier dans votre arborescence de travail mais de le supprimer de votre zone de préparation. En d'autres termes, vous pouvez conserver le fichier sur votre disque dur mais ne plus laisser Git le suivre. Cela est particulièrement utile si vous avez oublié d'ajouter quelque chose à votre fichier .gitignore et que vous l'avez accidentellement mis en scène, comme un gros fichier journal ou un tas de fichiers .a compilés. Pour ce faire, utilisez l'option --cached :

Vous pouvez transmettre des fichiers, des répertoires et des modèles de fichiers globaux à la commande git rm. Cela signifie que vous pouvez effectuer des opérations telles que :

Notez la barre oblique inverse (\) devant le *. Ceci est nécessaire car Git effectue sa propre extension de nom de fichier en plus de celle de votre shell. Cette commande supprime tous les fichiers ayant l'extension .log dans le répertoire log/. Ou, vous pouvez faire quelque chose comme ceci :

Cette commande supprime tous les fichiers dont les noms se terminent par un ~.

Déplacer des fichiers

Contrairement à de nombreux autres VCS, Git ne suit pas explicitement les mouvements de fichiers. Si vous renommez un fichier dans Git, aucune métadonnée n'est entreposée dans Git indiquant que vous avez renommé le fichier. Cependant, Git est assez intelligent pour le savoir après coup.

Il est donc un peu déroutant que Git dispose d'une commande mv. Si vous souhaitez renommer un fichier dans Git, vous pouvez exécuter quelque chose comme :

et cela fonctionne bien. En fait, si vous exécutez quelque chose comme ceci et regardez l'état, vous verrez que Git le considère comme un fichier renommé :

Vous regarder que tout est en ordre :

Cependant, cela équivaut à exécuter quelque chose comme ceci :

Git comprend implicitement qu'il s'agit d'un renommage, donc peu importe que vous renommiez un fichier de cette façon ou avec la commande mv. La seule différence réelle est que git mv est une commande au lieu de trois : c'est une fonction pratique. Plus important encore, vous pouvez utiliser n'importe quel outil pour renommer un fichier et traiter l'ajout/le rm plus tard, avant de valider.

Afficher l'historique des commits

Après avoir créé plusieurs commits, ou si vous avez cloné un dépôt avec un historique de commits existant, vous souhaiterez probablement revenir en arrière pour voir ce qui s'est passé. L'outil le plus simple et le plus puissant pour ce faire est la commande git log.

Ces exemples utilisent un projet très simple appelé «helloworld-pascal». Pour obtenir le projet, exécutez :

Lorsque vous exécutez git log dans ce projet, vous devriez obtenir une sortie ressemblant à ceci :

on obtiendra un résultat ressemblant à ceci :