Bitbucket : structurer ses pull requests pour une revue de code efficace

La pull request est le point de contrôle le plus important du cycle de développement. Bien configurée dans Bitbucket, elle devient un processus fluide qui protège le code sans ralentir l’équipe.

Protections de branches : les gardes-fous

Configurez les protections de branches dans Repository Settings → Branch permissions :

Branche : main
- Interdire les push directs (tout passe par PR)
- Requérir 2 approbations minimum
- Requérir que les checks CI passent
- Interdire la suppression de la branche
- Interdire le rewrite d'historique (force push)

Ces règles s’appliquent même aux administrateurs du dépôt — personne ne peut contourner le processus.

Templates de pull request

Créez un fichier .bitbucket/pull_request_template.md à la racine du dépôt :

## Description
<!-- Décrivez le changement et pourquoi il est nécessaire -->

## Ticket Jira
<!-- PROJ-XXX -->

## Type de changement
- [ ] Bug fix
- [ ] Nouvelle fonctionnalité
- [ ] Changement cassant (breaking change)
- [ ] Refactoring

## Tests
- [ ] Tests unitaires ajoutés ou mis à jour
- [ ] Tests manuels effectués

## Checklist
- [ ] Le code respecte les conventions de l'équipe
- [ ] La documentation est mise à jour
- [ ] La Quality Gate SonarCloud passe

Chaque nouvelle PR est pré-remplie avec ce template — les auteurs ne peuvent pas oublier d’indiquer le ticket Jira ou les tests effectués.

Merge Checks : automatiser les contrôles

Au-delà des approbations humaines, Bitbucket peut imposer des conditions automatiques au merge :

Minimum approvals : nombre minimum d’approbateurs (ex : 2)
No unresolved tasks : toutes les tâches de revue doivent être fermées
No unresolved comments : tous les commentaires doivent être résolus ou marqués outdated
Successful builds : le pipeline CI doit passer en vert
Passing SonarCloud : la Quality Gate de SonarCloud doit être verte (si intégrée)

Ces checks s’affichent directement dans la PR et bloquent le bouton Merge tant qu’ils ne sont pas tous satisfaits.

Code Insights : enrichir la PR avec des données externes

L’API Code Insights permet d’intégrer des rapports tiers dans l’interface Bitbucket. SonarCloud, Snyk et d’autres outils s’en servent pour afficher leurs résultats directement dans la PR :

POST /rest/insights/1.0/projects/PROJ/repos/myapp/commits/{commitId}/reports/sonarcloud
{
  "title": "SonarCloud Analysis",
  "result": "PASS",
  "details": "Quality Gate passed. Coverage: 84%",
  "link": "https://sonarcloud.io/summary/..."
}

L’auteur de la PR voit le résultat SonarCloud dans Bitbucket sans changer d’onglet.

Diff stratégie : gérer les branches de longue durée

Pour les feature branches longues, deux stratégies coexistent dans Bitbucket :

Merge commit — préserve l’historique complet de la branche. Utile pour tracer l’historique de développement d’une fonctionnalité.

Squash merge — condense tous les commits en un seul sur main. Historique plus propre, mais perte du détail des commits intermédiaires.

Rebase and merge — rejoue les commits de la branche sur main. Historique linéaire sans commit de merge.

Le choix dépend de la politique de l’équipe. Ce qui compte, c’est d’avoir une politique cohérente et documentée.

Notre formation Bitbucket couvre en profondeur la configuration des branches et l’organisation des revues de code dans l’écosystème Atlassian.