Mettre en place et piloter le projet sur GitHub

Créer le dépôt et le premier commit

Objectifs — installer et configurer Git, comprendre dépôt local / dépôt distant, créer le dépôt fioul-groupe sur GitHub, l'authentifier, et pousser un premier contenu.

1 · Installer et configurer Git

Terminal (une seule fois par poste)

git --version                       # vérifier l'installation
git config --global user.name "Prénom Nom"
git config --global user.email "prenom.nom@exemple.fr"
git config --global init.defaultBranch main   # branche par défaut = main
git config --global core.autocrlf input        # fins de ligne (Windows)

2 · Créer un compte et le dépôt sur GitHub

3 · S'authentifier : SSH ou token

GitHub n'accepte plus le mot de passe en ligne de commande. Deux méthodes :

Option A — clé SSH (recommandée)

ssh-keygen -t ed25519 -C "prenom.nom@exemple.fr"
cat ~/.ssh/id_ed25519.pub          # copier la clé PUBLIQUE

Option B — jeton d'accès personnel (PAT) pour HTTPS

4 · Relier le local au distant

Le dépôt existe déjà sur GitHub (créé à l'étape 2). On le clone pour en avoir une copie locale :

git clone git@github.com:<compte>/fioul-groupe.git
cd fioul-groupe
git remote -v                  # origin → l'URL du dépôt distant

On ajoute un premier fichier, puis le cycle fondamental modifier → indexer → valider → pousser :

echo "# Fioul Groupé" >> README.md
git status                     # voir ce qui a changé
git add README.md              # indexer (staging)
git commit -m "docs: présentation du projet"
git push                       # envoyer vers origin

Commits propres & branches

Objectifs — écrire un historique lisible (commits atomiques, messages conventionnels), maîtriser .gitignore, et travailler sur des branches sans polluer main.

1 · Ignorer ce qui ne doit pas être versionné

On ne versionne jamais les fichiers générés, les dépendances ni les secrets. Le .gitignore les exclut :

# .gitignore (extraits)
target/            # build Maven
build/             # build Flutter/Gradle
.env               # variables secrètes
*.log
.idea/  .vscode/   # réglages d'IDE

2 · Des commits atomiques et bien nommés

Un commit = une intention. On adopte la convention Conventional Commits (utile pour la CI et les releases plus tard) :

git add src/model/Campagne.java
git commit -m "feat: ajoute le modèle Campagne"
# types courants : feat, fix, docs, refactor, test, chore
git log --oneline --graph       # visualiser l'historique

3 · Travailler sur une branche

main reste stable ; chaque fonctionnalité vit sur sa propre branche :

git switch -c feature/modele-campagne   # créer + basculer
# ... on code, on commit sur la branche ...
git push -u origin feature/modele-campagne  # publier la branche
git branch                              # lister les branches
git switch main                         # revenir sur main

Collaborer : Pull Requests, revue & conflits

Objectifs — intégrer le travail via des Pull Requests, faire une revue de code entre binômes, et résoudre un conflit de fusion.

1 · Ouvrir une Pull Request

2 · Faire une revue de code

3 · Récupérer et gérer un conflit

Après une fusion, chacun met à jour sa copie locale :

git switch main
git pull                     # récupérer main à jour
git switch feature/api
git merge main               # réintégrer main → conflit possible

Git marque les conflits dans le fichier :

<<<<<<< HEAD
prixLitre = 1.05;
=======
prixLitre = 0.98;
>>>>>>> main

On choisit la bonne version, on retire les marqueurs, puis :

git add <fichier>
git commit                   # valide la résolution

Piloter le projet : Issues, labels & Projects

Objectifs — transformer le cahier des charges du fioul en tâches suivies, et piloter l'avancement sur un tableau kanban relié au code.

1 · Écrire des issues à partir des user stories

2 · Le tableau de bord (Projects)

3 · Relier le code aux tâches

Dans un message de commit ou une PR, un mot-clé ferme l'issue automatiquement à la fusion :

git commit -m "feat: endpoint POST /commandes (closes #12)"

Protéger et cadrer la collaboration

Objectifs — empêcher les erreurs sur main, imposer la revue, et standardiser issues et PR avec des modèles.

1 · Protéger la branche main (ruleset)

2 · Désigner des responsables (CODEOWNERS)

Un fichier .github/CODEOWNERS demande automatiquement la revue des bonnes personnes :

# chemin           responsable
/api/            @binome-backend
/mobile/         @binome-mobile

3 · Modèles d'issue et de PR

Intégration continue avec GitHub Actions

Objectifs — automatiser build et tests à chaque push/PR, pour ne fusionner que du code qui compile et passe les tests.

1 · Comprendre un workflow

Un workflow est un fichier YAML dans .github/workflows/. Il définit des déclencheurs (on), des jobs et des steps. GitHub fournit les machines (runners).

2 · Workflow build + tests de l'API

.github/workflows/api.yml

name: CI API
on:
  push: { branches: [ main ] }
  pull_request:
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with: { java-version: '21', distribution: temurin, cache: maven }
      - run: mvn -B verify        # compile + tests

3 · Voir la CI agir

Déployer : GitHub Pages, secrets & releases

Objectifs — publier le site du cours en ligne, gérer les secrets proprement, et versionner des livrables avec les releases.

1 · Publier le portail sur GitHub Pages

2 · Gérer les secrets (jamais dans le code)

3 · Publier une release

Un tag marque une version ; la release l'accompagne d'une note et de fichiers (ex. l'APK Flutter) :

git tag -a v1.0.0 -m "Première version démo"
git push origin v1.0.0

Sécuriser, réparer & finaliser

Objectifs — durcir le dépôt, savoir revenir en arrière proprement, et livrer un projet documenté prêt pour la soutenance.

1 · Sécurité du dépôt

2 · Revenir en arrière sans casser l'historique

git revert <hash>      # annule un commit en créant un commit inverse (sûr, partagé)
git restore <fichier>  # annule des modifs non validées
git reset --soft HEAD~1 # défait le dernier commit local (avant push)

3 · Finaliser la documentation

• README complet : présentation, prérequis, comment lancer l'API et l'appli, URL Pages, badge CI, captures.
• Un Wiki ou un dossier /docs pour la doc détaillée.
• Vérifier licence, .gitignore, absence de secret dans l'historique.
• Board Projects entièrement en Done, milestones clôturés.