Guid de survie Git

Créer votre dépôt pour l'UE

Pour initier la création de votre dépôt Git:

1. Connectez vous au serveur gitlab de l'école https://gitlab.telecom-paris.fr
   • Authentifiez vous en utilisant vos identifiants école en cliquant sur SSO & Fédération d'identité Edugain
2. Demandez à appartenir au sous-groupe se204/2x2y
   • Dans le panneau latéral, cliquer sur Groups
   • Allez dans l'onglet Explore Groups
   • Cliquez sur le sous-groupe se204/2x2y
   • Demandez l'accès en cliquant sur Request Access

Vous recevrez un mail dès que votre dépôt sera créé. Cette étape est manuelle et nécessite l'intervention d'en enseignant.

Acceder à son dépôt

Une fois que votre dépôt a été créé, vous pouvez:

• visualiser l'état et le contenu de son dépôt dans un navigateur en suivant le lient suivant:

https://gitlab.telecom-paris.fr/se204/2x2y/prenom-nom

• cloner votre dépôt

git clone git@gitlab.enst.fr:se204/2x2y/prenom-nom.git DEPOT_SE204

Pour cela il faut d'abord renseigner sa clé ssh dans son compte gitlab (voir la suite).

Clé ssh et gitlab

Pour interagir (clone, push, pull) avec son dépôt Git, il est préférable d'utiliser une connexion ssh et d'uploader sa clé publique ssh sur l'interface web de gitlab.

• Pour ajouter une clé ssh, dans l'interface web de gitlab
• dans le panneau latéral, cliquer sur Profile Settings
• allez dans l'onglet SSH Keys

Coller le contenu de votre clé publique dans le champ Key donnez lui un nom dans le champ Title puis cliquez sur Add Key. Notez que vous pouvez avoir plusieurs clés publiques en même temps (par exemple pour votre ordinateur personnel et votre compte école).

Si vous n'avez pas de clé ssh il faut d'abord la générer, par exemple en suivant ce qui est indiqué dans la doc de gitlab (https://gitlab.telecom-paris.fr/help/user/ssh.md).

Mémento

Configuration globale

Pour configurer vos noms et mails, une seule fois par "machine" et depuis n'importe quel répertoire :

• git config --global user.name "Prénom Nom"
• git config --global user.email "prenom.nom@telecom-paris.fr"
• git config --global core.editor "votre éditeur favoris" #(nano, vi, emacs...)

Ces informations seront stockées dans le fichier ~/.gitconfig (que vous pouvez aussi éditer à la main si vous préférez).

Pour éviter d'avoir à taper en permanence votre clef privée : ssh-add

Le fichier .gitignore dans la racine du dépôt permet d'ignorer certains fichiers inutiles (les *.pyc par exemple ou les *.o, *.swp, *~, ...). C'est un fichier texte que vous pourrez (devrez) éditer pour le compléter.

Création de dépôt git

• Créer un dépôt git : git init
• Cloner un dépôt : git clone adresse_du_dépôt

L'adresse du dépôt à cloner peut être :

• une adresse distante. Par exemple pour les dépôts de SE203 sur le serveur Gitlab de l'école, c'est du genre : git@gitlab.enst.fr:SE203/2122/prenom-nom
• un chemin local. Exemple, pour cloner le dépôt local depot1 en un nouveau dépôt local depot2 : git clone depot1 depot2

Voir ce qui s'est passé

• Voir l'état actuel de l'index et de son répertoire de travail : git status. Git vous indique ce qui est modifié et pas encore dans l'index, ce qui est dans l'index et pas encore committé, ce qui n'est pas tracké. Pour chaque cas, il vous indique la commande à taper pour mettre un fichier dans l'index, l'en sortir, le committer, etc...
• Voir l'historique de la branche sur laquelle vous êtes : git log
• Idem avec une belle application graphique : gitk
• Voir l'historique de la branche origin/main (c'est une branche distante) : git log origin/main

Comparaisons de versions

• Comparer son répertoire de travail avec le dernier commit : git diff HEAD
• Comparer son répertoire de travail avec l'index : git diff
• Comparer l'index avec le dernier commit : git diff --cached
• Comparer deux commits entre eux : git diff ea678 9deadb (remplacer ea678 et 9deadb par les numéros des commits en question. On peut aussi passer un nom de branche)

Manipuler des fichiers

• Supprimer un fichier : git rm fichier
• Supprimer un répertoire : git rm -r repertoire
• Bouger un fichier ou un répertoire : git mv ancien_chemin nouveau_chemin

[Attention]{.underline} : ne pas oublier le git commit après !

Enregistrement de fichiers

• Prendre une photo de certains fichiers : git add fichiers. Cette commande place la "photo" dans l'index.
• Enregistrer le contenu de l'index dans un commit : git commit
• Prendre une photo de tous les fichiers déjà connus de git et créer un nouveau commit : git commit -a
• Annuler un git add de certains fichiers (remettre l'index à la version du dernier commit) :git reset -- fichiers
• Annuler des modifications locales sur certains fichiers et revenir à l'état de l'index : git checkout -- fichiers
• Annuler des modifications locales et de l'index sur certains fichiers et revenir au dernier commit : git checkout HEAD -- fichiers
• Pareil avec tous les fichiers : git reset --hard ou git checkout -f

Le commit est enregistré à la suite de celui où pointe HEAD. Puis HEAD ainsi que l'éventuelle branche vers lequel HEAD pointait sont déplacés vers le nouveau commit.

• Modifier un commit précédent : git commit --amend. [Attention]{.underline} : ne jamais le faire si on a déjà pushé !

Travailler avec un serveur distant

• Récupérer les évolutions des branches depuis un serveur distant : git fetch. Cette commande met à jour la copie locale des branches distante (origin/xxx) mais ne répercute pas ces modifications dans vos branches locales.
• Appliquer les changements d'une branche distante à la branche courante : git merge origin/xxx
• Faire ces deux manipulations d'un coup sur la branche actuelle : git pull (= git fetch + git merge)
• Envoyer les modifications de la branche locale A vers la branche distante B du serveur server : git push server A:B
• Si A et B portent le même nom, on peut l'abréger en git push server A
• Si A est la branche courante, on peut omettre son nom : git push server
• Si server est celui par défaut (origin, ou le seul serveur configuré), on peut omettre son nom : git push . [Attention]{.underline} : [JAMAIS]{style="color:#FF0000;"} de git push -f !!!
• Voir les serveurs distants : git remote -v
• Ajouter un serveur distant qu'on appelera gh : git remote add gh git@github.com:chemin_vers_depot.git

Naviguer dans l'historique

• récupérer les fichers d'un certain commit et mettre à jour l'espace de travail ainsi que l'index : git checkout nom_du_commit fichiers où nom_du_commit peut être le SHA d'un commit, un nom de tag ou un nom de branche
• revenir dans l'état un commit particulier en mettant à jour tout le répertoire de travail : git checkout nom_du_commit

Si nom_du_commit est un nom de branche, cela veut dire qu'on a changé de branche. Tout nouveau commit sera ajouté à la nouvelle branche :

Si nom_du_commit est un numéro de commit, on se retrouve en mode "detached HEAD" : sur une branche qui n'a pas de nom. Tout nouveau commit sera ajouté à cette branche. Il est fortement conseillé de nommer cette branche pour pouvoir la retrouver plus tard : git branch nom_de_la_nouvelle_branche ou git checkout -b nom_de_la_nouvelle_branche

[Notes]{.underline} :

• HEAD~ ou HEAD^  ou HEAD~1 : commit précédent HEAD (idem avec un nom de branche).
• HEAD~~ ou HEAD^^ ou HEAD~2 : avant-dernier commit avant HEAD (idem avec un nom de branche).
• HEAD~~~ ou HEAD^^^ ou HEAD~3 : avant-avant-dernier commit avant HEAD (idem avec un nom de branche).
• etc.

[Attention]{.underline} : ^ et ~ ne veulent pas dire la même chose. Si en remontant il y a eu un merge :

• ~ remonte la branche du premier parent,
• ^N représente le N^ème parent.

[Exemple]{.underline} : si on a un merge, HEAD~2 représente le grand père en suivant le premier parent, alors que HEAD^2 représente le deuxième parent. HEAD~~~ est équivalent à HEAD^^^ et HEAD~3, mais [pas]{.underline} à HEAD^3.

Les branches

[Rappel]{.underline} : dans git, une branche est juste un pointeur vers un commit particulier. Par abus de langage, on appelle parfois "branche" l'ensemble de ce commit et de ses ancètres.

• Créer une branche à l'endroit actuel (HEAD) : git branch nom_de_la branche
• Créer une branche sur un commit particulier : git branch nom_de_la branche numero_de_commit
• Basculer sur une branche en mettant à jour le répertoire de travail et l'index : git checkout nom_de_la branche

Tout nouveau commit est ajouté à la suite de ce vers quoi pointe HEAD, et HEAD ainsi que le nom de la branche actuelle sont déplacés pour pointer sur le nouveau commit.

• Rapatrier les changements d'une branche vers la branche actuelle : git merge nom_de_la_branche_à_intégrer
  • S'il n'y a pas de conflits, cela crée automatiquement un nouveau commit avec comme message de log par défaut "Merge"
  • S'il a des conflits, ils sont indiqués par git. On doit alors les résoudre manuellement, en recherchant les passages délimités par des chervons et des signes "égal", faire les modifications qui s'imposent, supprimer les marqueurs (chevrons / égal), et committer le résultat.

Cette page est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d'Utilisation Commerciale - Partage à l'Identique 3.0 États-Unis. Elle utilise des images issues de http://marklodato.github.io/visual-git-guide/index-fr.html.

Références

• L'aide intégrée à git :man git commande (exemple : man git commit) ou git commande --help (exemple : git commit --help)
• Les commandes de git de façon visuelle : http://marklodato.github.io/visual-git-guide/index-fr.html
• Une explication complète de git, un peu similaire au précédent lien : https://docs.google.com/presentation/d/1IQCRPHEIX-qKo7QFxsD3V62yhyGA9_5YsYXFOiBpgkk
• Un bon tutorial visuel et interactif sur git et les branches : http://pcottle.github.io/learnGitBranching/
• Très bon livre à propos de git (lisible en ligne) : Pro Git
• Ah mince, j'ai fait un truc qu'il fallait pas, comment je me sors de ça ? http://ohshitgit.com/
• Quand on travaille en groupe, il faut se mettre d'accord sur la façon de gérer les branches. On appelle ça des "workflows". Il en existe plusieurs selon la taille du groupe, son organisation etc. Un bon site qui explique les différents workflows possibles : https://www.atlassian.com/git/tutorials/comparing-workflows