ЯрГУ им. П.Г.Демидова

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

Идея

Частично идея была позаимствована от GitFlow и TensorFlow (стандарт работы с git в компании Tensor)

Главные ветки

• master
• rc-{номер версии} (можно так же обозначать, как rc-*)

По-умолчанию Git создает 1 основную ветку - master. Она будет являться веткой с последним релизным состоянием.

Ветки с названием rc-{номер версии} создаются накануне релиза или незадолго до него, планово. Называться может, например, rc-1.0.2.

Все релизные ветки rc-* в конечном итоге при релизе конкретной версии сливаются в master.

Принципы работы

Ветки master должны быть заблокированы от прямого пуша в них, по крайней мере разрешить можно это делать нескольким избранным людям для каких-то срочных исправлений косяков.

Для выполнения какого-либо задания обычно следует ответвиться от ветки rc-* в новую ветку, название которой должно соответствовать следующему формату:

тип-ветки/тип-изменения/в-двух-словах-что-тут-делалось/и-еще-какая-нибудь-информация/ещё-что-нибудь

Где тип-ветки:

• m если ответвляемся от master
• {номер версии}, если ответвляемся от rc-*. Например, может быть 1.0.2

Где тип-изменения может быть:

• bugfix - при исправлениях каких-либо ошибок
• hotfix - срочное исправление, обычно попадает в rc-*
• feature - при создании нового функционала

Примеры правильных названий веток

• 1.0.3/feature/improved-sidebar
• m/hotfix/maa/fix-wrong-template-name

Тут maa - это инициалы человека, создавшего ветку и ведущего в ней разработку. Формат простой: ФИО.

Этапы ведения репозитория

• Сразу после создания репозитория необходимо создать от master ветку rc-* с какой-то начальной версией, например, 1.0.0.
• Если принята дата, к которой надо выпустить какие-то исправления или новый функционал, то необходимо:
  • Создать соответствующий milestone на github с необходимой версией по формату rc-* (например, rc-1.0.1)
  • Создать ветку rc-* с соответствующей версией от предыдущей rc-* (например, текущая rc-1.0.0, тогда новая будет rc-1.0.1). (Фиксация версии)
• Вести разработку в соответвующих ветках.
  • Если есть rc-* ветка, в которую вносятся изменения, то мёржить свои ветки надо не только в rc-*, но и в вышестоящие релизы, если они зафиксированы. Например:
    • Есть 2 релиза: rc-1.0.1, rc-1.0.2. Задачу надо закрыть в rc-1.0.1. В этом случае создается ветка от rc-1.0.1, например, 1.0.1/bugfix/maa/my-fix. После завершения разработки по данной задаче создаются Pull Request (Merge Request) в ветки rc-1.0.1, rc-1.0.2.
    • Если есть 3 релиза, то мёржи делаются во все эти версии. Ну и так далее.
  • Если задача стоит в релиз, который еще не зафиксирован, то следует согласовать перенос задачи/ошибки в версию, которая уже зафиксирована или попросить создать ветку для этой версии
  • Ветки rc-* при релизе мёржатся в master.

Дополнительная информация

Разделители слов в названии ветки могут быть:

• символ нижнего подчеркивания (_)
• тире (он же минус, -)