Эффективный GitFlow на проектах

Модель ветвления в git

Основной принцип

В новом репозитории автоматически создается ветка master. В ней фиксируется протестированная и прорецензированная разработка в состоянии, готовом для передачи клиенту.

Разработка ведется в рамках ветки dev, которую разработчик создаёт от ветки master после настройки репозиториев и импорта базовых решений. Она предназначена для фиксации прорецензированной разработки в состоянии, готовом для передачи в тестирование.

От dev создаются временные ветки для фич. После того, как фича прорецензирована, временная ветка фичи объединяется с исходной веткой.

Ниже представлена визуальная схема ветвления.

Рекомендация по передачи разработки заказчику

К моменту передачи разработки заказчику необходимо

1. Поставить метку с номером версии на последний коммит в master.
2. Сформировать пакет для передачи заказчику.
3. Сделать коммит и отправить изменения номера билда после формирования пакета в master.

Рекомендация по обновлению на новую версию

Перед обновлением на новую версию необходимо создать ветку для бэкапа состояния заказной разработки до обновления. Название ветки – номер версии до обновления.

Обновление осуществляетcя в ветке master.

В заказной разработке после успешного обновления клиентов ветки предыдущих версий могут удаляться.

Основы работы с git на примере GitExtensions

GitExtensions – одна из GUI-утилит для работы с git-репозиториями. Доступна для скачивания с GitHub. Справка доступна по адресу http://git-extensions-documentation.readthedocs.io/en/latest/.

Получение изменений с сервера

Нажать на кнопку pull (выделена красным). Так же pull можно сделать через меню: Commands -> Pull… или  горячими клавишами Ctrl-вниз.

В открывшемся окне в разделе Merge options доступны следующие варианты:

Merge – получает изменения с сервера в текущую ветку и при наличии локальных изменений создает merge-commit. Эту опцию в повседневной работе не используем, т.к. после нее история репозитория становится ветвистой и неудобной для восприятия.

Rebase – получает изменения с сервера в текущую ветку, а коммиты, которые были сделаны локально, пытается воспроизвести на новой версии исходников, полученных с сервера, таким образом история остается линейной и удобна для просмотра. Это основной режим, который мы используем для обновления исходников.

Fetch – позволяет получить изменения с сервера, но не применять их к рабочей папке. Эти изменения мы увидим только в истории репозитория.

Сохранение изменений

После внесения изменений в исходный код необходимо эти изменения сохранить в репозиторий. Для этого нажать кнопку Commit.

Индексирование файлов

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

Выполнение commit-а

Далее необходимо написать сообщение к коммиту. 

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

Отправка изменений на сервер

Подготовка перед отправкой

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

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

Схлапывание коммитов

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

Существует несколько методов схлапывания. Выбирать конкретный метод стоит исходя из ситуации. Например, если ведется одновременная разработка клиента и сервера, и нужно схлопнуть коммиты по областям – отдельно серверные изменения, отдельно клиентские, то стоит воспользоваться методом схлапывания через reset.

Если нужно схлопнуть конкретные коммиты в несколько, то лучше воспользоваться интерактивным режимом rebase’а.

Схлапывание через reset

По истории репозитория ищем коммит, после которого расходится история локальной ветки и удаленной (в которую должны попасть изменения). Далее нажать ПКМ на этот коммит и выбрать пункт Reset current branch to here.

В открывшемся окне поставить опцию reset type в soft, которая поставит указатель текущей ветки в указанный коммит. После чего все изменения всех файлов из локальных коммитов попадут одним плоским списком в индекс, и их останется только закоммитить и сделать rebase на нужную ветвь.

Push изменений

Перед отправкой своих изменений на сервер необходимо предварительно получить свежие изменения с сервера. В противном случае при попытке отправки будет выведен диалог запроса на получение изменений, в котором необходимо ответить “pull with rebase”.

После получения всех изменений с сервера и решения конфликтов (если они получились), нужно нажать на кнопку push (выделена красным). Так же push можно сделать через меню Commands > Push… или горячими клавишами Ctrl-вверх.

В открывшемся окне убедиться, что отправляем на сервер нужную ветку и нажать на кнопку Push.

Откат изменений

Несохраненные изменения

Если необходимо отменить изменения в рабочей папке, это можно сделать через окно коммита.

В открывшемся окне выбрать нужные файлы, изменения в которых необходимо откатить и через контекстное меню выбрать Reset file or directory changes.

Также для отмены всех изменений в рабочей папке можно воспользоваться командой из меню Commands -> Reset changes.

Неотправленные изменения

Если изменения еще не были отправлены на сервер, то один или несколько последних коммитов можно откатить, выполнив reset на требуемый коммит с опцией hard. Reset hard удаляет все изменения из рабочей папки, индекса и репозитория. Пользоваться этой опцией нужно аккуратно т.к. можно случайно потерять все свои изменения.

Изменения на сервере

Просто отменить изменения на сервере через reset или rebase нельзя. Все, что отправлено на сервер – это история, которая не подлежит изменению. Если же оказалось необходимым откатить конкретный коммит, который уже был отправлен на сервер, то можно воспользоваться командой revert. Для этого выбрать в истории репозитория коммит, который хотим откатить, и через контекстное меню выбрать Revert commit.

После выполнения этой команды, откаченные изменения автоматически попадут в индекс, и их останется только закоммитить и отправить на сервер, или же можно поставить галочку “Automatically create a commit”, тогда коммит с откатом изменений будет создан автоматически, и останется только отправить его на сервер.

Чтобы исправить свои отправленные изменения, которые были откачены с помощью revert, можно сделать revert для revert-commit’а. Изменения появятся в индексе, их можно поправить и залить.

Работа с ветками

Создание веток

Чтобы создать ветку, нужно нажать ПКМ на нужном коммите, на котором будет находится текущий указатель ветки. В контекстном меню выбрать Create new branch. В открывшемся окне указать имя ветви и нажать Create branch.

Использовать слово master в ветках кроме master нельзя.

Переключение между ветками

Для переключения веток нужно воспользоваться переключателем сверху:

В выпадающем списке отображаются только локальные ветки. Для переключения на remote-ветки необходимо выбрать пункт «Checkout branch...», и в открывашемся окне выбрать удаленную ветку, на которую надо переключиться.

Примечание. При переименовании объектов меняется большое количество файлов метаданных. Объекты необходимо переименовывать только в ветке разработки в момент, когда нет активных веток фич. Для этого вся текущая разработка по фичам должна быть слита в целевую ветку, после переименования объектов создаются новые ветки для продолжения разработки с актуальными наименованиями. Данные работы необходимо проводить согласованно всей командой разработки.

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