4. Github Setup

Un projet professionnel nécessite une configuration GitHub solide pour :

• Faciliter la collaboration en équipe
• Maintenir la qualité du code
• Standardiser les processus
• Protéger le code de production
• Automatiser les workflows

Sans configuration, n'importe qui peut merger du code non testé directement sur main, créer des branches anarchiques, ou pousser des commits non conformes.

Vérifier la qualité du code

npm run check

Structure des commits

Suivez la convention Conventional Commits :

• feat: : Nouvelle fonctionnalité
• fix: : Correction de bug
• docs: : Documentation
• refactor: : Refactorisation
• test: : Tests
• chore: : Tâches diverses

Exemple :

feat(auth): add JWT authentication
fix(user): resolve email validation bug
docs(readme): update installation steps

Code Review

Toute PR doit :

• Passer les tests CI
• Être revue par au moins 1 personne
• Respecter les standards de code
• Avoir une description claire

5. LICENSE

Choisissez une licence (MIT recommandée pour open-source) :

MIT License

Copyright (c) 2024 Votre Nom

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction...

Ou créez-la depuis GitHub : Add file → Create new file → Nommez-le LICENSE → GitHub propose des templates.

Templates GitHub

Template de Pull Request

Créez .github/PULL_REQUEST_TEMPLATE.md :

## Description

<!-- Décrivez les changements de cette PR -->

## Type de changement

<!-- Cochez les cases appropriées -->

- [ ] 🐛 Bug fix
- [ ] ✨ Nouvelle fonctionnalité
- [ ] 💥 Breaking change
- [ ] 📝 Documentation
- [ ] ♻️ Refactorisation
- [ ] ♻️ Tests

## Checklist

- [ ] Mon code respecte les guidelines du projet
- [ ] J'ai testé mes modifications localement
- [ ] J'ai ajouté des tests pour mes changements
- [ ] La documentation a été mise à jour si nécessaire
- [ ] Tous les tests passent (`npm test`)
- [ ] Le linting passe (`npm run lint`)
- [ ] J'ai suivi la convention Conventional Commits

## Tests effectués

<!-- Décrivez comment vous avez testé vos changements -->

## Screenshots (si applicable)

<!-- Ajoutez des captures d'écran si nécessaire -->

## Issues liées

<!-- Mentionnez les issues : Closes #123, Fixes #456 -->

Template d'Issue

Créez .github/ISSUE_TEMPLATE/bug_report.md :

---
name: Bug Report
about: Signaler un bug
title: '[BUG] '
labels: bug
assignees: ''
---

## Description du bug

<!-- Description claire et concise du bug -->

## Étapes pour reproduire

1. Aller sur '...'
2. Cliquer sur '...'
3. Voir l'erreur

## Comportement attendu

<!-- Qu'est-ce qui devrait se passer ? -->

## Comportement actuel

<!-- Qu'est-ce qui se passe actuellement ? -->

## Screenshots

<!-- Si applicable, ajoutez des screenshots -->

## Environnement

- OS: [e.g. macOS, Windows, Linux]
- Node.js: [e.g. 20.11.0]
- npm: [e.g. 10.2.4]

## Informations supplémentaires

<!-- Tout contexte additionnel -->

Créez .github/ISSUE_TEMPLATE/feature_request.md :

---
name: Feature Request
about: Proposer une nouvelle fonctionnalité
title: '[FEATURE] '
labels: enhancement
assignees: ''
---

## Problème à résoudre

<!-- Décrivez le problème que cette feature résoudrait -->

## Solution proposée

<!-- Décrivez la solution que vous envisagez -->

## Alternatives considérées

<!-- Avez-vous pensé à d'autres solutions ? -->

## Informations supplémentaires

<!-- Contexte additionnel, mockups, etc. -->

CODEOWNERS

Le fichier CODEOWNERS définit qui doit reviewer certaines parties du code.

Créez .github/CODEOWNERS :

# Propriétaires par défaut
* @votre-username

# Backend
/src/controllers/ @backend-team
/src/services/ @backend-team

# Database
/prisma/ @database-team
*.prisma @database-team

# CI/CD
/.github/workflows/ @devops-team

# Documentation
*.md @doc-team

Avantage : Les bonnes personnes sont automatiquement assignées aux revues de code.

Branch Protection Rules

Les branch protection rules empêchent les erreurs sur les branches importantes.

Configuration pour main

1. Settings → Branches → Add rule
2. Branch name pattern : main
3. Cochez les options suivantes :

Require a pull request before merging

• Require approvals : 1 (au moins une revue)
• Dismiss stale pull request approvals when new commits are pushed : OK
• Require review from Code Owners : OK

Require status checks to pass before merging

• Require branches to be up to date before merging : OK
• Sélectionnez les checks : Test and Lint (votre workflow CI)

Require conversation resolution before merging

Tous les commentaires doivent être résolus.

Require signed commits (optionnel mais recommandé)

Force les commits signés GPG pour plus de sécurité.

Include administrators

Les règles s'appliquent même aux admins.

Résultat

Impossible de :

• Pusher directement sur main
• Merger une PR sans revue
• Merger si les tests échouent
• Merger avec des commentaires non résolus

Structure des branches

Adoptez une convention de nommage pour les branches :

feat/nom-de-la-feature        # Nouvelle fonctionnalité
fix/nom-du-bug                # Correction de bug
refactor/nom-du-refactor      # Refactorisation
docs/nom-de-la-doc            # Documentation
test/nom-du-test              # Tests
chore/nom-de-la-tache         # Tâches diverses

Exemples :

git checkout -b feat/user-authentication
git checkout -b fix/login-validation-error
git checkout -b docs/update-readme

Secrets et Variables

Pour GitHub Actions et le déploiement, configurez les secrets :

1. Settings → Secrets and variables → Actions
2. New repository secret

Secrets à ajouter :

Nom	Description
JWT_SECRET	Clé secrète JWT
DATABASE_URL	URL de la base de données de test

Variables d'environnement (non sensibles) :

1. Settings → Secrets and variables → Actions → Variables
2. New repository variable

Nom	Valeur
NODE_ENV	production
PORT	3000