-
К каждому PR должен быть issue. В issue желательно обсудить что, как и зачем будет сделано, особенно если это новый issue.
-
Прежде чем делать PR надо протестировать, что код работает, причём в нескольких сценариях.
-
Также надо проверить, что в eslint не появилось новых предупреждений в изменнённых частях кода.
-
Коммитов в PR должно быть минимальное количество, как правило один. Если в рабочей ветке коммитов больше, надо их сребейзить прежде чем делать PR (см. п.10).
-
Все изменения в PR должны относиться только к решаемой задаче. Например, не надо делать рефакторинг кода, в который не вносятся функциональные изменения.
-
Если в PR есть слабо связанные изменения, но относящиеся к решаемой задаче, их надо разделить на несколько коммитов, например, если изменения можно применить по отдельности без нарушения валидности кода и функциональности программы.
-
Во всех commit message в первой строке должна быть ссылка на issue (не на PR) в виде #123
-
Если нужно сделать длиный commit-message, то в первой строке надо написать краткое описание, оставить одну пустую строку, затем написать остальной текст.
-
Изменения по ревью можно как делать новыми коммитами, так и добавлять в первый и пушить с форсом.
-
Перед мержем все коммиты необходимо склеить (кроме случая слабо связанных изменений) и отребейзить на master. Коротко и по-русски: https://htmlacademy.ru/blog/27-how-to-squash-commits-and-why-it-is-needed, подробно: https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#_changing_multiple