ELCa11 - Tuto : Git et GitLab¶

Objectifs¶

Maîtriser les commandes Git de base : status, add, commit, push, pull, branch, merge.
Créer et gérer un projet sur la plateforme GitLab de Centrale Lyon.
Travailler à plusieurs sur le même projet (cas du binôme).
Intégrer Git dans Qt Creator.

Prérequis¶

Une certaine aisance en ligne de commande (un Terminal).
Aucun prérequis Git : on part de zéro.

1 — Pourquoi Git ?¶

Git est un système de gestion de versions. Il garde la trace de toutes les modifications apportées à un ensemble de fichiers, ce qui permet :

de revenir à une version antérieure à tout moment ;
de travailler à plusieurs sur le même projet sans se marcher dessus ;
de tester de nouvelles idées sur des branches sans toucher au code principal.

Il est utilisé universellement pour les codes sources (Python, C++, Java…), mais aussi pour les rapports LaTeX, les notes Markdown, etc.

GitLab (gitlab.ec-lyon.fr) est une plateforme en ligne basée sur Git qui ajoute des outils collaboratifs : gestion des membres d’un projet, merge requests, suivi des tickets, etc. C’est à la fois un hébergeur et un réseau social pour développeurs. Centrale Lyon propose sa propre instance, qu’on utilisera pour le projet de ce cours. Des plateformes équivalentes : GitHub, Bitbucket.

Apprenez la ligne de commande. Des interfaces graphiques (GitHub Desktop, Sourcetree, GitKraken) existent, mais elles cachent les concepts. Commencez par la ligne de commande pour bien comprendre ce qui se passe. Vous pourrez basculer plus tard si vous voulez.

Une fiche aide-mémoire utile : github-git-cheat-sheet.pdf.

2 — Installation et configuration¶

Vérifier la présence de Git¶

Ouvrir un Terminal (sur Windows : Windows PowerShell, déjà installé) et taper :

git --version

Le retour ressemble à git version 2.45.2. Si la commande n’est pas reconnue :

Windows : télécharger l’installateur sur git-scm.com/download/win.
macOS : Git est installé avec les Xcode Command Line Tools (cf. tuto précédent).
Linux : sudo apt install git (Debian/Ubuntu) ou équivalent selon la distribution.

Configuration globale (à faire une seule fois)¶

git config --global user.name  "Votre nom"
git config --global user.email "votre.mail@ec-lyon.fr"
git config --global color.ui   auto
git config --global init.defaultBranch main

Vérifier avec :

git config --list

3 — Premier dépôt sur GitLab¶

Se rendre sur gitlab.ec-lyon.fr et se connecter avec les identifiants Centrale Lyon.
Cliquer sur New project > Create blank project.
Renseigner :
- le nom du projet (par ex. tuto-git) ;
- la visibilité : Private (recommandé pour un projet personnel ou en binôme) ou Public ;
- décocher Initialize repository with a README — on va le créer localement plus loin, ce qui évite les soucis de fusion lors du premier push.
Valider avec Create project.

L’interface affiche maintenant les instructions pour pousser un dépôt local existant : git remote add origin …, etc. On va les utiliser dans la section suivante.

4 — Cloner et travailler en local¶

On va créer un dépôt local puis le synchroniser avec GitLab.

Cas A — Le dépôt GitLab est vide (ce qu’on vient de faire)¶

Dans un Terminal, à l’endroit où vous voulez créer le projet :

mkdir tuto-git
cd tuto-git
git init                              # initialise un dépôt Git local

Créer un fichier README.md (avec votre éditeur), avec par exemple :

# Tuto Git

Mon premier projet Git.

Puis :

git status                            # voir l'état du dépôt
git add README.md                     # ajouter le fichier à l'index (préparation)
git status                            # README.md apparaît "à valider"
git commit -m "Commit initial"        # créer le commit
git remote add origin https://gitlab.ec-lyon.fr/<utilisateur>/tuto-git.git
git push -u origin main               # envoyer le commit sur GitLab

Le -u de git push -u origin main mémorise origin/main comme branche par défaut. Les git push et git pull suivants n’auront pas besoin de préciser la branche.

Cas B — Le dépôt GitLab contient déjà un readme¶

git clone https://gitlab.ec-lyon.fr/<utilisateur>/tuto-git.git
cd tuto-git

L’URL HTTPS se trouve sur la page GitLab du projet, en cliquant sur le bouton Clone > Clone with HTTPS.

HTTPS vs SSH : on utilise HTTPS dans ce tuto, plus simple à mettre en route. Au premier git push, GitLab demandera votre mot de passe ou un token d’accès personnel (à créer depuis votre profil GitLab). SSH évite cette authentification répétée mais nécessite de générer une clé. Vous pourrez basculer en SSH plus tard si vous le souhaitez.

Cycle de travail standard¶

Le cycle de travail Git se résume à 4 commandes :

git status                  # 1. voir l'état du dépôt
git add <fichier>           # 2. préparer les modifications
git commit -m "message"     # 3. enregistrer en local
git push                    # 4. publier sur GitLab

Faites un essai : modifier README.md, puis enchaîner ces commandes. Aller voir sur GitLab : la page se met à jour.

Important : git status est votre amie. À utiliser tout le temps pour comprendre où vous en êtes.

Voir l’historique : `git log`¶

git log
git log --oneline           # version compacte

Chaque commit a un identifiant unique (hash SHA-1 du type 6d0cec16…). On peut revenir à n’importe quelle version antérieure à partir de cet identifiant, mais les commandes (git revert, git reset) sont délicates — à voir une fois les bases solides.

5 — Les branches¶

Une branche est une ligne de développement parallèle. Vous travaillez par défaut sur main (la branche principale). On crée une branche pour tester quelque chose, et on fusionne ensuite si on est satisfait.

En local¶

git branch                           # liste les branches
git branch test-fonction             # crée une branche
git checkout test-fonction           # bascule dessus
# (équivalent en une commande : git checkout -b test-fonction)

# … on modifie des fichiers, on commite …

git checkout main                    # revient à main
# les modifs ne sont plus visibles ici, elles sont sur test-fonction

git merge test-fonction              # fusionne test-fonction dans main
git branch -d test-fonction          # supprime la branche fusionnée (locale)

Avant de changer de branche, toujours commit ou stash vos modifications en cours, sinon Git refuse le changement (ou perdrait votre travail).

Sur GitLab : Merge Request¶

Sur GitLab, l’usage est de :

créer une branche (git checkout -b feature-x) ;
la pousser : git push -u origin feature-x ;
ouvrir une Merge Request depuis l’interface web (menu Code > Merge requests > New merge request) ;
faire relire son code par un collègue ;
cliquer sur Approve puis Merge.

Avantage par rapport à un simple git merge local : trace écrite de la décision, possibilité de discussion, vérification automatisée (tests, lint).

6 — Travailler à plusieurs¶

Inviter un binôme¶

Le propriétaire du projet :

va sur le projet GitLab, menu Project information > Members (ou Manage > Members) ;
ajoute son binôme avec le rôle Developer (peut commiter et pousser) ou Reporter (lecture seule).

Le binôme reçoit un mail et doit accepter l’invitation.

Le binôme clone le projet¶

git clone https://gitlab.ec-lyon.fr/<utilisateur>/tuto-git.git
cd tuto-git

Conflit type — pull avant push¶

Mise en situation :

l’utilisateur A modifie le fichier a.txt, fait commit + push → GitLab à jour.
l’utilisateur B (qui n’a pas encore récupéré le travail de A) modifie le fichier b.txt, fait commit puis tente un push.

Git refuse : « remote contains work that you do not have locally ». Marche à suivre :

git pull                  # récupère et fusionne le travail de A
git push                  # publie maintenant

Si A et B modifient le même fichier au même endroit, Git ne saura pas fusionner automatiquement → conflit de fusion. Git insère des marqueurs dans le fichier conflictuel (<<<<<<<, =======, >>>>>>>). Il faut :

éditer le fichier pour résoudre le conflit (garder l’une, l’autre, ou un mélange) ;
enlever les marqueurs ;
git add <fichier> ;
git commit ;
git push.

Bonne pratique : faire git pull régulièrement, idéalement avant chaque session de travail, et toujours avant git push.

7 — Intégrer Git dans Qt Creator¶

L’objectif : versionner un projet Qt avec Git, depuis Qt Creator.

Préparer le projet Qt¶

Créer un projet Qt (Qt Quick, Plain C++, etc.) avec Qt Creator.
À l’écran Project Management (dernière étape du wizard), choisir Git comme système de contrôle de version. Qt Creator initialise un dépôt local et fait un premier commit.
Créer à la racine du projet un fichier nommé exactement .gitignore (avec le point initial). Y coller le contenu du fichier officiel Qt.gitignore — il liste tous les fichiers temporaires de Qt à ne pas versionner (.pro.user, build directories, etc.).

Commiter ce .gitignore :

git add .gitignore
git commit -m "Ajout du .gitignore Qt"

Lier le dépôt local à GitLab¶

Sur GitLab, créer un nouveau projet vide (sans readme), par exemple tutoGitQT.

Dans le Terminal, depuis la racine du projet Qt :

git remote add origin https://gitlab.ec-lyon.fr/<utilisateur>/tutoGitQT.git
git push -u origin main

Rafraîchir la page GitLab : le code y apparaît.

Une fois le projet lié à GitLab, Qt Creator propose un menu Outils > Git avec des sous-menus :

Dépôt local > Commit : commite les changements sélectionnés (équivalent de git add + git commit).
Dépôt local > Log : affiche l’historique.
Dépôt distant > Pull : récupère les changements de GitLab.
Dépôt distant > Push : envoie les commits locaux à GitLab.

Un commit Qt Creator ne sera soumis que si vous avez renseigné un message de commit. Soyez explicite : "Ajout de la classe Joueur", "Fix : bug d'affichage sur l'écran de fin", etc. Ne pas mettre "update" ou "misc" — sans valeur.

Bonne pratique d’un commit local¶

Un commit local doit compiler. Inutile d’attendre la fin d’une fonction complète : commiter par petites étapes cohérentes (« ajout de la signature de la méthode », « implémentation du calcul »).
Fréquence : toutes les ~30 min à 1 h de travail, ou à chaque petit jalon.
Le git push (envoi sur GitLab) ne se fait que sur une version stable : compile, tests passent, fonctionnalité finalisée.

Aide-mémoire — commandes Git essentielles¶

Commande	Usage
`git status`	État du dépôt (fichiers modifiés, indexés, à commiter)
`git add <fichier>`	Ajoute un fichier à l’index (préparation du commit)
`git add -A`	Ajoute tous les changements (créés, modifiés, supprimés)
`git commit -m "message"`	Crée un commit avec un message explicatif
`git log`	Historique des commits
`git log --oneline`	Historique compact, un commit par ligne
`git push`	Envoie les commits locaux sur GitLab
`git pull`	Récupère les commits du dépôt distant
`git branch`	Liste les branches
`git branch <nom>`	Crée une branche
`git checkout <branche>`	Bascule sur une branche existante
`git checkout -b <branche>`	Crée et bascule en une commande
`git merge <branche>`	Fusionne `<branche>` dans la branche courante
`git branch -d <branche>`	Supprime une branche fusionnée
`git clone <url>`	Clone un dépôt distant
`git remote -v`	Liste les dépôts distants connus
`git diff`	Affiche les modifications non encore indexées
`git stash`	Met de côté les modifications en cours (pour changer de branche)
`git stash pop`	Récupère les modifications mises de côté