Git : guide d'utilisation de base
Préambule
Un système de gestion de version (« version control system » en anglais) est un programme permettant à plusieurs personnes de travailler en commun sur un projet. Il permet surtout de maintenir un historique complet des changements dans le projet ainsi que différentes versions vers lesquelles il est possible de revenir. Ainsi, il est utile d'y avoir recours même si l'on travaille seul.e.
Pour pouvoir travailler avec git, il faut que l'outil git soit installé sur la machine utilisée. C'est le cas des VMs de L'EPFL (en connexion à distance) ou sur les machines des salles de TP. Sinon, voir : https://git-scm.com/book/en/v2/Getting-Started-Installing-Git.
Nous supposons dans ce qui suit qu'Alice et Bob travaillent sur un projet commun et qu'Alice possède quelque part chez elle un répertoire, par exemple [chemin_vers_le_projet]/MP2-2025/, contenant déjà du code du projet.
SETUP INITIAL (à ne faire qu'une fois et uniquement par Alice)
Voici les manipulations que doit faire Alice (seulement elle et une seule fois) pour initialiser le projet avec git:
- Créer un dépôt sur https://gitlab.epfl.ch (identification Tequila avec
les identifiants Gaspar) en cliquant sur le + en haut à gauche :
et choisir l'option New project/repository.
- Choisir l'option Create blank project.
- Choisir un nom de projet, par exemple, cs107-2025-alice-et-bob, et laisser le niveau de visibilité à "private".
- Décochez l'option permettant de créer automatiquement un fichier README:
- Cliquer sur le bouton Create project en bas de page ceci crée un dépôt commun où placer le contenu à partager.
- La vidéo de mise en place recommande a priori https car elle ne nécessite que la création d'un mot de passe.
- Cependant, ce mot de passe est demandé à chaque interaction ce qui est plus pénible.
- L'utilisation de ssh vous affranchit de cette contrainte, mais nécessite des mises en place supplémentaires un peu plus complexes et qui sont décrite plus bas.
Dans les messages qui apparaîssent en haut de la fenêtre : "You won't be able to pull or push project code via HTTPS until you set a password on your account" Cliquer sur "set a password" et introduire un mot de passe de votre choix si vous souhaitez travailler avec https.
Alice doit ensuite importer le contenu de [chemin_vers_le_projet]/MP2-2025/ dans ce dépôt. Pour cela, elle doit taper les commandes suivantes dans une invite de commande/terminal :
cd [chemin_vers_le_projet]/MP2-2025/
git init --initial-branch=master
echo ".idea" >> .gitignore
git add .
git config --global user.email "‹your mail>"
git config --global user.name "‹your name>"
git commit -m "Initial commit"
git remote add origin https://gitlab.epfl.ch/alice/cs107-2025-alice-et-bob.git
git push -u origin master
Taper ces commandes dans un terminal ou une invite de commande en remplaçant https://...cs107i-2025-bob-et-alice.git par l'adresse exacte associée à votre dépôt, et ne pas oublier le point à la fin de git add .
Si vous avez choisi https, la dernière commande exigera de vous de taper le mot de passe que vous avez précédemment créé (utilisez votre user name gaspar).
Pour vérifier que tout est en ordre, Alice peut taper dans le terminal :
git status .
et devrait obtenir :
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean
Le projet est alors configuré avec git.
Droits d'accès
Alice doit finalement donner le droit de contribution à Bob.
Dans la page https://gitlab.epfl.ch/.../cs107-2025-alice-et-bob/, sur le bandeau de gauche, cliquer sur Settings > General > Manage > members, puis:
- Cliquer sur le bouton à droite Invite members.
- Introduire l'adresse email epfl de Bob et lui attribuer le rôle Maintainer.
- Puis cliquer sur le bouton Invite.
RÉCUPÉRATION DU PROJET (par Bob)
Le partenaire de travail d'Alice peut maintenant récupérer une copie du projet git chez lui. Pour cela, il lui suffit de se placer dans un répertoire choisi sur sa machine et récupérer le contenu du dépôt en tapant les commandes suivantes dans un terminal ou une invite de commande : si vous utilisez https:
cd chemin_vers_le_repertoire_choisi
git clone https://gitlab.epfl.ch/.../cs107-2025-alice-et-bob.git
ou, si vous utilisez ssh:
cd chemin_vers_le_repertoire_choisi
git clone gitlab@gitlab.epfl.ch/.../cs107-2025-alice-et-bob.git
(ne pas oublier de remplacer par l'adresse exacte chez vous)
TRAVAIL ROUTINIER (Pour Bob et Alice)
À faire SYSTÉMATIQUEMENT à chaque fois que vous décidez de recommencer à travailler sur le projet :
git pull
qui récupère les modifications faites par l'autre.
Supposons que vous ayez ensuite modifié un fichier existant Main.java et que vous avez terminé
et relu vos modifications:
git pull
git add Main.java
git commit -m "commentaire explicatif sur la modification\
(par exemple : ajouté un test sur la méthode getXthBit)" Main.java
(on peut omettre le nom du fichier si on a modifié plusieurs fichiers pour un patch)
puis
git push
qui permet de pousser/publier les modifications sur le dépôt commun.
L'autre personne peut à ce moment récupérer les modifications au moyen d'un git pull)
Si on veut supprimer un fichier
git rm nom_de fichier
ou si on veut déplacer un fichier ou un dossier:
git mv nom_de_fichier_ou_dossier nouveau_nom_ou_repertoire_destination.
Annulation des modifications courantes
Si l'on a fait des modifications dans un fichier que l'on n'a pas encore ajouté au moyen de la commande git add, il est possible de les annuler avec :
git checkout nomDuFichier
ou
git checkout
qui annule toutes les modifications (non ajoutées) sur tous les fichiers.
Conflits
Un souci récurrent avec git est l'occurrence de conflits dont certains sont très pénibles à résoudre. Vous pouvez éviter ces derniers en:- Adhérant strictement au protocole indiqué ci-dessus pour le travail routinier
- En vous concertant avant de travailler : git ne vous dispense pas de communiquer sur qui prend la main sur quelle partie du projet et à quel moment
- Finalement, en ne partageant pas ce qui est spécifique à chacun (fichier .class, fichiers de configuration, etc.).
Le dernier point est particulièrement important. Afin d'éviter des conflits sur les fichiers exécutables ou issus de la compilation, il est préférable de les exclure de git. Pour ce faire, il suffit d'ajouter au projet, un fichier .gitignore qui indique tout ce qu'il faut exclure.
Bonnes pratiques
Pour pouvoir tirer le meilleur parti de Git et du travail collaboratif, il est recommandé d'adhérer à la discipline suivante:
- Ne pousser que du code qui compile
- Ne pas ajouter les fichiers .class ou les des fichiers de configurations spécifiques à sa machine (un bon fichier .gitignore devrait faire l'affaire).
- Faire des publications (commit) atomiques: c'est à dire ne pas ajouter un ensemble important de modifications d'un coup avec un seul gros (commit), mais plutôt publier, comme un tout, l'ensemble des modifications liées à une petite correction/ajout donné. Par exemple, si deux fonctionnalités ont été ajoutées au code, on les publiera par le biais de deux commit séparés, plutôt que comme un seul gros commit incluant les deux.
Commandes utiles
Voici deux commandes très utiles pour savoir où vous en êtes :
git status
(ou git status . pour connaitre le status du répertoire courant)
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
(use "git add ‹file>..." to include in what will be committed)
crypto-stegano/MyNewFile.java
nothing added to commit but untracked files present (use "git add" to track)
veut dire que :
- Ma « branche » de référence dans le dépot local s'appelle « master » ; vous pouvez l'ignorer, nous n'utiliserons pas les branches dont nous n'allons pas du tout parler
- qu'elle est actuellement synchronisée ('up to-date') avec le dépot commun qui s'appelle ici `origin/master` (ce nom ne changera pas) ;
- mais qu'il y a un nouveau fichier (« untracked file ») : fichier existant chez moi, mais non recensé dans git;
- et ce qu'il faut faire si je veux l'ajouter : « use git add ... » Si ce fichier est pertinent, il faut l'ajouter comme indiqué plus haut. Sinon il faut ignorer simplement le message ou détruire le fichier sans passer par git rm.
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD ‹file>..." to unstage)
new file: crypto-stegano/myNewFile.java
une fois git commit fait (après avoir fait un `pull` comme conseillé plus haut) ,
git status donne:
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits)
nothing to commit, working directory clean
(et l'on termine par un push).
Dans IntelliJ, le status est donné par des couleurs (rouge pour fichier non recensé, bleu pour fichier
recensé et localement modifié, etc.), donc il n'y a pas directement besoin de cette commande.
L'autre commande utile est :
git log (ou git log .)
elle permet de voir tous les `commit` effectués et leur message. C'est-à-dire tout l'historique des modifications.
Un synopsis des commandes usuelles est disponible
ici (il s'agit d'une documentation de
l'hébergeur GitHub, mais les commandes git sont partout les mêmes).
Accès pas ssh
L'accès aux données de votre dépôt par https est un peu pénible, car il exige d'entrer un mot de passe à chaque push. Pour simplifier cela, il faut ajouter à GitLab une clé ssh publique qu'il faut générer en suivant ces instructions:
- Ouvrir un Terminal (Pour Mac/Linux) ou PowerShell (pour windows) ou le terminal intégér à IntelliJ
- Créer une clé SSH
Les commandes suivantes marchent sur tous les OS (window/mac/linux):
ssh-keygen
Puis appuyer sur la touche Enter 4 fois. Ensuite:cat ~/.ssh/*.pub
Copier le résultat de la commande. Par example:ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKJV4a55+EozJx8dAlSEsxac6M4sV8jVuW7cKQmDbdHf toto@linux
Ensuite, aller à l'addresse https://gitlab.epfl.ch/-/user_settings/ssh_keys. Cliquer sur Add new key, puis coller le contenu, et enfin cliquer sur Add key.