Як підготувати свій pull request до рев'ю і як оновлювати його після коментарів?

Перший рецензент PR - його автор. Перегляд власного дифу на GitHub (а не в редакторі) за кілька хвилин знаходить те, на що інакше пішов би раунд рев'ю.

Чеклист перед запитом рев'ю:

• переглянути весь диф у вкладці Files changed - так, як побачить рецензент;
• прибрати dd(), dump(), console.log, закоментований код, випадкові файли;
• CI зелений, тести на нову поведінку є;
• опис оновлено: що, навіщо, як перевірити;
• залишити власні коментарі до неочевидних місць: «тут свідомо без транзакції, бо...» - це зменшує кількість запитань;
• PR не містить сторонніх змін, що потрапили «заодно».

Як оновлювати PR після коментарів:

• нові коміти, а не переписування історії під час рев'ю: рецензент бачить лише те, що змінилося з останнього перегляду. Після force push GitHub губить зв'язок частини коментарів з кодом, і доводиться переглядати все заново;
• fixup-коміти зручні, якщо історію треба буде впорядкувати перед злиттям:

git commit --fixup=a1b2c3d
# перед злиттям, коли рев'ю завершене:
git rebase -i --autosquash main

А якщо репозиторій вливає через squash - впорядковувати взагалі не потрібно;

• відповідати на кожен коментар: «виправлено в 4f2e1a0», «не згоден, бо...», «винесу в #430»;
• не закривати чужі обговорення без відповіді - рецензент має бачити, що його почули;
• повторно запросити рев'ю (Re-request review), коли все виправлено, - інакше рецензент не дізнається, що черга знову за ним.

Якщо коментарів дуже багато - часто це сигнал, що варто поговорити голосом чи переглянути підхід, а не виправляти по одному.

Докладніше в документації: GitHub: запит на рев'ю