Initiation à Git

Git est un gestionnaire de versions. Il permet de sauvegarder différentes versions d'un code. Git est beaucoup plus puissant que ce que l'on va voir là. Commençons par simple.

⌛ Git permet d'avoir des branches pour gérer plusieurs versions d'un logiciel en parallèle, par exemple pour ajouter des nouvelles fonctionnalités. On verra ça plus tard.

Pourquoi ?

Eviter un enfer de fichiers

On peut éviter de se mélanger les pinceaux 🖌🖌🖌 dans les versions de fichier :

🖹 programme.c
🖹 programme (v2).c
🖹 programme (v3).c
🖹 programme (v3 essai avec DFS).c
🖹 programme (v3 essai avec BFS).c

A plusieurs, on éviter de s'envoyer des mails et de se tromper dans la version du fichier, ou de modifier à la main des parties d'un fichier. On veut éviter de devoir manuellement intégrer des modifications de différentes personnes.

🖹 programme.c
🖹 programme (v2).c
🖹 programme (v3 par Patrick).c
🖹 programme (v3 par Julia).c  
🖹 dijkstra.c
🖹 dijkstra (v2 par Julia).c
🖹 dijkstra (v3 correction mineure par Jenny).c
🖹 dijkstra (v3 par Julia).c
🖹 dijkstra (v3 par Julia) Copie de sécurité.c

Travailler de manière isolé

Vous travaillez à plusieurs, mais tu es en train d'ajouter une fonctionalité, et tu ne veux pas perturber le travail des autres.

Pour cela, git offre un mécanisme de branches. ⌛ On verra ces notions un autre jour !

Aspects sociaux

• Le projet peut être rendu visible pour d'autres personnes qui peuvent rejoindre le projet.
• On peut reporter des bugs et des propositions de nouvelles idées sur la plate-forme commune sans devoir s'envoyer des mails.

Aspects historiques

On peut faire de l'archéologie logicielle.

• Quelle était la raison de cette ligne de code ? Qui l'a écrit ? Quand ?
• Sur quelle partie du logiciel a travaillé Patrick ?
• Depuis quand les tests unitaires sur dijkstra ne fonctionne plus ?

Pourquoi un outil décentralisé ?

L'outil git est décentralisé. C'est bien car on peut travailler dans le train, quand il n'y a pas de réseau. On peut faire des commits (c'est-à-dire estampiller des modifications) sans connexion Internet.

Serveur distant

Ici, on utilisera https://gitlab.aliens-lyon.fr/. C'est là-bas que sera vos dépôts (appelé projets dans gitlab). Un dépôt est un ensemble de code source avec tout son historique de versions.

Créer une clé

Le plus simple pour se connecter à un dépôt (et éviter de taper un mot de passe toutes les 5 secondes et demi) est d'utiliser une clé SSH. Pour en créer, tapez cette commande :

ssh-keygen -t rsa -b 4096

Elle génère deux fichiers :

• une clef privée id_rsa (ne jamais donner/montrer ce fichier !)
• une clef publique id_rsa.pub

Dans github, gitlab, copier la clef publique (attention, pas la clef privée !). Dans gitlab Aliens c'est ici : https://gitlab.aliens-lyon.fr/-/user_settings/ssh_keys.

Créer un dépôt

Depuis https://gitlab.aliens-lyon.fr/projects/new, vous pouvez créer un dépôt.

Récupérer le contenu sur votre ordinateur

La récupération d'un dépôt distant sur votre ordi s'appelle clone. Dans la page web de votre projet (i.e. dépôt), copier l'URL :

Si vous avez une clef SSH, votre vie est plus simple : pas besoin de taper un mot de passe à chaque fois. Avec HTTPS, il faudra taper un mot de passe à chaque commande.

Sur votre ordinateur dans le dossier de votre choix, taper :

git clone [url]

Exemple :

git clone git@github.com:tableaunoir/tableaunoir.git

Créer un dépôt local

On peut aussi créer un dépôt entièrement en local. Pour créer un dépôt vide depuis rien du tout et connecté à rien du tout sur Internet :

git init <nomduprojet>

Exemple :

git init superlogiciel

Mon premier commit

Un commit est une estampille, des données "tamponnées". Souvent ça correspond à une étape dans la création d'un logiciel :

• génération d'un labyrinthe
• déplacement de la balle implémentée
• correction du bug de déplacement du vaisseau

Les fichiers d'un dossier ne sont pas tous versionnés, i.e. incorporés à un commit ! Par exemple, il est hors de question de versionner des fichiers temporaires ou des fichiers exécutables :

🖹 infos.log
🖹 fichiertemporaire.aux
🖹 monprogramme.exe

Au contraire, il faut versionner les fichiers sources par exemple :

🖹 balle.c
🖹 vaisseau.h
🖹 vaisseau.c

Pour dire que des fichiers doivent être maintenus et versionné au prochain commit, on écrit :

git add <fichier>

Exemple :

git add *.tex
git add dijkstra.c

Pour commiter (estampiller) les fichiers explictement ajoutés :

git commit -m "message"

Pour commiter les fichiers modifiés qui ont déjà été versionné un jour :

git commit -am "message"

Définitions.

• "untracked" signifie que les fichiers ne sont pas versionnés du tout.
• "staging area/tracked/index" parle des fichiers qui vont être versionnés quand on fait un commit
• "not staged" parle des fichiers qui sont a priori versionnés mais dont on a pas explicitement dit qu'ils allaient être versionnés au prochain commit

TODO cf. image de https://www.nicelydev.com/git/commit-am

Suppression et renommage de fichiers

Pour renommer un fichier :

git mv [nom-fichier-courant] [nouveau-nom]

Pour supprimer un fichier :

git rm [fichier]

Pour supprimer un fichier du dépôt mais pas du système de fichier :

git rm --cached [fichier]

Gérer le serveur distant

Pour télécharger les données du serveur vers mon ordinateur :

git pull

Pour poster nos modifications sur le serveur :

git push

Obtenir des informations sur le dépôt

Lister les nouveaux fichiers et à commiter :

  git status

Idée générale

Commandes principales

Quiz

• Quelle est la différence entre upstream et origin ?
• Quelles est la différence entre workspace, index et local repository ?
• A-t-on besoin d'une connexion Internet pour faire un git commit ?