Imaginons un dossier normal avec des fichiers. On ajuste un script un peu — puis encore — puis encore. Une semaine plus tard, c’est déjà difficile de se rappeler ce qui a changé exactement et pourquoi ça a “soudainement” cessé de fonctionner. Le réflexe le plus courant, c’est de faire des copies : script_v2.sh, script_final.sh, script_final_final.sh, et ensuite apparaît script_final_ok_please.sh. C’est une réaction humaine tout à fait normale — beaucoup de gens l’ont déjà fait. Mais c’est justement là que Git devient vraiment utile : il enlève le chaos des copies et donne un historique clair des changements.
Git, c’est un système de version control. Il transforme une suite de petites modifications un peu “au hasard” en une histoire structurée : chaque changement important est enregistré comme une étape, avec une courte explication. À tout moment, il est possible de voir ce qui a été modifié, de revenir à une version précédente, ou de comparer deux versions. Git n’est pas une “magie de programmeur” : c’est un outil pratique qui évite de dépendre de la mémoire… et des copies de fichiers faites à la main.
Dans ce tutoriel, on fait un tour d’horizon de Git : installation sur Linux (avec Debian comme exemple), connexion d’un repo GitLab sur un ordinateur ou un serveur, et les scénarios de base pour travailler avec Git au quotidien.
On peut prendre un café ou un thé — et on commence.
Notions de base Git
Pour travailler avec Git, il suffit de connaître un petit “vocabulaire” de base.
Repository (repo) — c’est le dossier du projet avec l’historique des changements géré par Git. Un repo se crée avec git init dans un dossier existant, ou apparaît automatiquement lors d’un clonage (git clone) depuis GitLab/GitHub.
Commit — c’est une étape logique enregistrée. Pas juste “j’ai changé quelque chose”, mais plutôt “voici ce qui a été fait, et pourquoi”. Une suite de commits, c’est comme un journal de bord clair et précis.
Branch — c’est une ligne de travail parallèle. Par exemple, pour ajouter une nouvelle fonction sans casser la version principale : on travaille dans une branche, puis quand tout est prêt, on merge vers la branche principale.
Remote — c’est le serveur distant avec lequel le repo se synchronise. En local, le travail reste rapide et simple; le remote sert de “source de vérité” et de backup (utile si un PC/serveur tombe en panne). C’est aussi ce qui rend le travail en équipe possible, via des pull/merge requests.
En pratique, comme remote on utilise très souvent GitLab ou GitHub.
GitHub — c’est la grande place publique de l’open-source et des communautés : on trouve facilement des projets, on contribue, on montre un portfolio. À noter : GitHub appartient à Microsoft, donc l’approche est très orientée écosystème et intégrations cloud; parfois ça se ressent comme une grosse plateforme “corporate”, avec ses avantages et ses limites.
GitLab est souvent choisi quand on veut du “tout-en-un” et moins de services à gérer : repo, CI/CD, registry et plusieurs outils DevOps sous le même toit. GitLab est aussi très solide en self-hosted : on peut utiliser gitlab.com, ou installer GitLab Community Edition (CE) sur son propre serveur (open-source) et garder ses repos privés sous contrôle : accès, règles, backups, politiques de sécurité. Au quotidien, gitlab.com est généralement très confortable et offre assez de fonctionnalités et d’espace pour la majorité des projets.
Dans ce tutoriel, l’exemple sera sur Debian, avec un repo GitLab en SSH :
[email protected]:oleks.ca/bash.git
La suite est très pratique : préparation de Debian, configuration de l’accès (repo privé inclus), clonage, puis les commandes Git les plus utilisées et les situations typiques de synchro entre la machine locale et GitLab.
Préparation de Debian
Installer Git et vérifier l’installation
Se connecter au serveur en SSH, puis installer Git :
sudo apt update sudo apt install -y git
Après l’installation, vérifier que Git est bien disponible :
git --version
Configurer le nom et l’email (signature des commits)
Git enregistre dans l’historique des commits l’auteur (nom + email). Cela permet de voir clairement, dans git log et dans GitLab, qui a fait chaque changement. Cette configuration se fait une seule fois et s’applique à tous les repos sur cet ordinateur. Il suffit de remplacer le nom et l’email par les valeurs appropriées.
git config --global user.name "Oleks" git config --global user.email "[email protected]"
Vérification :
git config --global --list
Créer un dossier de travail
Pour garder tous les repos au même endroit et éviter de les éparpiller dans le dossier personnel, il est pratique d’utiliser un répertoire dédié (ici : ~/repos).
mkdir -p ~/repos cd ~/repos
Dans GitLab et GitHub, il est possible de créer des repos publics et privés. Un repo public peut être consulté et cloné par tout le monde, mais seuls les utilisateurs qui ont les droits peuvent y pousser des changements (push). Un repo privé, lui, est accessible uniquement aux utilisateurs ajoutés au projet (Project members) ou à un groupe qui a déjà l’accès.
Dans ce cas-ci, le repo bash est public et son propriétaire a tous les droits. Comme il est public, n’importe qui peut le cloner sans restriction. Par contre, pour faire un push (et aussi pour accéder à un repo privé), GitLab doit pouvoir identifier qui se connecte depuis cet ordinateur. Une des méthodes les plus simples et les plus utilisées est l’authentification par clé SSH (l’alternative serait HTTPS avec un Personal Access Token, mais c’est un autre scénario).
Les clés SSH sont expliquées plus en détail ici : Génération et Utilisation des Clés
Ci-dessous, la version courte et pratique.
Si ~/.ssh n’existe pas, créer le dossier :
mkdir -p ~/.ssh chmod 700 ~/.ssh
Générer une clé ed25519 :
ssh-keygen -t ed25519 -C "debian-gitlab" -f ~/.ssh/id_ed25519
Pendant la création, une passphrase est demandée : il est possible d’en définir une (recommandé), ou simplement d’appuyer sur Entrée.
Démarrer ssh-agent et ajouter la clé :
eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_ed25519
Copier la clé publique
cat ~/.ssh/id_ed25519.pub
Copier la ligne complète : elle commence par ssh-ed25519 et va jusqu’à la fin (y compris le commentaire/nom, par exemple debian-gitlab).
Ajouter la clé dans GitLab (au niveau du compte)
Dans GitLab :
1. Cliquer sur l’avatar (en haut à droite) → Edit profile / Preferences
2. Dans le menu de gauche, ouvrir SSH Keys (comme sur le screenshot)
3. Dans la section Add an SSH key, remplir :
– Key — coller la ligne de clé publique (grand champ)
– Title — nom de la clé (ex. debian-home ou debian-gitlab). Souvent rempli automatiquement, modifiable au besoin
– Usage type — laisser Authentication & Signing
– Expiration date — optionnel (recommandé) : choisir une date après laquelle la clé devient invalide
4. Cliquer sur Add key
Après l’ajout, la clé doit apparaître dans la liste Your SSH keys.
Vérifier la connexion SSH
ssh -T [email protected]
Résultat attendu : un message confirmant que l’authentification a réussi. La première fois, le système peut demander de confirmer le fingerprint (clé hôte) de GitLab.
Ajouter la clé SSH dans GitHub (au niveau du compte)
Dans GitHub :
1. Cliquer sur l’avatar (en haut à droite) → Settings
2. Dans le menu de gauche, ouvrir SSH and GPG keys
3. Cliquer sur New SSH key
4. Remplir :
– Title — nom de la clé (ex. debian-home ou debian-github)
– Key type — laisser Authentication Key
– Key — coller la clé publique (la ligne ssh-ed25519 ...)
5. Cliquer sur Add SSH key (GitHub peut demander une confirmation par mot de passe ou 2FA)
Cloner le dépôt (via SSH)
Clonage
Dans le dossier ~/repos :
cd ~/repos git clone [email protected]:oleks.ca/bash.git
Entrer dans le repo
cd bash
Vérifier que tout est OK
git remote -v git status
Commandes Git les plus utilisées (avec explications)
Vérifier l’état du repo
git status
Affiche :
– la branche active ;
– les fichiers modifiés ;
– ce qui est déjà dans le staging (index) — la zone “prête à committer” après un git add ;
– les fichiers non suivis (untracked).
Voir les différences
git diff
Montre les changements pas encore ajoutés au staging.
git diff --staged
Montre les changements déjà ajoutés au staging.
Ajouter des fichiers au staging
Ajouter un fichier :
git add file.sh
Ajouter tout :
git add .
Créer un commit
git commit -m "Fix: update script options"
Un commit = une étape logique enregistrée dans l’historique.
Envoyer les changements vers GitLab
git push
Première fois sur une branche :
git push -u origin main
Récupérer les changements depuis GitLab
git pull
Techniquement, c’est un git fetch + merge/rebase (selon la config).
Voir l’historique
git log --oneline --decorate --graph -10
Travailler avec les branches
Lister les branches :
git branch
Créer une branche et s’y déplacer :
git switch -c feature/readme
Revenir sur une branche existante :
git switch main
Mettre de côté des changements temporairement (stash)
git stash push -m "WIP"
Restaurer :
git stash pop
Revenir à l’état du repo (annuler des changements locaux)
Annuler les changements non committés d’un fichier :
git restore file.sh
Annuler tout (attention) :
git restore .
Situations typiques : local ↔ GitLab
L’idée : les changements se préparent en local, et GitLab sert de “référence” pour synchroniser entre machines et/ou collaborateurs.
Situation A — Changements locaux à envoyer vers GitLab (push)
Vérifier ce qui a changé :
git status git diff
Ajouter au staging :
git add .
Créer un commit :
git commit -m "Describe change"
Envoyer :
git push
Situation B — Changements sur GitLab à récupérer en local (pull)
git pull
Note importante : Si le dépôt a évolué des deux côtés (en local et sur GitLab), Git peut afficher un avertissement demandant comment gérer la synchronisation.
Pour éviter cela, il est recommandé de configurer le comportement par défaut une fois pour toutes :
– Pour fusionner proprement en mettant tes changements locaux par-dessus ceux du serveur (fortement recommandé pour les scripts) :
git config --global pull.rebase true
– Pour faire une fusion classique avec un commit de merge automatique :
git config --global pull.rebase false
S’il y a des conflits (si la même ligne du même fichier a été modifiée des deux côtés), Git s’arrête et marque les zones conflictuelles directement dans les fichiers. Il suffit d’ouvrir le fichier, de choisir les bonnes lignes, de supprimer les balises de conflit (<<<<<<<, =======, >>>>>>>), puis de terminer en faisant un nouveau commit :
git add . git commit -m "Fix: resolve merge conflicts"
Situation C — Ignorer les changements locaux et revenir à la version GitLab
État :
git status
Revenir sur les fichiers suivis (tracked) :
git restore .
Supprimer les fichiers/dossiers non suivis (untracked) (attention) :
Toujours faire une simulation (dry run) d’abord pour éviter de perdre accidentellement des fichiers importants. Cela montre ce qui sera supprimé sans rien toucher :
git clean -fdn
Si la liste est correcte et sans danger, exécuter la suppression réelle :
git clean -fd
Attention : git clean -fd est une commande “aveugle”, elle supprime définitivement les fichiers non suivis (comme des scripts de test ou des fichiers de config locaux) sans passer par la corbeille.
Revenir strictement à la version d’origin/main :
git fetch origin git reset --hard origin/main
Attention : reset –hard supprime les changements locaux non sauvegardés.
Situation D — Remplacer la version GitLab par la version locale
En général, il vaut mieux éviter. Le scénario normal :
git pull git push
Si un écrasement est volontaire (risqué) :
git push --force-with-lease
Cela peut écraser des commits sur le serveur. À utiliser seulement si les conséquences sont bien comprises.
Situation E — Changements locaux en cours, mais besoin de pull sans perdre le travail (stash)
git stash push -m "temp" git pull git stash pop
Aide-mémoire rapide (le strict minimum)
Et pour conclure, voici la petite “cheat sheet” à garder sous la main :
Vérifier l’état : git status
Voir les différences : git diff
Ajouter au staging : git add .
Commit : git commit -m "..."
Récupérer depuis GitLab : git pull
Envoyer vers GitLab : git push
Annuler les changements locaux : git restore .
Revenir exactement comme sur le serveur (attention) : git fetch && git reset --hard origin/main
Voilà — on a fait connaissance avec Git : les notions de base, l’installation sur Debian, la connexion à GitLab via SSH, le clonage du repo et les commandes essentielles du quotidien. Avec ça, la gestion des scripts devient beaucoup plus propre : un historique clair, des changements traçables, et une synchro simple entre machines (ou en équipe).
Bonne chance!