Практически в каждом проекте к которому я присоединялся, старый или новый, в любом случае договоренности по git либо были, но им мало кто следовал или описывались с нуля.

Поэтому решил, написать шаблон по договоренностям работы с git, который можно переиспользовать/адаптировать в зависимости от потребности/правил в компании и проекте.

Правила работы с git

Каждая новая задача делается в рамках отдельной ветки (branch). При разработке всегда создаём бранч от master ветки (push напрямую в master запрещён).

Соглашение о наименовании бранчей:

Наименование бранчей: <номер задачи в task tracker>_<описание опиционально>

Например: JIRA-1010_dag_payments или просто JIRA-1010

Каждое изменение проводим через dev, затем через механизм Code Review (Pull request/Merge request) осуществляем merge в master.

Code review - обязателен!!!

Наименование коммитов и общие рекомендации:

1. Все коммиты пишутся на английском языке
2. Все коммиты должны иметь следующий формат <номер задачи> <глагол> <субъект> <детали> . Пример: JIRA-1010 Add dag for prosessing payments
3. Опционально: писать подробности коммита в произвольной форме отступив 1 строку от заголовка.
4. Недопустимо делать подряд несколько коммитов с одинаковой подписью. Исключение: на своём бранче в разработке и squash перед merge в master.
5. В коммитах необходимо использовать термины из словаря проекта.
6. Название коммита должно показывать бизнес изменения, если они были, а не изменения в кодовой базе.

Pull requests

Внесение всех изменений в стабильные ветви репозитория осуществляются через pull request’ы.

С целью обмена опытом в команде, предотвращения слияния ошибочных изменений, выявления ошибок, нарушений стилей кодирования, все PRs проходят обязательную проверку Code Review.

Правила проведения Code Review

1. Проверяется только область с непосредственными изменениями, изменения вне области изменяемого кода проверять не рекомендуется, за исключением случаев, когда изменения вне изменяемой области критичны в рамках выполняемых работ. Данное правило ведено с целью повышения скорости принятия изменений, предотвращения затягивания процесса реализации работ.
2. Все предложения, замечания, комментарии должны быть понятны. Запрещены оскорбительные высказывания, неконструктивная критика в адрес коммитера. Все предложения и замечания должны относиться только к коду и нести конструктивный характер.
3. При наличии замечаний и предложений, ревьюер может отправлять изменения на доработку. При этом в PR должна присутствовать содержательная часть предложений и замечаний.
4. При слиянии проверяется наличие неразрешенных замечаний (не находящихся в статусе Closed) и дополнительных проверок CI если есть. При их наличии изменения отправляются на доработку.

После проведения всех проверок необходимо слить изменения (Merge and squash) и удалить слитую ветвь с сервера.

Если что, этот шаблон возможно поможет кому-то быстро внедрить правила в команде.

Планирую улучшать его по мере накопления кейсов.