gitgit >= 2.23Nous utiliserons les commandes restore et switch introduites dans la version 2.23 de git, ce sont des alternatives aux commandes historiques checkout et reset qui sont surchargées et causent trop de confusions.
git et vérifiez que la commande git --version retourne une version supérieure à 2.23.tigDe nombreuses interfaces graphiques permettent de visualiser l'historique et l'état du dépôt.
Le paquet tig fournit une interface curses permettant une telle visualisation dans votre terminal.
tigLes commits contiennent le nom et l'adresse mail de la personne qui l'a crée (cette personne est appelée committer).
Pour que les commits vous identifient correctement comme étant l'auteur et/ou le committer, tapez les commandes suivantes :
$ git config --global user.name "<Prénom> <Nom>"
$ git config --global user.email "<adresse_mail>"Utilisez votre adresse mail universitaire.
Si votre version de git est au moins 2.28 et si vous voulez que la branche par défaut des dépots que vous allez créer s'appelle main plutôt que master, tapez la commande :
$ git config --global init.defaultBranch mainObservez le résultat dans le fichier ~/.gitconfig.
git-test/ et initialisez-y un dépôt git.plop dont le contenu est la chaîne hop.plop à la staging area (index).plop en remplaçant la chaîne de caractères hop par hap.plop à la staging area (index).toto dont le contenu contient 4 lignes de votre choix.toto à la staging area (index).toto.toto à la staging area (index).toto.toto à la staging area (index).tig (cliquez sur entrée pour voir les diffs).toto, supprimez sa première ligne et sauvegardez-le.toto grâce à git.toto, modifiez sa 4e ligne et sauvegadez-le.toto à la staging area.toto soit identique à celui du 3e commit.Cette partie n'est pas prioritaire (vous pouvez passer au prochain paragraphe et y revenir plus tard).
Lisez la page du slide intitulée "Ne versionner que le source, ignorer les sous-produits".
Créez un répertoire nommé programmation/ dans votre répertoire de travail.
Créez-y un fichier de type "Hello world" nommé hello.c, et commitez-le.
Compilez-le et exécutez-le.
Que donne la commande
$ git statusCréez un fichier .gitgnore à la racine de votre répertoire de travail (worktree) de sorte à éviter de commiter par inadvertance le fichier compilé.
Que donne la commande
$ git statusSi les fichier compilés n'apparaissent plus, commitez le fichier .gitgnore.
Modifiez le fichier hello.c de sorte à ce qu'il fasse plutôt "Hello git".
Compilez-le et exécutez-le.
Commitez-le.
essaiessai votre branche courante).test.txt, ajoutez-le à la staging area et commitez.milieu-testtest.txt, ajoutez-le à la staging area et commitez..git/HEAD et des différents fichiers et sous-répertoires du répertoire .git/refs/git gère ses références (tags, branches, branche courante).main.plop, ajoutez-le à la staging area et commitez.essai dans la branche courante main.tig.À faire avec un·e camarade (vous pouvez passer au prochain paragraphe et y revenir plus tard).
Demandez à votre camarade de dessiner sur une feuille un DAG un peu complexe avec des tags et des branches à plusieurs endroits.
Amusez-vous à réaliser ce DAG comme le DAG des commits de votre dépôt avec les commandes add, commit, branch, switch, tag, merge.
Si vous ne voulez pas perdre de temps à créer du contenu à commiter mais vous concentrer sur la gestion du DAG, vous pouvez au choix (ou successivement) :
dessiner directement votre DAG dans le simulateur learngitbranching
utiliser les alias suivants (le premier crée un fichier vide avec un nom aléatoire, l'ajoute dans la staging area et le commite avec un message aléatoire, le second dessine le DAG des commits en ASCII-art) :
$ alias Commit_un_truc='R=$RANDOM;touch f$R;git add f$R;git commit -m c$R'
$ alias DAG='git log --graph --oneline --all --decorate --color'Ainsi, il suffit de taper la commande Commit_un_truc (utilisez l'autocomplétion !) pour créer un nouveau commit et DAG pour observer le DAG obtenu.
Demandez à votre camarade de choisir une branche et un de ses ancêtres lointains.
Faites de l'ancêtre choisi le commit courant sans utiliser son hash, mais avec l'adressage relatif à la branche choisie (cf slides).
Cherchez ensemble des commits qui possèdent des ancêtres joignables par plusieurs chemins orientés dans le DAG. Faites un git diff entre ces deux adresses du même commit pour vérifier qu'il n'y a pas de différence (et valider votre hypothèse sur les chemins).
Imaginez d'autres challenges de ce type de sorte à devenir à l'aise dans la navigation dans le DAG des commits. Amusez-vous. Si vous découvrez un exercice instructif, n'hésitez pas à le partager sur le salon sysadmin_git du mattermost.
Inversez les rôles.
Lorsque vous avez fini avec les exercices précédents, constituez un groupe d'au moins 5 étudiant·es pour travailler ensemble sur un dépôt distant commun, par exemple votre groupe de projet. Vous pouvez utiliser le salon mattermost sysadmin_git pour chercher des camarades.
Lorsque votre groupe est constitué, choisissez un nom de dépôt distant dans la liste suivante, et reservez-le en l'annonçant sur le salon sysadmin_git pour éviter les collisions : aqua, aquamarine, azure, beige, bisque, black, blue, brown, chartreuse, chocolate, coral, cornsilk, crimson, cyan, fuchsia, gainsboro, gold, goldenrod, gray, green, honeydew, indigo, ivory, khaki, lavender, lime, linen, magenta, maroon, moccasin, navy, olive, orange, orchid, peru, pink, plum, purple, red, salmon, seashell, sienna, silver, snow, tan, teal, thistle, tomato, turquoise, violet, wheat, white, yellow.
Voici quelques informations sur la machine hébergeant le dépôt distant. Lorsque nous serons plus avancé·es dans le cours de sysadmin, toutes ces informations devraient vous être familières et compréhensibles.
la machine distante est un conteneur accessible via le nom de domaine yologit.netlib.re. Il possède sa propre adresse IPv6. Comme vous ne savez pas encore comment joindre une machine IPv6-only par SSH depuis un réseau IPv4-only, ce conteneur hérite de l'adresse IPv4 de la machine hôte qui l'héberge, grâce à une redirection de port. Ainsi, le port de connexion SSH ne sera pas le port 22 (défaut), mais 2271.
les fingerprints des clefs publiques du serveur SSH de ce conteneur sont :
RSA : SHA256:uwcsZ4oiL19jikWYFA2S6u3DhF/NUSnnHRP1wJjeBzk ECDSA : SHA256:bAQxBoag6nOvmmt657sMzP45ktbe/lTKnVsHSNAJnyE ED25519 : SHA256:0eoJohNR3VCQBP7OxHORYdQ8720cXobNJNTr32FocbA
l'user qui héberge les dépôts distants sur ce conteneur s'appelle gituser.
le shell de l'user gituser a été configuré pour n'accepter que des commandes git. En effet, le fichier /etc/passwd de la machine yologit.netlib.Re contient la ligne :
gituser:x:1000:1000:,,,:/home/gituser:/usr/bin/git-shellcomme vous n'avez pas encore manipulé de clefs SSH, l'authentification se fera exceptionnellement par mot de passe, celui-ci se trouve dans l'en-tête du salon mattermost sysadmin_git, il est n'est pas public.
Retournez dans votre répertoire de travail d'administration système (quittez git-test/) et clonez le dépôt que vous avez choisi :
$ git clone ssh://gituser@yologit.netlib.re:2271/~/<nom_du_depot_distant>Un message d'alerte s'affiche. Afin d'être sur·e que la connexion n'a pas été interceptée par une entité malveillante, vérifiez que le fingerprint du serveur SSH de la machine distante correspond bien à l'un des fingerprints cités plus haut (point 3).
Une fois que vous avez vérifié le fingerprint, vous pouvez taper yes, et git clonera le dépôt via SSH.
perso/. Créez-y un fichier dont le nom est votre prenom.nom et ajoutez-y des informations (non-compromettantes) sur vous (n'hésitez pas à baratiner, pensez que la confidentialité de ce dépôt est très faible).perso/<prenom.nom> et repoussez votre nouveau commit.pull des push et des merge.Le but de ce paragraphe est de jouer au jeu du cadavre exquis inventé par les surréalistes, mais avec git.
Désignez 5 joueu·ses et un·e maitre·sse du jeu ("release manager"). Dans tout le jeu, le ou la release manager est la seule qui peut modifier la branche main.
Dans le répertoire de travail de votre dépôt local partagé se trouve un répertoire nommé cadavre_exquis/. Dans ce répertoire se trouve un fichier nommé template.txt.
Le ou la release manager copie le template en un fichier jeu.1.txt, commite ce fichier dans la branche main et pousse cette branche sur le dépôt commun que tout·es les joueu·ses récupèrent.
Répartissez les 5 lignes à remplir parmis les joueu·ses (1. substantif, 2. adjectif, 3. verbe, ...).
Une fois que vous êtes d'accord sur la ligne que chaque joueu·se doit remplir, créez chacun·e une branche ayant pour nom votre prénom.
Chaque joueu·se modifie en secret le fichier jeu.1.txt en ajoutant au niveau du tiret qui correspond à sa ligne un ensemble de mots admissibles (par exemple un verbe pour la 3e ligne). Évitez les termes offensants ou discriminatoires.
Chaque joueu·se commite ses changements sur sa branche et pousse sa branche sur le dépôt commun.
Le ou la release manager récupère toutes les branches sur son dépôt local, les merge dans la branche main et pousse cette branche sur le dépôt commun. Comme les lignes modifiées sont différentes, il ne devrait pas y avoir de collision à gérer.
Tout le monde récupère la branche main du dépôt commun et découvre le résultat du cadavre exquis.
Observez qui a effectué les changements sur le fichier avec la commande :
$ git blame jeu.1.txtRecommencez une partie (en remplaçant jeu.1.txt par jeu.2.txt, etc) de sorte à ce que tout le monde ait pu jouer le rôle de release manager.
baston, commencez à y écrire un texte, commitez-le et poussez vos changements sur le dépôt distant.baston et repoussez votre nouveau commit.merge doit être résolu manuellement, décidez seul·e de la version à garder pour que le texte reste cohérent.pull des push et des merge en rapport avec le fichier baston.Si vous êtes arrivé·e à ce paragraphe dans les 3h, félicitations !