Велика фіча, 12 штук PR в стаку, де кожен ґіт бранч залежить від попереднього, один за одним. Рев'ювер просить змінити перший. Фіксиш, робиш push with lease.

Всі наступні PR тепер базуються на коді ДО цієї зміни. Треба зробити rebase в #2, потім #3-й ... #12. Конфлікти вилізають в кожному, бо є спільні файли в які вносилися зміни в різних PR.

Чим більше PR в ланцюжку, тим дорожче мейнтейнити. Ефект доміно, тільки з merge конфліктами.

Складність = O(кількість PR × конфліктні комміти).

Як виглядає процес:

# фікс в одному з перших PR
git checkout pr1
# фікси
git commit ...
git push --force-with-lease

# rebase наступний PR
git checkout pr2
git fetch origin
git rebase origin/pr1
# резолвимо конфлікти
git rebase --continue
git push --force-with-lease

# rebase наступний PR
git checkout pr3
git rebase origin/pr2
# резолвимо конфлікти
git rebase --continue
git push --force-with-lease

...

(і так 12 разів)

Типова послідовність коли щось потрібно інвестіґейтити:

git status
git diff --name-only --diff-filter=U

git checkout --ours <file> # ours це у найкращому сценарії - найлегший фікс
git add <file>

git rebase --continue # це для кожного коміту в PR, поки не залишиться конфліктів

Валідація перед тим як пушити:

python3 -m compileall path1/src
python3 -m compileall path2/tests/unit
pytest path2/tests/unit -q

Ментальна модель:

зміна в PR1
  ↓
rebase PR2
  ↓
rebase PR3
  ↓
rebase PR4
  ↓
...
rebase PR12
force-push кожен бранч.

(процес дуже на любителя, особисто не раджу).

----

Висновок: просити рев'ювати із change request лише в останньому PR.

Написано на підставі гіркого досвіду.