Git et GitHub pour les QA Engineers: Un Tutoriel Sans Remplissage

Tout poste QA en automatisation exige Git. Pas comme un bonus, comme prérequis. Vos tests vivent dans un dépôt, votre CI/CD tourne depuis ce dépôt, et votre équipe revoit le code via des pull requests.

Ce que fait Git

Git suit les modifications des fichiers dans le temps. Chaque changement sauvegardé (un "commit") est enregistré avec une description, un horodatage, et son auteur. Vous pouvez voir l'historique complet de chaque fichier et revenir à n'importe quel état antérieur. Vous pouvez aussi travailler sur des modifications sans affecter la base de code principale tant que vous n'êtes pas prêt.

Pour les ingénieurs QA : Git est le moyen de sauvegarder votre travail de test, de le partager avec les développeurs, et de le lancer dans les pipelines CI/CD. Pas de pipeline CI sans dépôt.

Installer Git

Téléchargez depuis git-scm.com et installez. Pendant l'installation, sélectionnez "Use Git from the command line and also from 3rd-party software."

Lancez xcode-select --install dans le Terminal. Git est inclus.

git --version
# git version 2.44.0

Les 10 commandes que vous utiliserez 90% du temps

Configuration (une seule fois)

# Dire à Git qui vous êtes
git config --global user.name "Votre Nom"
git config --global user.email "vous@exemple.com"

Créer ou cloner un dépôt

# Initialiser un nouveau dépôt dans le dossier courant
git init

# Cloner un dépôt existant depuis GitHub
git clone https://github.com/username/nom-du-depot.git

Pour la plupart des ingénieurs QA, vous ferez plus de clone que de init. Vous rejoindrez un projet existant.

Voir ce qui a changé

# Voir quels fichiers ont des modifications
git status

# Voir les modifications spécifiques dans les fichiers
git diff

Lancez git status constamment. Il vous indique exactement où vous en êtes.

Sauvegarder votre travail (le workflow de base)

# Ajouter des fichiers spécifiques à l'index (les mettre dans la liste "à commiter")
git add tests/login.spec.ts
git add pages/LoginPage.ts

# Ou ajouter tous les fichiers modifiés
git add .

# Commiter les changements indexés avec un message
git commit -m "Add login test cases with negative scenarios"

Indexer → Commiter. C'est le cycle de sauvegarde. Le message décrit ce que vous avez changé et pourquoi.

Synchroniser avec le remote (GitHub)

# Récupérer les derniers changements depuis GitHub
git pull

# Envoyer vos commits vers GitHub
git push

Travailler sur des fonctionnalités (branches)

# Créer une nouvelle branche et y basculer
git checkout -b feature/add-login-tests

# Voir toutes les branches
git branch

# Basculer vers une branche existante
git checkout main

Un workflow quotidien complet

Voici à quoi ressemble l'utilisation de Git en pratique sur une journée type :

# 1. Démarrer la journée — récupérer les derniers changements
git pull

# 2. Créer une branche pour votre travail
git checkout -b test/payment-flow-automation

# 3. Écrire vos tests dans VS Code
# ... (tests/payment.spec.ts créé/modifié)

# 4. Vérifier ce qui a changé
git status
# On branch test/payment-flow-automation
# Changes not staged for commit:
#   modified:   tests/payment.spec.ts
# Untracked files:
#   pages/PaymentPage.ts

# 5. Indexer les fichiers
git add tests/payment.spec.ts
git add pages/PaymentPage.ts

# 6. Commiter avec un message clair
git commit -m "Add payment flow tests: happy path and card decline scenarios"

# 7. Pousser vers GitHub
git push origin test/payment-flow-automation

# 8. Ouvrir une pull request sur GitHub (dans le navigateur)

GitHub : hébergement de dépôts distants

GitHub stocke votre dépôt en ligne. Les principales actions sur GitHub :

1. Allez sur github.com → New repository

2. Donnez-lui un nom

3. Choisissez Public ou Private

4. Cliquez sur Create

# Après avoir créé le dépôt sur GitHub, connectez votre dossier local
git remote add origin https://github.com/votrenom/votre-depot.git
git push -u origin main

Quand vous avez terminé votre travail sur une branche, vous ouvrez une pull request sur GitHub. Elle montre les changements faits, laisse l'équipe les réviser et commenter, puis fusionne dans la branche principale après approbation.

Pour les ingénieurs QA en équipe : votre code de test passe par le même processus de revue que le code des développeurs. Ouvrez une PR, faites-la réviser, fusionnez.

.gitignore : ce qu'il ne faut pas suivre

Certains fichiers ne doivent pas aller dans Git : les sorties de build, les secrets, les node_modules. Créez un fichier .gitignore à la racine de votre dépôt :

# Node modules (toujours ignoré — installez avec npm install à la place)
node_modules/

# Résultats et rapports de tests Playwright
test-results/
playwright-report/

# Fichiers d'environnement qui peuvent contenir des secrets
.env
.env.local

# Fichiers système
.DS_Store
Thumbs.db

Branches : pourquoi elles comptent pour QA

Les branches permettent à plusieurs personnes de travailler simultanément sans se marcher dessus. Conventions de nommage standard :

main               # code stable, prêt pour la production
feature/add-search # nouvelle fonctionnalité en développement
bugfix/login-error # bug en cours de correction
test/checkout-flow # nouveau test en cours d'écriture

Le pattern utilisé par la plupart des équipes :

1. La branche main est toujours stable

2. Tout le monde crée des branches feature/test pour son travail

3. Le travail est revu dans des pull requests

4. Les changements approuvés fusionnent dans main

5. Le CI/CD se lance automatiquement quand les changements atteignent main

En tant qu'ingénieur QA, vous créerez des branches pour de nouvelles suites de tests, des mises à jour de tests, et des reproductions de bugs.

Conflits de fusion : ce que c'est et comment les résoudre

Un conflit de fusion se produit quand deux personnes ont modifié la même partie du même fichier et que Git ne peut pas les combiner automatiquement.

<<<<<<< HEAD
await expect(page.getByText('Success')).toBeVisible();
=======
await expect(page.getByRole('alert')).toHaveText('Success');
>>>>>>> feature/update-assertions

La section <<<<<<< HEAD est votre version. La section >>>>>>> feature/update-assertions est la version entrante. Vous devez choisir l'une (ou les combiner manuellement), supprimer les marqueurs de conflit, et commiter.

La plupart des conflits dans les dépôts de tests sont faciles à résoudre. Ils arrivent surtout dans les fichiers partagés comme playwright.config.ts ou les fichiers Page Object que plusieurs personnes touchent.

Git log : comprendre l'historique

# Voir les commits récents
git log --oneline
# a3f2c1d Add payment tests
# b7e9a04 Fix login page locator after UI update
# c2d1f8e Add item creation test with validation scenarios

# Voir les changements d'un commit spécifique
git show a3f2c1d

# Voir qui a modifié en dernier chaque ligne d'un fichier
git blame tests/login.spec.ts

GitHub Actions : votre pipeline CI

Une fois vos tests dans GitHub, GitHub Actions peut les lancer automatiquement à chaque push. Un fichier de workflow basique :

# .github/workflows/playwright.yml
name: Playwright Tests
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test

C'est le fichier que npm init playwright@latest propose de créer pour vous. Une fois dans votre dépôt, GitHub lance vos tests à chaque push et pull request. L'article sur CI/CD couvre ça en détail.

Aide-mémoire des commandes

# Configuration
git config --global user.name "Nom"
git config --global user.email "email"

# Quotidien
git status              # voir ce qui a changé
git pull                # récupérer la dernière version du remote
git add file.ts         # indexer un fichier
git add .               # indexer tous les fichiers modifiés
git commit -m "message" # sauvegarder les changements indexés
git push                # envoyer vers le remote

# Branches
git checkout -b nom-branche   # créer et basculer
git checkout main              # basculer sur main
git branch                     # lister les branches
git merge nom-branche          # fusionner une branche dans la courante

# Historique
git log --oneline              # commits récents
git diff                       # changements non indexés
git show hash-commit           # changements dans un commit

FAQ

Les deux fonctionnent. VS Code intègre le support Git (le panneau Source Control) qui couvre la plupart des opérations quotidiennes sans ligne de commande. GitHub Desktop est une autre option. La ligne de commande vaut la peine d'être apprise : vous la rencontrerez dans les scripts CI/CD et sur les serveurs distants. Commencer avec une interface graphique est tout à fait bien.

Git est le logiciel de contrôle de version qui s'exécute en local. GitHub est un site qui héberge les dépôts Git à distance. GitLab et Bitbucket sont des alternatives à GitHub. Git fonctionne sans GitHub ; GitHub stocke et partage vos dépôts Git.

Soyez précis. "Add login tests" est trop vague. "Add negative login tests: wrong password, empty fields, SQL injection" est utile. Un bon message de commit répond à : qu'est-ce qui a changé et pourquoi (pas comment, le code montre comment).

Pas de panique. Si vous n'avez pas encore pushé :

git reset HEAD~1  # annuler le dernier commit, garder les modifications
git checkout -b ma-branche  # créer une branche appropriée
git add .
git commit -m "message"

Si vous avez pushé et que votre équipe utilise une branche main protégée, consultez votre tech lead. Ne faites jamais un force-push sur main sans consensus de l'équipe.

Oui, si vous l'aviez commité auparavant :

git checkout HEAD -- chemin/vers/fichier.ts

C'est l'une des fonctionnalités les plus utiles de Git. Vous pouvez récupérer tout ce qui a été commité un jour.