Collaboration avec GitHub

Collaboration avec GitHub

Dépôts distants (remotes)

Un remote est un dépôt Git hébergé sur un serveur (GitHub, GitLab, Bitbucket). Il permet de collaborer en synchronisant le code entre développeurs.

# Voir les remotes configurés
git remote -v

# Ajouter un remote
git remote add origin https://github.com/user/projet.git

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

Push — envoyer du code

# Pousser la branche courante
git push origin main

# Premier push d'une nouvelle branche (avec tracking)
git push -u origin feature/login
# Ensuite, un simple git push suffit
git push

# Pousser toutes les branches
git push --all origin

# Pousser les tags
git push --tags

Pull — récupérer du code

# Récupérer et fusionner les changements
git pull origin main

# Équivalent à :
git fetch origin
git merge origin/main

# Pull avec rebase (historique plus propre)
git pull --rebase origin main

Fetch — récupérer sans fusionner

# Récupérer les infos du remote sans modifier vos fichiers
git fetch origin

# Voir les branches distantes
git branch -r

# Voir les différences avec le remote
git diff main origin/main

# Basculer sur une branche distante
git checkout -b feature/api origin/feature/api

Les Pull Requests (PR)

Une Pull Request est une demande de fusion d'une branche dans une autre, avec un processus de revue de code.

Workflow d'une Pull Request

1. Créer une branche
   git checkout -b feature/panier

2. Développer et committer
   git add .
   git commit -m "Ajouter le panier d'achat"

3. Pousser la branche
   git push -u origin feature/panier

4. Créer la PR sur GitHub
   → Titre clair et description détaillée

5. Revue de code
   → Les collègues commentent et approuvent

6. Merger la PR
   → Squash, merge ou rebase

7. Supprimer la branche
   git branch -d feature/panier

Rédiger une bonne Pull Request

## Description
Ajout du système de panier d'achat permettant aux utilisateurs
d'ajouter des produits et de passer commande.

## Changements
- Création du composant CartComponent
- Ajout du service CartService avec gestion du localStorage
- Intégration avec l'API /orders

## Comment tester
1. Se connecter avec un compte utilisateur
2. Ajouter un produit au panier
3. Vérifier que le compteur se met à jour
4. Valider la commande

## Captures d'écran
[Si pertinent, ajouter des captures]

Stratégies de merge

Stratégie Résultat Quand l'utiliser
Merge commit Conserve tous les commits + commit de merge Historique complet important
Squash and merge Un seul commit propre Feature avec beaucoup de petits commits
Rebase and merge Historique linéaire Préférence pour un historique propre

Travailler en équipe

Fork et contribution open source

# 1. Forker le projet sur GitHub (via l'interface web)

# 2. Cloner votre fork
git clone git@github.com:votre-user/projet.git
cd projet

# 3. Ajouter le dépôt original comme remote
git remote add upstream https://github.com/original/projet.git

# 4. Créer une branche pour votre contribution
git checkout -b fix/typo-readme

# 5. Faire vos modifications et committer
git add .
git commit -m "Corriger les fautes dans le README"

# 6. Pousser sur votre fork
git push origin fix/typo-readme

# 7. Créer une PR depuis votre fork vers le dépôt original

# Garder votre fork à jour
git fetch upstream
git checkout main
git merge upstream/main
git push origin main

Revue de code — bonnes pratiques

En tant que reviewer :

  • Soyez constructif et bienveillant
  • Posez des questions plutôt que d'imposer
  • Concentrez-vous sur la logique, pas le style (le linter s'en charge)
  • Approuvez quand c'est prêt, ne bloquez pas sur des détails

En tant qu'auteur :

  • Gardez les PR petites et focalisées (< 400 lignes idéalement)
  • Répondez à tous les commentaires
  • Ne prenez pas les retours personnellement

Tags et releases

Les tags marquent des versions importantes dans l'historique.

# Créer un tag annoté
git tag -a v1.0.0 -m "Première version stable"

# Créer un tag sur un ancien commit
git tag -a v0.9.0 abc1234 -m "Version beta"

# Lister les tags
git tag
git tag -l "v1.*"                # Filtrer

# Pousser les tags
git push origin v1.0.0
git push --tags                  # Tous les tags

# Supprimer un tag
git tag -d v1.0.0                # Local
git push origin --delete v1.0.0  # Distant

Versionnement sémantique (SemVer)

v MAJOR . MINOR . PATCH
  │       │       └── Corrections de bugs (rétrocompatible)
  │       └── Nouvelles fonctionnalités (rétrocompatible)
  └── Changements cassants (non rétrocompatible)

Exemples :
v1.0.0 → v1.0.1  # Bug fix
v1.0.1 → v1.1.0  # Nouvelle feature
v1.1.0 → v2.0.0  # Breaking change

GitHub Actions — introduction au CI/CD

GitHub Actions permet d'automatiser des tâches à chaque push ou PR.

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Installer Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Installer les dépendances
        run: npm ci

      - name: Lancer les tests
        run: npm test

      - name: Lancer le linter
        run: npm run lint

Bonnes pratiques de collaboration

  1. Toujours passer par des PR — ne poussez jamais directement sur main
  2. Protégez la branche main — exigez au moins une approbation
  3. Synchronisez-vous régulièrement avec git pull --rebase
  4. Communiquez dans les PR — utilisez les descriptions et commentaires
  5. Utilisez des conventions pour les noms de branches et messages de commit
  6. Automatisez avec le CI/CD — tests, lint, build à chaque PR
  7. Taguez vos releases avec le versionnement sémantique