Module 04 · Git & GitHub · Mémo

Mémo Git & GitHub

1. Git quotidien

CommandeÀ quoi elle sert / options utiles
sudo apt update && sudo apt install gitMet à jour l’index des paquets puis installe Git sur Debian/Ubuntu.
git --versionVérifie que Git est installé et affiche sa version.
git configConsulte ou modifie la configuration Git.
  • --list : affiche les variables de configuration visibles pour le dépôt courant.
  • --global : lit ou modifie la configuration de l’utilisateur, utilisée par défaut dans ses dépôts.
  • Exemple : git config --global user.email "vous@example.com" modifie la valeur user.email que l’on retrouve avec git config --list.
git statusAffiche l’état du dépôt : branche courante, fichiers modifiés, indexés ou non suivis.
git diffCompare les modifications du répertoire de travail avec l’index.
  • --cached (ou --staged) : affiche ce qui est déjà dans l’index et sera inclus dans le prochain commit.
  • <branche-ou-sha>..<branche-ou-sha> : compare deux références.
git logConsulte l’historique des commits.
  • --oneline : affiche chaque commit sur une seule ligne avec son SHA abrégé et son message.
  • --graph : dessine un graphe ASCII pour visualiser les branches et les merges.
  • --name-status : affiche, pour chaque commit, les fichiers concernés et leur statut : A (ajout), M (modification), D (suppression).
  • --decorate : affiche les noms de branches et tags associés aux commits.
  • --all : inclut dans l’affichage les commits accessibles depuis toutes les références connues, pas seulement la branche courante.
git switchCommande moderne dédiée au changement de branche, à privilégier pour cet usage à la place de git checkout.
  • git switch feature/x : change de branche ; équivalent de git checkout feature/x.
  • git switch -c feature/x : crée la branche puis bascule dessus ; équivalent de git checkout -b feature/x.
git stashMet temporairement de côté des modifications non commitées.
  • push -m "WIP" : crée un stash nommé.
  • list : liste les stash.
  • pop : réapplique le dernier stash puis le supprime de la pile.
git revert <sha>Crée un nouveau commit qui annule les effets du commit ciblé. Adapté à un historique déjà partagé.
git reflogAffiche les déplacements locaux de HEAD. Très utile pour retrouver un commit après un reset, rebase ou changement de branche.
git cherry-pick <sha>Rejoue un commit précis sur la branche courante.
git rebase <base>Rejoue les commits de la branche courante sur une nouvelle base. À éviter sur un historique partagé sans coordination.

2. Branches et remote

CommandeÀ quoi elle sert / options utiles
git remoteListe les remotes configurés.
  • -v : affiche également les URL utilisées pour fetch et push.
git branchListe et gère les branches.
  • -a : affiche branches locales et branches distantes connues.
  • -r : uniquement les branches distantes connues.
  • -vv : affiche le suivi upstream et l’avance/retard de chaque branche locale.
  • -d feature/x : supprime localement une branche déjà fusionnée.
  • -D feature/x : force la suppression locale ; à utiliser seulement si la perte des commits non fusionnés est volontaire.
git fetchRécupère les nouvelles références du remote sans modifier la branche de travail.
  • --prune : supprime les références locales origin/... correspondant à des branches supprimées sur le remote. Cela ne supprime pas vos branches locales.
git pushPublie des commits ou agit sur une référence distante.
  • -u origin feature/x : publie la branche et configure origin/feature/x comme upstream.
  • origin --delete feature/x : supprime la branche sur le remote après merge/livraison.
  • --force-with-lease : force un push uniquement si la branche distante n’a pas évolué à votre insu ; préférable à --force.
git pullRécupère puis intègre les changements de l’upstream dans la branche courante.
  • --rebase : rejoue les commits locaux au-dessus des commits récupérés au lieu de créer un merge de synchronisation.
Réflexe après merge : supprimer la branche distante avec git push origin --delete feature/x, supprimer la branche locale avec git branch -d feature/x, puis utiliser git fetch --prune pour nettoyer les références distantes devenues obsolètes.
Historique partagé : préférer revert. Si un push forcé est exceptionnellement nécessaire sur votre propre branche, préférer --force-with-lease à --force.

3. GitHub Actions

name: CI
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
  workflow_dispatch:
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pytest
CléRappel
onDéclencheur
jobsTravaux
runs-onRunner
stepsÉtapes
usesAction réutilisable
runCommande shell
needsDépendance entre jobs
strategy.matrixVariantes d'exécution

4. Events / triggers

Chaque scénario ci-dessous conserve la même ossature minimale : name → on → jobs. Le contenu du job est volontairement réduit afin de voir immédiatement ce qui change dans le déclencheur.

4.1. Push sur main

Cas typique lorsque main représente la branche de production : le workflow démarre après un push sur cette branche.

name: Push main
on:
  push:
    branches: [main]

jobs:
  run:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: echo "Push sur main"

4.2. Pull request vers main

Déclenche les contrôles lorsqu’une pull request cible main, avant le merge.

name: PR main
on:
  pull_request:
    branches: [main]

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: echo "Validation de la PR"

4.3. Déclenchement manuel

workflow_dispatch ajoute le déclenchement manuel du workflow depuis GitHub Actions.

name: Manuel
on:
  workflow_dispatch:

jobs:
  run:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Lancement manuel"

4.4. Limiter un push à certains fichiers

paths permet de ne déclencher le workflow que si les fichiers correspondant aux chemins indiqués ont changé. paths-ignore fait l’inverse.

name: Push application
on:
  push:
    branches: [main]
    paths:
      - "src/**"

jobs:
  run:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: echo "Le code applicatif a changé"

5. Variables, secrets et diagnostic

ÉlémentSyntaxe / exempleÀ quoi il sert
envenv:
APP_ENV: production		Déclare des variables d’environnement. La portée peut être le workflow, un job ou une step ; une déclaration plus locale peut préciser la valeur utilisée.
Lire une variable env${{ env.APP_ENV }}
$APP_ENV dans un shell Linux		Le contexte env est utilisable dans les expressions GitHub ; dans une commande run, la variable est également disponible dans l’environnement du shell.
GITHUB_REPOSITORY$GITHUB_REPOSITORYDépôt concerné, sous la forme propriétaire/dépôt.
GITHUB_ACTOR$GITHUB_ACTORUtilisateur ou acteur ayant déclenché le workflow.
GITHUB_EVENT_NAME$GITHUB_EVENT_NAMENom de l’événement ayant déclenché le run, par exemple push ou pull_request.
GITHUB_REF$GITHUB_REFRéférence Git associée au run.
GITHUB_SHA$GITHUB_SHASHA du commit associé au run.
GITHUB_WORKSPACE$GITHUB_WORKSPACERépertoire de travail mis à disposition du job sur le runner.
Secret${{ secrets.NOM }}Lit un secret configuré dans GitHub. Ne pas placer une valeur sensible directement dans le YAML.
GITHUB_TOKEN${{ secrets.GITHUB_TOKEN }}Jeton fourni au workflow pour agir sur le dépôt selon les permissions accordées.
permissionspermissions:
contents: read		Réduit ou précise les droits accordés au GITHUB_TOKEN. Donner seulement les droits nécessaires.
Diagnostic d’un runEvent → filtres → job → needs → step en erreur → logs → variables/contextesOrdre de lecture rapide lorsqu’un workflow ne démarre pas, qu’un job est ignoré ou qu’une étape échoue.
Réflexe : si le workflow ne démarre pas, vérifier d’abord on, la branche et les filtres. S’il démarre mais échoue, descendre ensuite jusqu’au job et à la step en erreur, puis lire ses logs et les valeurs de contexte disponibles.