A PR végterméke az, hogy az egész gondolatmenet, aprólékosan, fokozatosan felépítve, megmarad a commit history-ban.
De hát ez csak annyit jelent, hogy a PR egy külön branch, aminek ott a commit historyja. És merge után nem törlöd ki a branchet. Ennyi az egész, megmarad az egész gondolatmeneted.
Ha van egy hiba a kódban, amely egy olyan téves elgondolásból származik, amely a patch set közepét érinti,
Nincs ilyen, hogy a patch set közepe. Maximum az, hogy a PR-ban többféle funkcionalitás van, amelyek a PR-on belül külön életet élnek.
Csinálhatod azt, hogy van egy PR branched, és ebből a PR branchből te még ágaztatsz le "patch" brancheket, amiket a PR branchbe mergelsz be, amikor az a rész készen van és már nincs benne hiba.
Szóval valahogy így:
1. mastert leágaztatod a PR-odhoz, legyen a neve pr-foo
2. A PR-ban, mivel több patched is van (patch set), minden egyes patchhez létrehozol egy branchet. Azt a branchet reviewzod, commitolsz oda, hívhatod ezeket a brancheket úgy, hogy pr-foo-patch-bar
3. Ezeket a pr-foo-patch-x brancheket mergeled folyamatosan a pr-foo branchbe. Megmarad minden kommit a pr-foo-patch-x brancheken is.
4. Amint a PR branchbe minden patch branch bekerült, akkor a PR branch bekerülhet a masterbe.
A reviewerek mindig megnézhetik a pr-foo-patch-x brancheket, és reviewzhatják azt.
Az egész csak annyit jelent, hogy a fejlesztés során hány különálló életet kódrészed van, mindegyik megérdemel egy branchet. Az, hogy ez a branch miből származik (a masterből, PR branchből, vagy éppen a patch branchből is - ha esetleg szükség van rá), az a fejlesztői folyamat része.
De git szintjén csak branchek kellenek és kész. És semmilyen historyt nem kell újraírni, soha.