CONTRIBUTING.md (2566B)
1 1. К каждому PR должен быть issue. 2 В issue желательно обсудить что, как и зачем будет сделано, 3 особенно если это новый issue. 4 5 2. Прежде чем делать PR надо протестировать, что код работает, 6 причём в нескольких сценариях. 7 8 3. Также надо проверить, что в eslint не появилось новых предупреждений 9 в изменнённых частях кода. 10 11 4. Коммитов в PR должно быть минимальное количество, как правило один. 12 Если в рабочей ветке коммитов больше, надо их сребейзить прежде чем делать PR (см. п.10). 13 14 5. Все изменения в PR должны относиться только к решаемой задаче. 15 Например, не надо делать рефакторинг кода, 16 в который не вносятся функциональные изменения. 17 18 6. Если в PR есть слабо связанные изменения, но относящиеся к решаемой задаче, 19 их надо разделить на несколько коммитов, 20 например, если изменения можно применить по отдельности 21 без нарушения валидности кода и функциональности программы. 22 23 7. Во всех commit message в первой строке должна быть ссылка на issue (не на PR) 24 в виде #123 25 26 8. Если нужно сделать длиный commit-message, то 27 в первой строке надо написать краткое описание, оставить одну пустую строку, 28 затем написать остальной текст. 29 30 9. Изменения по ревью можно как делать новыми коммитами, так и добавлять в первый и пушить с форсом. 31 32 10. Перед мержем все коммиты необходимо склеить (кроме случая слабо связанных изменений) и отребейзить на master. 33 Коротко и по-русски: 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