Créer une pull request

VérifiéSûr

Workflow concis pour préparer une branche, compiler, tester, pousser et ouvrir une pull request avec Gradle.

Spar Skills Guide Bot
DeveloppementDébutant
0018/10/2026
Claude CodeCursorCodex
#git-workflow#pull-request#gradle#commit-conventions#branching

Recommandé pour

Notre avis

Ce skill décrit une procédure en sept étapes pour préparer et ouvrir une pull request sur un projet Gradle, en vérifiant le build et les tests avant de committer.

Points forts

  • Séquence ordonnée et facile à suivre, de la création de branche à l'URL de la PR
  • Garde-fou explicite : ne commite qu'après la réussite de ./gradlew build et ./gradlew test
  • Impose un message de commit conventionnel et une PR avec titre et corps descriptifs
  • Précise de ne pas travailler directement sur main/develop

Limites

  • Les commandes sont spécifiques à Gradle ; il faut adapter l'outil de build pour d'autres écosystèmes
  • Ne détaille pas la création de la PR (outil utilisé, remote, authentification) ni la gestion des conflits
  • Aucune convention de nommage de branche ni de format de message n'est fournie
Quand l'utiliser

À utiliser lorsqu'un ensemble de modifications est prêt et qu'il faut le livrer proprement via une branche et une pull request sur un projet Gradle.

Quand l'éviter

À éviter sur un projet non-Gradle ou lorsque la PR doit être créée selon un processus interne très spécifique non décrit ici.

Analyse de sécurité

Sûr
Score qualité78/100

The skill describes a standard development workflow: creating a branch, running Gradle build and tests, committing, pushing, and opening a PR. It does not instruct destructive actions, data exfiltration, or bypassing safety mechanisms. Running build and test commands is a routine, legitimate activity.

Aucun point d'attention détecté

Exemples

Open a PR for finished work
My changes are done — create a feature branch if needed, run the build and tests, commit with a conventional message, and open a pull request with a summary.
Ship a bug fix properly
Commit this bug fix on a fix branch, make sure ./gradlew build and ./gradlew test pass first, then push and open a PR for review.
Turn local edits into a pull request
I've made edits on main by mistake — move them to a feature branch, verify the Gradle build and tests, and raise the PR with a descriptive title and body.

Create PR Workflow

  1. Ensure all changes are on a feature/fix branch (create one if on main/develop)
  2. Run the build: ./gradlew build
  3. Run tests: ./gradlew test
  4. If build+tests pass, commit with a conventional commit message
  5. Push the branch
  6. Create a PR with a descriptive title and body summarizing changes
  7. Report the PR URL
Skills similaires