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

Votre premier conflit de merge

Un conflit n'est pas une erreur. C'est git qui refuse de deviner entre deux vérités — la vôtre et celle de main — et demande à un humain de décider.

Par Shahriyar · Mis à jour

Pourquoi ça arrive

Pendant que vous travailliez sur votre branche, quelqu'un a changé les mêmes lignes sur main. Git peut merger des changements à des endroits différents silencieusement ; le même endroit a besoin de vous.

▸ What a conflict actually looks like
<<<<<<< HEAD
  await page.click("#place-order");
=======
  await page.getByRole("button", { name: "Place order" }).click();
>>>>>>> main

# resolve: keep one (or combine), DELETE the marker lines, then
git add checkout.spec.js
git rebase --continue   # or: git commit, if you were merging

Rebase vs merge — pourquoi les équipes débattent

Merge garde l'historique tel qu'il s'est passé, avec des commits de merge en plus. Rebase rejoue vos commits par-dessus main — linéaire et propre, mais ça réécrit votre branche. Les deux sont corrects ; les équipes en choisissent un. Demander « on rebase ou on merge ici ? » dès le premier jour se lit comme de l'expérience, pas de l'ignorance.

Basé sur la documentation git sur le merge et le rebase

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