Mon Git Survival Guide

Introduction

Je met noir sur blanc, une fois pour toute, deux ou trois trucs qui me mettent toujours plus ou moins en panique. Je sens que ça va se transformer en cheat sheet cette histoire…

drawing

Do you remember...🎵

Table of Contents

Installation Linux & Windows

Linux 

apt-get install git

Windows

Configuration à minima

Quand Git est installé, dans un terminal, pour s’assurer que tout va bien, saisir :

git

Ensuite saisir :

git config --global user.name "MON NOM"

Enfin, saisir :

git config --global user.email "ADR EMAIL"

On peut aussi saisir

git config --global init.defaultBranch main

En fait par défaut git crée une branche “master” dont le nom n’est plus trop dans l’air du temps (wokisme quand tu nous tiens…) ce qui peut poser des soucis lorsqu’on crée un repo depuis VSCode qui lui, va créer une branche “main”.

Je suis d’accord mon lapin, tout ça c’est des conneries, “master en servant” c’était pourtant bien cool, mais bon, autant se simplifier la vie dès le départ.

Prendre ensuite le temps de lire cette page.

Revenir en arrière

  • J’ai un projet Rust de démonstration, un truc simple, qui comporte peut être un ou deux fichiers source et qui est synchronisé sur GitHub
  • Je fais pas de branche (bien sûr…)
  • Je fait des bidouilles et je commit plusieurs fois
  • Je veux juste revenir au projet dans l’état il était en version V2 (129eca1)

Je fais quoi ?

git status
git log --oneline -n 5
git restore --source=129eca1 --staged --worktree .
git commit -m "revert: back to version V2 (129eca1)"
git push

Tout cassé et plusieurs commits entre temps

Typiquement avec le site 40tude.fr (Jekyll + thème Just The Docs) je fais des modifs dans le GemFile… et puis à un moment ça déploie plus sur GitHub

PANIQUE! 😡

git log --oneline -n 5
git reset --hard dfa46c011b33092ea30c14938616f5281f092811
git push --force
  • Avec le --hard on supprime les commits suivants et les modifications associées
  • --force la mise à jour du dépôt distant pour refléter l’état actuel de la branche locale. Les commits effacés seront également supprimés du dépôt distant.

C’est donc assez radical et cela ne marche que parce que je suis tout seul sur le projet. C’est pas du tout une bonne idée de faire ça si on est en équipe car pendant que tu ratatouille de ton côté, Robert lui a fait plusieurs commits vachement intéressants et si avec --hard tu supprimes les commits suivants… Ca va chù%@ pour ton matricule.

PLUS de PANIQUE… 😁

J’ai continué à bosser mais je veux revenir au dernier commit

Bien sûr, j’ai pas fait de commit entre temps… On est d’accord… Mais bon, je m’en sors plus, y a trop de modifications, ça va pas, c’est que du brin

PANIQUE! 😡

git reset --hard HEAD # 1. Annuler toutes les modifications non commitées
git clean -fd # 2. Supprimer les fichiers non suivis
git status #3. Vérifier que tout est propre

PLUS de PANIQUE… 😁

Récupérer un de mes projets sur GitHub

Dans PowerShell, dans le répertoire où on peut créer un sous-répertoire pour y héberger les sources du projet récupéré, taper :

git clone https://github.com/40tude/A-Tour-Of-Cpp.git
  • Faire des modifications dans les fichiers
  • Faire un commit
git commit -am "Relecture et typos"

Bien noter le “a” de “-am” qui “commit” tous le fichiers modifiés

  • Faire un push sur le serveur distant GitHub
git push master origin
  • Mettre à jour le projet
git fetch origin

Branch & Merge

Clairement je n’ai pas encore le réflexe… Je promets, je vais faire un effort…

  • Je me met dans le cas où :
    • J’ai un projet avec un repo GitHub
    • J’ai une idée transcendantale…

Mode VSCode

  • En bas à gauche je clique sur main
  • Je choisis Create New Branch (b1 par exemple)
  • Je modifie, j’ajoute des fichiers, je teste…
  • Je commit plusieurs fois
  • Quand j’ai terminé sur b1

Si je ne suis pas content

  • Je reviens sur main en cliquant en bas à gauche
  • Je supprime ensuite la branche b1

Si je veux intégrer mes modifications

  • Je reviens sur main en cliquant en bas à gauche
  • Je choisis Branch/Merge/b1
drawing

Quand le merge est fait, je commit main Je peux alors supprimer la branche b1

Si au moment du merge il y a un conflit

drawing

Ensuite on fait un commit de main Voir le graphe en bas à gauche

drawing

Mode CLI

  • Si on a un terminal ouvert dans le répertoire du projet (CTRL+SHIFT+ù sous VScode)
  • On peut mélanger les clicks dans VSCode et les commandes dans le terminal
Action Commande
Initialiser un dépôt Git git init
Ajouter des fichiers git add <file> git add .
Faire un commit git commit -m "message"
Créer une branche git checkout -b <branch-name>
Basculer entre branches git checkout <branch-name>
Ou créer/basculer sur la branche git switch -c <branch-name>
Fusionner une branche git merge <branch-name>
Résoudre un conflit Résoudre le conflit, puis git add <file>
Supprimer une branche git branch -d <branch-name>
Historique des commits git log --oneline --graph --all

Gros Fichier - Cas N°1

Note

  • Ci-dessous je peux me permettre de faire un git reset car je suis tout seul
  • Si jamais je suis en équipe il faudra utiliser git revert
    • Dans un cas (reset) on modifie ce sur quoi pointe HEAD
    • Alors que dans l’autre (revert) on ajoute à la série des commits locaux un nouveau commit qui annule mes bêtises
  • Si d’autres travaillent avec une copie du repo distant
    • Dans le premier cas ca va être Rock’n Roll au moment des merges (pull ou merge) car on va avoir des HEAD qui vont plus être synchros
    • Dans le second ca va bien se passer (j’ai juste rajouté un commit)

On se met dans le cas où

  • J’ai un projet qui est synchronisé sur GitHub
  • J’ajoute un fichier dont la taille est supérieure à 100 MB
  • J’oublie d’en tenir compte dans .gitignore
  • Je commit
  • Je synchronise

PANIQUE! 😡

drawing
drawing
  • Il semble qu’il n’a rien poussé
  • J’édite .gitignore
  • Je prends 2 captures d’écran que je met dans un dossier ./assets
  • Je commit et je synchronise

Même problème…

git reset --soft HEAD~2

Cela nous ramène à 2 commits en arrière dans le staging area. Je fais -2 car entre temps (-1) j’ai pris des captures d’écran etc.

  • Sous VSCode on le voit dans l’interface graphique

git rm --cached .\data\large_file.csv

Le gros fichier n’est plus suivi

drawing

Éditer .gitignore

# -----------------------------------------------------------------------------
# files to ignore
secrets.ps1
.env
Jenkinsfile
*.log

# too big
large_file.csv

# -----------------------------------------------------------------------------
# directories to ignore
.git/
.vscode/

# "**/.mypy_cache/" ignore all directories named ".mypy_cache/""
**/.mypy_cache/
**/__pycache__/
**/mlruns/
**/logs/
  • Tout sauver
  • Fair un commit
  • Faire un git push origin main --force (ligne de commande)

ATTENTION

  • Le SYNCHRONIZE (pull + push) de l’interface VSCode n’est PAS suffisant ici
  • En effet les historiques (local et distant) ne sont PLUS synchros (=> --force)

Différence entre Synchronize et git push --force

Action Synchronize git push –force
Récupération des modifications distantes Fait un pull avant le push Ne fait aucun pull.
Gestion des désalignements Échoue si l’historique diverge Écrase l’historique distant.
Cas d’utilisation Cas normaux (pas de désalignement) Réécriture d’historique ou conflits majeurs

PLUS de PANIQUE… 😁

Résumé 

git reset --soft HEAD~2
git rm --cached .\data\large_file.csv
Édite le .gitignore
Commit
git push origin main --force

Ou alors

git reset --soft HEAD~2
git rm --cached .\data\large_file.csv
git add .gitignore
git commit -m "Remove large file and update .gitignore"
git push origin main --force

Gros Fichier - Cas N°2

  • J’ai un projet qui est synchronisé sur GitHub
  • J’ajoute un fichier > 100 MB
  • J’oublie d’en tenir compte dans .gitignore
  • Je commit mais je ne fais PAS de synchronisation

Je réalise que j’ai un gros fichier… Comment revenir en arrière ?

PANIQUE! 😡

git reset --soft HEAD~1
git rm --cached .\data\large_file_2.csv
Éditer `.gitignore`
git add .gitignore
git commit -m "Remove large_file_2 and update .gitignore"
git push origin main --force

Note de ChatGPT

Les modifications non committées dans ton espace de travail ne seront pas perdues avec un git reset --soft. Ce mode préserve toutes tes modifications dans la staging area (index) et l’espace de travail. Si tu veux plus de sécurité, tu peux faire une copie temporaire de ton travail (git stash) avant d’exécuter cette commande.

git stash                       # Optionnel, si tu veux sauvegarder tes modifications locales
git reset --soft HEAD~1         # Annule le dernier commit
git rm --cached ./data/large_file_2.csv  # Supprime le fichier du suivi Git. On le voit plus das VSCode Source Control
echo "/data/large_file_2.csv" >> .gitignore  # Ajoute au .gitignore
git add .gitignore              # Ajoute le fichier .gitignore
git add .                       # Ajoute les autres modifications
git commit -m "Remove large file and update .gitignore"
git push origin main --force    # Réécrit l'historique
git stash pop                   # Optionnel, pour restaurer tes modifications

On retrouve bien le projet synchro sur GitHub

PLUS de PANIQUE… 😁

Résumé 

git stash
git reset --soft HEAD~1
git rm --cached ./data/large_file_2.csv
echo "/data/large_file_2.csv" >> .gitignore
git add .gitignore
git add .
git commit -m "Remove large file and update .gitignore"
git push origin main --force
git stash pop

Fichier secrets.ps1 ou .env

  • J’ai un projet qui est synchronisé sur GitHub
  • J’ajoute un fichier secrets.ps1 (ou un .env)
  • J’oublie d’en tenir compte dans .gitignore
  • Je commit et je sync

Comment revenir en arrière ?

PANIQUE! 😡

git reset --soft HEAD~1
git rm --cached ./secrets.ps1
Edition de .gitignore
git add .gitignore
# git add .
git commit -m "Remove secrets.ps1 to avoid a nuclear war :-)"
git push origin main --force

Pour aller plus loin…

  1. Nettoyer tout l’historique public : filter-repo
  2. Supprimer le cache GitHub pour garantir qu’aucune trace ne reste sur leurs serveurs

1. filter-repo : 

# Voir si on veut créer un env virtuel ou pas ????
# conda install filter-repo -c conda-forge
#       marche pas trop
#       trouve rien
#       en plus c'est pas à jour

pip install git-filter-repo
git config --global filter.repo.clean "git filter-repo"

Ensuite faut faire

cd chemin/vers/le/depot
git filter-repo --invert-paths --path ./secrets.ps1

Afin de vérifier qu’il ne reste plus de traces dans les logs

git log --all -- secrets.ps1
# Si y a une arborescence pour accéder au fichier
git log --all -- 01_model_and_data/01_model_and_data_ops/05_modelizer/assets/secrets.ps1

Quand tout est OK localement faut mettre à jour le repo distant

git push origin main --force

2. Supprimer le cache GitHub

  • ???

PLUS de PANIQUE… 😁

Répertoire de logs

  • J’ai un projet qui est synchronisé sur GitHub
  • J’ajoute un répertoire ./logs avec des centaines de logs qu’il est ridicule d’avoir sur GitHub.
  • J’oublie d’en tenir compte dans .gitignore
  • J’ai fait un commit et une synchro
  • Les fichiers de logs sont petits, tout est parti sur GitHub

Mais comment faire ? Comment revenir en arrière ?

PANIQUE! 😡

Je propose :

git reset --soft HEAD~1
git rm -r --cached ./logs
Edition de .gitignore (ajout de la ligne ``/logs/``)
git add .gitignore
git add .
git commit -m "Remove ./logs and all the logs files"
git push origin main --force

Bien voir le -r de la commande git rm

Note parce que j’oublie tout le temps :

  • logs/ - Ignore TOUS les dossiers nommés logs dans l’ensemble du projet, quelle que soit leur position dans l’arborescence.
  • /logs/ - Ignore uniquement le dossier logs situé à la racine du projet. Elle n’affectera pas les dossiers logs situés dans des sous-répertoires.

PLUS de PANIQUE… 😁

Pull Request (PR pour les intimes)

1. Forker le projet

  • Avec un browser web, faut aller sur : https://github.com/firstcontributions/first-contributions ou un autre projet, mais bon, celui là est justement pour qu’on s’entraîne.

  • Cliquer sur le bouton Fork (rectangle rouge ci-dessous)


  • On va récupérer une copie du projet dans notre repo GitHub
  • Sur notre PC, ouvrir un terminal dans un répertoire où on veut créer le clone
  • Cloner le projet à partir de notre repo Github
    • git clone https://github.com/40tude/first-contributions.git
    • git remote -v
  • Si dans la liste affichée on ne voit pas le repo du projet initial
    • git remote add upstream <URL-du-projet-original>
    • C’est à faire qu’une seule fois

2. Créer et basculer sur une branche

  • git switch -c b1

C’est équivalent à:

  • git branch b1 # créer la branche
  • git switch b1 # basculer vers la branche

3. Business as usual

  • Pas d’embrouille… On est bien sur la branche b1.
  • Lire : https://github.com/firstcontributions/first-contributions/blob/main/gui-tool-tutorials/github-windows-vs-code-tutorial.md
  • Faire les modifs proposées (ajouter son nom à contributors.md)
  • Sauver
  • Faire un commit de la branche b1 de notre repo Github

4. Pull Request

  • Avec un browser web faut aller sur la page du projet sur notre repo Github
  • GitHub a détecté une différence entre le fork et le projet original
  • Il propose de faire un pull request
  • Quand c’est fait, le PR est alors une proposition de merge de la branche b1 du fork vers la branche main du projet original

Ensuite…

  • Les mainteneurs examinent la PR, réunion du conseil d’état, tout ça, tout ça…
  • Il l’acceptent ou demandent des changements (via des commentaires sur GitHub).
  • Je fais les changements dans la branche b1 sur mon PC puis je commite sur mon repo GitHub
  • Les modifs seront automatiquement ajoutées à la PR
  • Je n’essaie pas de faire avance la branche. Je la laisse là où elle est. Si le PR est acceptée, la branche sera fusionnée avec son point d’anbranchement.

5. Se maintenir à jour

C’est important avec les “vrais” projets mais bon par exemple ici on peut imaginer que les mainteneurs prennent un peu de temps pour répondre. On va donc jouer le jeu et maintenir notre copie du projet synchronisée avec le projet. En effet lui de son côté, il continue a évoluer.

  • Du coup tous les matins il faut: 
    git fetch upstream                           # récupérer les updates
git switch main                              # laisser la branche sur laquelle on est et aller sur main
git merge upstream/main                      # fusionner les updates
git push origin main                         # pousser sur notre repo
  • Faut vraiment pas hésiter à créer autant de branches que nécessaires.
  • Si le PR est accepté faut plus toucher à la branche.
  • Si le PR est rejeté définitivement on peut choisir de supprimer la branche

Que faire si la branche b1 est affectée par les changements ?

git switch b1

Rebaser b1 sur la branche main à jour pour appliquer les changements récents de main sur la branche b1. Cela ajuste l’historique de la branche b1 pour qu’elle repose sur la dernière version de main.

git rebase main

Si il y a des conflits, les résoudre. À la fin :

git rebase --continue

Après le rebase, il faut forcer le push de la branche b1 vers le fork (car l’historique a changé)

  • git push --force-with-lease origin my_branch
  • git push origin b1 --force mais là attention si on est en équipe ou si on a fait des commits depuis une autre machine

Note pour savoir si il faut faire un rebase de b1

Etape 1 :

Action Commande
Vérifier si b1 est en retard par rapport à main git log b1..main
Identifier les fichiers impactés git diff b1..main
Faire un commit git rebase main

Etape 2 : On va voir les fichiers qui ont changé dans main mais pas dans b1. Si on voit des fichiers sur lesquels on travaille dans b1, alors faut rebaser

Comment nommer les branches?

  • feature/ ou feat/ → new features
  • fix/ ou bugfix/ → bug fixes
  • docs/ → documentation
  • refactor/ → refactoring (sans nouvelle feature)
  • test/ → adding tests
  • chore/ → taches diverses (config, dépendances…)
  • hotfix/ → correction urgente

Exemples:

  • feature/add-syntax-highlighting
  • fix/menu-crash-on-resize
  • docs/improve-readme
  • refactor/cleanup-event-handling
  • test/add-unit-tests-dialog

La routine du matin… 

# Ajouter le projet original comme remote (une seule fois, si ce n'a pas déjà été fait)
git remote add upstream <URL-du-projet-original>

# Récupérer les mises à jour du projet original et les mettre dans un "arbre" qui s'appelle ``upstream``
# Arbre n'est pas du tout un terme officiel je crois. C'est juste l'idée que je m'en fait
git fetch upstream

# Mettre à jour la branche main locale en applicant les modifications qui sont dans la branche upstream/main
git switch main
git merge upstream/main

# Pousser les mises à jour de la branche ``main`` sur mon fork sur GitHub
git push origin main


# Revenir sur la branche où on était
git switch my_branch

# Intégrer les derniers changements sur notre branche
git rebase main

# Travailler puis pousser sur notre repo et PR comme vu au dessus
git push --force-with-lease origin my_branch

Un ptit script Powershell pour la route?

Je propose : sync-fork.ps1

L’idée de ce script est d’avoir un espèce de couteau Suisse utilisable dans les 4 scénarios suivants:

  1. J’ai fait un fork. Je veux juste synchroniser main@local et main@origin avec main@uptstream. J’invoque le script sans nom de branche en paramètre
  2. Je veux tester des trucs et débuter une branche. J’invoque le script avec un nom de branche en paramètre. main@local et main@origin sont d’abord synchronisées avec main@uptstream. La branche est ensuite créée. À la fin j’ai switché sur la branche et je peux commencer à travailler
  3. J’ai commencé à travaillé sur la branche et j’ai sans doute fait des commits sur my_branch@origin. Je souahite je veux rester synchro avec upstream. J’invoque le script avec le nom de ma branche en paramètre. main@local et main@origin sont d’abord synchronisées avec main@uptstream. Ensuite ma branche est “repoussée” au bout de main@local. À la fin du script j’ai switché sur la branche et je peux continuer à travailler
  4. Je pense que ma branche est prête. J’ai fait des commits sur my_branch@origin. Je veux faire un PR. J’invoque le script avec le nom de ma branche en paramètre. main@local et main@origin sont d’abord synchronisées avec main@uptstream. Ensuite ma branche est “repoussée” au bout de main@local. À la fin du script j’ai “switché” sur la branche et je peux en toute sérénité aller faire mon PR sur GitHub (ou dans VSCode).
<#
.SYNOPSIS
    Fork Synchronization Script - Keeps your fork and branches in sync with upstream

.DESCRIPTION
    1. Drop this script at the root of the project and add it to `.gitignore`
    2. Edit the variable `$upstreamUrl` in the code

    The idea behind this script is to have a Swiss Army knife usable in the following 4 scenarios:

    1. I've created a fork. I just want to synchronize `main@local` and `main@origin` with `main@upstream`. I invoke the script without a branch name parameter. Example: ./sync-fork.ps1

    2. I want to test some things and start a new branch. I invoke the script with a branch name parameter. `main@local` and `main@origin` are first synchronized with `main@upstream`. The branch is then created. At the end, I've switched to the branch and can start working. Example: ./sync-fork.ps1 -BranchName feature/new_feature

    3. I've started working on the branch and probably made commits on `my_branch@origin`. I want to stay in sync with `upstream`. I invoke the script with my branch name parameter. `main@local` and `main@origin` are first synchronized with `main@upstream`. Then my branch is rebased on top of `main@local`. At the end of the script, I've switched to the branch and can continue working. Example: ./sync-fork.ps1 -BranchName feature/new_feature

    4. I think my branch is ready. I've made commits on `my_branch@origin`. I want to create a PR. I invoke the script with my branch name parameter. `main@local` and `main@origin` are first synchronized with `main@upstream`. Then my branch is rebased on top of `main@local`. At the end of the script, I've switched to the branch and can confidently proceed to create my PR on GitHub (or in VSCode). Example: ./sync-fork.ps1 -BranchName feature/new_feature

    This script automates synchronizing a Git fork with the upstream repository.
    It performs the following operations:
    - Adds upstream remote if missing
    - Fetches latest changes from upstream
    - Updates local main branch
    - Optionally creates or updates a working branch and rebases it on local main


.PARAMETER BranchName
    (Optional) The name of the working branch to update or create.
    If omitted, only the main branch and origin are synchronized.

.PARAMETER DryRun
    When specified, no Git commands are executed — they are only displayed.

.EXAMPLE
    Get-Help ./sync-fork.ps1 -Full
    Displays complete help for this script.

.EXAMPLE
    ./sync-fork.ps1
    Synchronizes only main@local and main@origin with main@upstream.

.EXAMPLE
    ./sync-fork.ps1 -BranchName feature/new_feature
    Synchronizes main@local and main@origin with main@upstream.
    Then updates or creates the feature/new_feature branch with the latest upstream changes.

.EXAMPLE
    ./sync-fork.ps1 -BranchName fix/typos -DryRun
    Simulates all operations without executing any Git commands.

.NOTES
    Author: 40tude
    Version: 1.5
    Required: PowerShell 5.1+
#>

param(
    [Parameter(Position = 0)]
    [string]$BranchName,

    [switch]$DryRun
)

# --- CONFIGURATION ---
$upstreamUrl = "https://github.com/<NAME>/<PROJECT>.git"  # Change this URL to your upstream repo

# --- HELPER FUNCTION ---
function Run-Git {
    param([string]$Command, [string]$Step)

    if ($DryRun) {
        Write-Host "[DryRun] git $Command" -ForegroundColor DarkGray
    } else {
        Write-Host "$Step..." -ForegroundColor Cyan
        Invoke-Expression "git $Command"
        if ($LASTEXITCODE -ne 0) {
            Write-Host "Error during step: $Step" -ForegroundColor Red
            exit 1
        }
    }
}

# --- STEP 1: Ensure origin and upstream remotes exist ---
$remotes = git remote
if ($remotes -notcontains "origin") {
    Write-Host "Error: 'origin' remote is missing. Please check your repository setup." -ForegroundColor Red
    exit 1
}

if ($remotes -notcontains "upstream") {
    Write-Host "Adding upstream remote..." -ForegroundColor Yellow
    Run-Git "remote add upstream $upstreamUrl" "Add upstream remote"
} else {
    Write-Host "Upstream remote already exists." -ForegroundColor Green
}

# --- STEP 2: Sync local main and origin with upstream ---
Run-Git "fetch upstream" "Fetching from upstream"
Run-Git "switch main" "Switching to main branch"
Run-Git "merge upstream/main" "Merging upstream/main into local main"
Run-Git "push origin main" "Pushing updated main to origin"

# --- CONDITIONAL: only continue if a branch name was provided ---
if (-not [string]::IsNullOrEmpty($BranchName)) {
    Write-Host "`nProcessing branch '$BranchName'..." -ForegroundColor Cyan

    $branchExists = git branch --list $BranchName

    if (-not $branchExists) {
        Run-Git "switch -c $BranchName" "Creating new branch '$BranchName'"
    } else {
        Run-Git "switch $BranchName" "Switching to existing branch '$BranchName'"
    }

    Run-Git "rebase main" "Rebasing '$BranchName' on main"
    Run-Git "push --force-with-lease origin $BranchName" "Pushing '$BranchName' to origin"

    Write-Host "`nBranch '$BranchName' is now up to date and ready for a Pull Request." -ForegroundColor Green
}
else {
    Write-Host "`nNo branch name provided. Only main and origin were synchronized with upstream." -ForegroundColor Green
}

Combien de fois par jour ?

Combien de fois par jour faut il synchroniser avec le main du projet initial?

Une à deux fois par jour

  1. Synchroniser une fois au début de la journée (ou avant de commencer une nouvelle tâche)
    • Travailler avec une base de code à jour.
  2. Synchroniser une deuxième fois en fin de journée (ou avant un pull request)
    • S’assurer que les modifications qu’on soumet sont compatibles avec les changements récents sur main

Bonnes pratiques pour les merges sur main ?

C’est peut être pas cool ni dans l’air du temps, mais ça passe par une politique stricte des merges ainsi que par de la discipline.

Utiliser des feature branches

  • Toute idée doit être développée dans une branche (ex. : feature/ticket-123)
  • Interdiction de pousser sur main.

Passer par des pull requests

  • Les merges dans main doivent être effectués via des PR
  • Bien sûr, entre temps, il y a eu une revue de code, tous les test passent etc.

Limiter le nombre de merges par jour

  • Limiter les merges dans main à 1 ou 2 moments précis par jour
    • Exemple : à midi et en fin de journée
  • Facilite la synchronisation et “éduque” l’équipe
    • “Merde, je vais être en retard pour le merge de 18H00”

Automatiser la validation avec CI

  • Avant de merger dans main
  • Exécuter automatiquement la suite de tests via Jenkins (GitHub Actions, GitLab CI/CD…)

Le workflow idéal ?

1. Membre de l’équipe

Avant de commencer une nouvelle tâche

  • Synchroniser avec main pour partir d’une base de code propre : 
       git fetch upstream
   git switch main
   git merge upstream/main
   git switch -c <ma_tache> # -c pour créer

Pendant le développement

  • Travailler dans une branche dédiée (ex. : feature/ticket-123)
  • Synchroniser cette branche avec main régulièrement
    • surtout si le développement dure plusieurs jours.

Avant de soumettre une PR

  • Synchroniser avec main une dernière fois pour résoudre les éventuels conflits en amont.

2. L’équipe

Planifier les merges dans main

  • Les merges ont lieu 2 fois par jour (midi et fin de journée).
  • Cela permet à tout le monde le temps de se synchroniser

Communiquer activement

  • Informer à propos des merges importants
  • Pour que tout le monde puisse vérifier si se branche est impactée ou pas

Respecter le processus de PRs

  • On ne peut merger qu’une PR qui a été revue et testée

Webliographie

Back to top

Published on: Nov 29 2024 at 03:00 PM | Last updated: Nov 12 2025 at 04:00 PM

Copyright © 1964-2025 - 40tude