# 📖 Protocole Git & Règles de Contribution

## 🌿 Gestion des Branches

Nous allons travailler sur des branches spécifiques pour chaque nouvelle fonctionnalité ou résolution de bug. **Il est impératif de toujours travailler sur SA branche**.

### Nomenclature
Le nom de la branche doit suivre ce format : `type/description`

- **Nouvelle fonctionnalité** : `feature/nom-fonctionnalite`
- **Résolution de bug** : `fix/le-nom-du-bug`

> [!CAUTION]
> **Il est strictement interdit** de créer des branches avec des noms vagues et incompréhensibles tels que `feature/fonctionnalite`, `fix/bug`, `fix/bug-du-turfu`, ou `feature/trop-bien`.
>
> ⚠️ **Attention :** Évitez les caractères spéciaux (`é`, `è`, `à`, etc.) et les espaces. Faites les séparations avec un trait d'union `-`.

✅ **Exemples de noms corrects :**
- `fix/mauvais-typage-controller`
- `fix/overflow-page-accueil`
- `feature/creation-utilisateur`

### Créer et changer de branche

Pour créer une nouvelle branche et basculer dessus immédiatement :
```bash
git switch -c type/description
```

*(Si `git switch` ne fonctionne pas sur votre version de Git, utilisez : `git branch type/description` suivi de `git checkout type/description`.)*

Pour vérifier la branche sur laquelle vous êtes (à faire **dès que vous commencez quelque chose**) :
```bash
git branch
```

### Travailler à plusieurs sur la même branche

Si vous êtes plusieurs à bosser sur la même branche, voici le flux de travail classique :

**Développeur 1 :**
```bash
git commit -m "feat(home): ajout navbar"
git push origin type/description
```

**Développeur 2 :**
```bash
git switch type/description  # S'il n'est pas encore sur la branche
git pull origin type/description
```

> [!IMPORTANT]
> **POUR TOUS LES CAS DE FIGURE :**
> Faites toujours un `git pull origin type/description` de façon régulière ou avant de modifier.  
> **➡️ Cela évite 90% des conflits !**

---

## 💾 Conventions des Commits

Il faut absolument éviter les messages de commit vagues comme : *"résolution de bug"*, *"j'ai refait le code"*.

Utilisez toujours la convention suivante :  
**`type(scope): description courte et claire`**

### Les principaux types autorisés sont :

- **`feat`** : ajout d'une nouvelle fonctionnalité
- **`fix`** : correction d'un bug
- **`hotfix`** : correction urgente d'un bug critique (à utiliser **uniquement** en cas d'urgence)
- **`refactor`** : modification du code sans impact sur le comportement utilisateur

✅ **Exemples de bons commits :**
- `feat(auth): ajout inscription utilisateur`
- `fix(home): correction overflow navbar mobile`
- `refactor(api): simplification logique controller user`
- `hotfix(db): correction crash lors de l'inscription`

---

## 🔀 Pull Requests et Fin de Fonctionnalité

Une fois que vous avez terminé de développer votre code sur votre branche :

1. **Poussez votre branche sur le dépôt distant** (si ce n'est pas déjà fait) :
   ```bash
   git push origin type/description
   ```

2. **Créez une Pull Request (PR)** *(ou Merge Request)* sur l'interface GitHub pour fusionner votre code vers la **branche principale** (souvent `main` ou `develop`).

3. **Une fois la PR validée et fusionnée**, pour commencer une nouvelle fonctionnalité, vous devez :
   - Revenir sur la branche principale
   - Récupérer le "nouveau" code à jour
   - Créer une nouvelle branche à partir de là

   ```bash
   git switch main          # ou develop
   git pull origin main     # récupérer le code à jour
   git switch -c feature/nouvelle-fonctionnalite
   ```