Travailler comme un ingénieur : Git, PRs & revue de code · Leçon 1 sur 6 · Module bonus

La boucle : branche, commit, PR, merge

Le code ne va pas de votre portable à la production. Il passe par une boucle que chaque entreprise exécute. Apprenez-la une fois et chaque équipe semble familière.

Par Shahriyar · Mis à jour

La boucle, du début à la fin

  1. Mettez main à jour, puis branchez depuis elle — nommée pour le travail, pas pour vous.
  2. Petits commits au fur et à mesure. Chacun une étape qui a du sens en soi.
  3. Poussez et ouvrez une PR. La description dit ce qui a changé et pourquoi.
  4. La revue arrive. Des commentaires, peut-être « changements demandés ». Vous répondez et re-poussez.
  5. Approbation → merge (souvent squashé en un seul commit) → la branche est supprimée.
▸ The whole loop in commands
git checkout main && git pull
git checkout -b test/checkout-smoke
# ...work...
git add -p                        # stage in reviewable pieces
git commit -m "Add smoke tests for guest checkout"
git push -u origin test/checkout-smoke
# then open the PR in the browser

Qui approuve, et ce qui bloque

Sur un vrai repo le bouton de merge est verrouillé jusqu'à ce que les règles passent : une ou deux approbations, et la CI verte. Personne ne merge par permission de politesse — la protection de branche fait respecter ça. C'est pourquoi un pipeline rouge sur votre PR est l'affaire de tous.

Basé sur la documentation git et le flux de pull request de GitHub

Toutes les leçons de Travailler comme un ingénieur : Git, PRs & revue de code

  1. La boucle : branche, commit, PR, merge
  2. Votre premier conflit de merge
  3. Lire du code que vous n'avez pas écrit
  4. Recevoir une revue sans le prendre personnellement
  5. Donner une revue en tant que personne qualité
  6. Des commits et PRs qu'un examinateur lira