Pr Create

Créer automatiquement une PR

Crée automatiquement des Pull Requests en analysant vos modifications Git pour un flux de travail plus fluide.

Utilisation

# Créer automatiquement une PR à partir de vos modifications
git add . && git commit -m "feat: Implement user authentication"
"Create a Draft PR with the right description and labels"

# Conserver votre modèle existant
cp .github/PULL_REQUEST_TEMPLATE.md pr_body.md
"Fill in the blanks but keep the template structure intact"

# Marquer comme prêt une fois terminé
gh pr ready
"Switch to Ready for Review after checking quality"

Exemples de base

# 1. Créer une branche et committer
git checkout main && git pull
git checkout -b feat-user-profile
git add . && git commit -m "feat: Implement user profile feature"
git push -u origin feat-user-profile

# 2. Créer la PR
"Please create a PR:
1. Check what changed with git diff --cached
2. Use the PR template from .github/PULL_REQUEST_TEMPLATE.md
3. Pick up to 3 labels that match the changes
4. Create it as a Draft (keep HTML comments)"

# 3. La marquer comme prête après passage de la CI
"Once CI is green, mark the PR as Ready for Review"

Étapes d'exécution

1. Créer une branche

# Nomenclature des branches : {type}-{subject}
git checkout main
git pull
git checkout -b feat-user-authentication

# Confirmer que vous êtes sur la bonne branche
git branch --show-current

2. Committer

# Préparer vos modifications
git add .

# Committer avec un message clair
git commit -m "feat: Implement user authentication API"

3. Pousser vers le distant

# Premier push (définit l'upstream)
git push -u origin feat-user-authentication

# Pushs suivants
git push

4. Créer un brouillon de PR avec analyse automatique

Étape 1 : Analyser les modifications

# Voir quels fichiers ont changé
git diff --cached --name-only

# Examiner les modifications réelles (premières 1000 lignes)
git diff --cached | head -1000

Étape 2 : Générer automatiquement la description

# Priorité des modèles :
# 1. Conserver la description PR existante telle quelle
# 2. Utiliser .github/PULL_REQUEST_TEMPLATE.md
# 3. Se rabattre sur le modèle par défaut

cp .github/PULL_REQUEST_TEMPLATE.md pr_body.md
# Remplir seulement les sections vides - ne pas toucher aux commentaires HTML ou séparateurs

Étape 3 : Sélectionner automatiquement les labels

# Obtenir les labels disponibles (non interactif)
"Retrieve available labels from .github/labels.yml or GitHub repository and automatically select appropriate labels based on changes"

# Sélection automatique par correspondance de motifs (max 3)
# - Documentation : *.md, docs/ → documentation|docs
# - Tests : test, spec → test|testing
# - Corrections de bugs : fix|bug → bug|fix
# - Nouvelles fonctionnalités : feat|feature → feature|enhancement

Étape 4 : Créer la PR via l'API GitHub (Préserver les commentaires HTML)

# Créer la PR
"Create a Draft PR with the following information:
- Title: Auto-generated from commit message
- Description: Properly filled using .github/PULL_REQUEST_TEMPLATE.md
- Labels: Auto-selected from changes (max 3)
- Base branch: main
- Preserve all HTML comments"

Méthode B : GitHub MCP (Solution de secours)

// Créer une PR en préservant les commentaires HTML
mcp__github__create_pull_request({
  owner: "organization",
  repo: "repository",
  base: "main",
  head: "feat-user-authentication",
  title: "feat: Implement user authentication",
  body: prBodyContent, // Contenu complet incluant les commentaires HTML
  draft: true,
  maintainer_can_modify: true,
});

Système de sélection automatique de labels

Détermination à partir des motifs de fichiers

• Documentation : *.md, README, docs/ → documentation|docs|doc
• Tests : test, spec → test|testing
• CI/CD : .github/, *.yml, Dockerfile → ci|build|infra|ops
• Dépendances : package.json, pubspec.yaml → dependencies|deps

Détermination à partir du contenu

• Corrections de bugs : fix|bug|error|crash|repair → bug|fix
• Nouvelles fonctionnalités : feat|feature|add|implement|new-feature|implementation → feature|enhancement|feat
• Refactorisation : refactor|clean|restructure → refactor|cleanup|clean
• Performance : performance|perf|optimize → performance|perf
• Sécurité : security|secure → security

Contraintes

• Max 3 labels : Limite supérieure pour la sélection automatique
• Labels existants uniquement : Interdit de créer de nouveaux labels
• Correspondance partielle : Déterminée par l'inclusion de mots-clés dans les noms de labels

Directives du projet

Approche de base

1. Toujours commencer en brouillon : Toutes les PR doivent être créées à l'état Draft
2. Amélioration progressive de la qualité : Phase 1 (Implémentation de base) → Phase 2 (Ajouter des tests) → Phase 3 (Mettre à jour la documentation)
3. Labels appropriés : Toujours ajouter jusqu'à 3 labels
4. Utiliser les modèles : Toujours utiliser .github/PULL_REQUEST_TEMPLATE.md
5. Espacement japonais : Toujours ajouter un espace demi-chasse entre le texte japonais et les alphanumériques

Convention de nomenclature des branches

{type}-{subject}

Exemples :
- feat-user-profile
- fix-login-error
- refactor-api-client

Messages de commit

{type}: {description}

Exemples :
- feat: Implement user authentication API
- fix: Correct login error
- docs: Update README

Système de traitement des modèles

Priorité de traitement

1. Description PR existante : Conserver tout ce qui est déjà écrit
2. Modèle du projet : Utiliser .github/PULL_REQUEST_TEMPLATE.md
3. Modèle par défaut : Utiliser ceci si rien d'autre n'existe

Règles de préservation du contenu existant

• Ne pas toucher au contenu existant : Laisser ce qui est déjà là tel quel
• Remplir seulement les blancs : Ajouter du contenu seulement là où il manque
• Conserver les commentaires fonctionnels : Comme <!-- Copilot review rule -->
• Conserver les commentaires HTML : Tous les <!-- ... --> restent tels quels
• Conserver les séparateurs : Les éléments comme --- restent en place

Gestion de la préservation des commentaires HTML

Attention : GitHub CLI (gh pr edit) échappe les commentaires HTML, et le traitement du shell peut créer des problèmes avec des chaînes comme EOF < /dev/null.

Comment corriger ceci :

1. Utiliser l'option --field de l'API GitHub : Ceci gère l'échappement correctement
2. Rester simple : Éviter les pipes et redirections complexes
3. Ne rien supprimer : Conserver tous les commentaires HTML et modèles intacts

Réponses aux commentaires de revue

# Committer vos corrections
git add .
git commit -m "fix: Address review feedback"
git push

Notes

Importance de la préservation des commentaires HTML

• Problème GitHub CLI : gh pr edit échappe les commentaires HTML et peut casser les choses
• La solution : Utiliser l'option --field de l'API GitHub pour une gestion appropriée
• Tout conserver : Ne pas supprimer les commentaires HTML - conserver tout le modèle

Contraintes d'automatisation

• Pas de nouveaux labels : Ne peut utiliser que les labels de .github/labels.yml
• 3 labels max : C'est la limite pour la sélection automatique
• Ne pas toucher au contenu manuel : Ne jamais changer ce que quelqu'un a écrit

Qualité étape par étape

• Commencer avec brouillon : Chaque PR commence comme brouillon
• Vérifier la CI : Exécuter gh pr checks pour voir le statut
• Marquer comme prêt : Utiliser gh pr ready quand la qualité semble bonne
• Suivre le modèle : S'en tenir à la structure de votre projet