1 · Connexion remote

Un remote est un alias pointant vers un dépôt distant (GitHub, GitLab, Bitbucket…). Le remote conventionnel s'appelle origin.

Gérer les remotes

Copier# Lier un dépôt local à un remote GitHub
git remote add origin https://github.com/user/repo.git

# Afficher les remotes configurés
git remote -v
# origin  https://github.com/user/repo.git (fetch)
# origin  https://github.com/user/repo.git (push)

# Changer l'URL d'un remote
git remote set-url origin git@github.com:user/repo.git

# Renommer un remote
git remote rename origin upstream

# Supprimer un remote
git remote remove old-remote

SSH vs HTTPS

Copier# Générer une clé SSH (une seule fois)
ssh-keygen -t ed25519 -C "alaa@example.com"
# Copier ~/.ssh/id_ed25519.pub dans GitHub → Settings → SSH Keys

# Tester la connexion SSH
ssh -T git@github.com
# → Hi user! You've successfully authenticated.

2 · Push & Pull

Synchronisez votre dépôt local avec le remote pour partager et récupérer les modifications.

Push : envoyer vos commits

Copier# Premier push : lier la branche locale à origin/main
git push -u origin main
# -u = --set-upstream : mémorise origin/main pour les prochains push

# Pousser une branche feature
git push origin feature/login

# Après un rebase ou amend : force-push sécurisé
git push --force-with-lease origin feature/login

# Supprimer une branche distante
git push origin --delete feature/ancienne-branche

Pull : récupérer les modifications

Copier# Récupérer ET merger les modifications de origin/main
git pull origin main

# Pull avec rebase (évite les merge commits inutiles)
git pull --rebase origin main

# Configurer pull --rebase par défaut
git config --global pull.rebase true

Fetch vs Pull

3 · Fork & Clone

La distinction fork/clone est fondamentale pour contribuer à l'open source.

Fork vs Clone

Workflow contributeur open source

Copier# 1. Cloner VOTRE fork (pas l'upstream)
git clone https://github.com/VOUS/projet.git
cd projet

# 2. Ajouter l'upstream (dépôt original)
git remote add upstream https://github.com/AUTEUR/projet.git
git remote -v
# origin   https://github.com/VOUS/projet.git
# upstream https://github.com/AUTEUR/projet.git

# 3. Synchroniser votre fork avec l'upstream
git fetch upstream
git switch main
git rebase upstream/main
git push origin main

Clone shallow pour les gros dépôts

Copier# Clone avec seulement le dernier commit (plus rapide)
git clone --depth=1 https://github.com/user/repo.git

# Récupérer l'historique complet ensuite
git fetch --unshallow

4 · Issues GitHub

Les Issues sont le système de ticket intégré à GitHub. Elles tracent bugs, fonctionnalités, et discussions.

Composants d'une issue

• Titre — Court et descriptif : "Bug : le formulaire ne valide pas les emails"
• Description — Contexte, étapes de reproduction, comportement attendu vs observé
• Labels — bug, enhancement, documentation, good first issue, help wanted…
• Assignees — Qui est responsable de résoudre l'issue
• Milestones — Regrouper les issues par version (v2.0, Sprint 3…)
• Projects — Tableau Kanban GitHub Projects

Fermer une issue via un commit

Copier# Mots-clés qui ferment automatiquement l'issue à la merge de la PR :
# fixes, closes, resolves (insensible à la casse)

git commit -m "fix: correction validation email — Fixes #42"
git commit -m "feat: ajout page contact — Closes #15, Closes #23"

# Cross-repo (autre dépôt)
git commit -m "fix: Closes user/autre-repo#7"

Template d'issue (bug report)

Copier# .github/ISSUE_TEMPLATE/bug_report.md
---
name: Bug Report
about: Signaler un bug
labels: bug
---

## Description du bug
...

## Étapes de reproduction
1.
2.

## Comportement attendu vs observé
...

## Environnement
- OS:
- Browser:
- Version:

5 · Code Review

La code review est au cœur du travail collaboratif sur GitHub. Elle garantit la qualité et le partage de connaissances.

Types de feedback

Suggestion de code

Copier# Dans un commentaire de review, proposer un remplacement direct :
```suggestion
const email = value.trim().toLowerCase();
```
# L'auteur peut accepter la suggestion en 1 clic → commit automatique

Bonnes pratiques de code review

• Commenter le code, pas la personne ("Ce bloc peut être simplifié en…" vs "Tu as mal codé…")
• Distinguer les bloquants ("Must fix") des suggestions ("Nit:", "Optional:")
• Indiquer pourquoi, pas seulement quoi ("Cette approche peut causer des race conditions car…")
• Résoudre les threads quand la correction est faite
• Utiliser les CODEOWNERS pour assigner automatiquement les bons reviewers

CODEOWNERS

Copier# .github/CODEOWNERS
# Tous les fichiers → revue par @team-lead
* @team-lead

# Dossier backend → revue par l'équipe backend
/src/api/ @org/backend-team

# Fichiers de conf → DevOps
*.yml @org/devops
Dockerfile @org/devops

6 · GitHub Flow

GitHub Flow est une méthodologie simple et efficace pour les équipes pratiquant le déploiement continu.

Les règles de GitHub Flow

• main est toujours déployable — on ne merge que du code validé et testé
• Toute modification passe par une branche — jamais de commit direct sur main
• Les branches sont descriptives : feature/user-auth, fix/login-validation
• Push régulier — partager l'avancement, éviter les gros diffs
• PR pour démarrer la conversation — même avant d'être prêt (Draft PR)

Workflow complet en commandes

Copier# 1. Créer et se placer sur la branche
git switch -c feature/user-auth

# 2. Coder et committer
git add .
git commit -m "feat: ajout authentification JWT"

# 3. Pousser sur origin
git push -u origin feature/user-auth

# 4. Créer la PR via GitHub CLI
gh pr create --title "feat: authentification JWT" --body "Implémente #23"

# 5. Après la review et approbation, merger via GitHub
# 6. Nettoyer la branche locale
git switch main
git pull origin main
git branch -d feature/user-auth