git_commit_rules.txt

Git: Оформление коммитов и работа с ветками
================================================================================

 1. Коммиты
 ----------
    1.1 Коммиты должны быть атомарными и НЕБОЛЬШИМИ, т.е. одна логическая правка - один коммит.
        Все рефакторинги, переименования и пр. параллельные усовершенствования лучше оформлять отдельным коммитом.
        Ориентироваться надо на других разработчиков, которые будут просматривать эти коммиты.

    1.2 Все форматирование кода, приведение к стандарту оформлять ОТДЕЛЬНЫМ коммитом.

    1.3 Каждую миграцию структуры БД или редактирование миграции оформлять ОТДЕЛЬНЫМ коммитом.
        Чтобы иметь возможность объединить несколько коммитов по одной миграции.

    1.4 Для Git принято соглашение в первой строке сообщения писать краткое описание,
        а ЧЕРЕЗ строку - подробное. Т.е. как почтовое сообщение - заголовок и тело.
        В заголовок комментария надо обязательно включать номер тикета и тему/компонент,
        к которому он относится.
        Например:
            ----------------------
            t565 Календарь: Ошибка при добавлении периодической операции

            После добавления операции выдаётся ошибка что незаполнена категория,
            но при этом не даёт изменить её. Была проблема в формировании ответа
            json на сервере.
            ----------------------

    1.5 Для подготовки коммита НАДО использовать:
            git add -p
        Чтобы контролировать каждую правку, которая попадет в коммит.

    1.6 Перед кажым коммитом смотреть дифф будущего коммита:
            git diff --cached


 2. Ветки
 --------
    2.1 Под каждую задачу создается отдельная ветка и туда отправляются все коммиты по задаче.

    2.2 В названии ветки указывать тикет и 1-2 слова-описания: t69-profile-email

    2.3 Если работа над веткой продолжается дольше чем один день. Тогда подтягиваем
        ветку каждый день перед началом работы и после окончания, чтобы не накапливать конфликты.
        Если коммитов очень много, тогда лучше регулярно мерджить правки из основной ветки.
        Но лучше до такого не доводить и дробить задачи или объединять технические коммиты.

    2.4 Чтобы опубливать ветку для ревью или демонстрации, ее надо подтянуть к родительской:

            # Убедиться, что родительская ветка в актуальном состоянии:
            git fetch
            git co master
            git merge origin/master

            # Подтянуть ветку, если отстала
            git co my-branch
            git rebase master

            # Отправить в remote
            git push origin my-branch

    2.5 Перед тем как опубликовать ветку - посмореть полный диф всех правок:
            git diff НАЧАЛЬНЫЙ_КОММИТ..НАЗВАНИЕ_ВЕТКИ