Git и GitLab: Мастерство ветвления, слияния и Rebase

Основы ветвления: архитектура Git, создание и переключение между ветками

Добро пожаловать в курс «Git и GitLab: Мастерство ветвления, слияния и Rebase». Мы начинаем наше погружение в мир контроля версий с фундаментальной темы, без которой невозможно представить современную разработку — с ветвления. В этой статье мы разберем, как Git работает изнутри, что такое ветки на физическом уровне и как ими управлять.

Архитектура Git: Снимки, а не дельты

Чтобы понять ветвление, нужно сначала осознать, как Git хранит данные. Многие системы контроля версий (например, старый SVN) хранят информацию как список изменений для каждого файла. Это похоже на то, как если бы вы хранили только список правок: «в строке 10 добавлено слово». Это называется дельта-хранением.

Git работает иначе. Он мыслит снимками (snapshots).

Каждый раз, когда вы делаете коммит (сохраняете состояние проекта), Git словно делает фотографию всех ваших файлов в данный момент и сохраняет ссылку на этот снимок. Если файл не изменился, Git не сохраняет его копию снова, а просто делает ссылку на предыдущий идентичный файл.

!Сравнение дельта-хранения и хранения снимков (Snapshots) в Git

Три состояния Git

Понимание архитектуры невозможно без знания трех состояний, в которых могут находиться ваши файлы:

Modified (Изменен) — вы поменяли файл, но еще не зафиксировали это изменение в базе данных Git.

Staged (Подготовлен) — вы отметили измененный файл как готовый к включению в следующий коммит (команда git add).

Committed (Зафиксирован) — данные сохранены в локальной базе данных Git (команда git commit).

Эти состояния соответствуют трем секциям проекта Git:

* Рабочая директория (Working Directory): то, что вы видите в редакторе кода. * Область подготовленных файлов (Staging Area / Index): файл, содержащий информацию о том, что войдет в следующий коммит. * Директория .git (Repository): место, где Git хранит метаданные и базу объектов.

Что такое ветка на самом деле?

Теперь, когда мы знаем о снимках, давайте разберем ветки. Для новичков ветвление часто кажется чем-то сложным, вроде создания полной копии папки с проектом. Но в Git ветка — это невероятно легковесная сущность.

Ветка в Git — это просто подвижный указатель на один из коммитов.

Когда вы создаете коммиты, они выстраиваются в цепочку, где каждый коммит знает, кто был его родителем. Ветка — это просто ярлык (название), приклеенный к последнему коммиту в этой цепочке.

По умолчанию основная ветка во многих репозиториях называется master или main. Когда вы делаете новые коммиты, находясь в этой ветке, указатель main автоматически сдвигается вперед.

Роль HEAD

Как Git узнает, на какой ветке вы сейчас находитесь? Для этого существует специальный указатель под названием HEAD.

Представьте HEAD как курсор или отметку «Вы находитесь здесь» на карте. Обычно HEAD указывает на имя текущей ветки, а ветка, в свою очередь, указывает на последний коммит.

!Визуализация того, как HEAD указывает на текущую активную ветку, а ветки указывают на конкретные коммиты

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

Создание ветки происходит мгновенно, независимо от размера вашего проекта. Почему? Потому что Git не копирует файлы. Он просто создает новый файл размером 41 байт, в который записывает хеш-сумму (идентификатор) того коммита, на котором вы сейчас находитесь.

Команда для создания ветки:

Например, создадим ветку для разработки новой функции:

Важно: Эта команда только создает ветку, но не переключает вас на нее. Ваш HEAD все еще указывает на старую ветку (например, на main).

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

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

Или более современная и интуитивная команда (добавленная в Git версии 2.23):

Пример:

Что происходит при переключении?

Это один из самых важных моментов в понимании Git. Когда вы переключаетесь на другую ветку, Git физически меняет файлы в вашей рабочей директории.

Если вы переключитесь на старую ветку, файлы, которых там не было, исчезнут из папки (но останутся в базе Git в другой ветке), а измененные файлы вернутся к состоянию того момента.

> Внимание: Перед переключением веток всегда старайтесь иметь «чистую» рабочую директорию (закоммитить или спрятать текущие изменения), иначе Git может запретить переключение, чтобы вы не потеряли несохраненные данные.

Создание и переключение одной командой

Разработчики редко создают ветку, чтобы не переключиться на нее сразу. Поэтому существует сокращение.

Используя checkout:

Используя switch:

Флаг -b означает branch (ветка), а -c — create (создать).

Ветвление и GitLab

Хотя Git — это инструмент, работающий локально на вашем компьютере, GitLab выступает в роли удаленного хранилища (Remote). Ваши локальные ветки не появляются в GitLab автоматически.

Чтобы ваша ветка feature-login стала доступна коллегам в GitLab, её нужно «запушить» (отправить):

Флаг -u (или --set-upstream) связывает вашу локальную ветку с удаленной веткой. В будущем, находясь в этой ветке, вы сможете писать просто git push без дополнительных аргументов.

В интерфейсе GitLab вы увидите список всех веток в разделе Repository -> Branches. Это позволяет проводить Code Review и использовать Merge Requests, о чем мы поговорим в следующих статьях.

Итоги

В этой статье мы заложили фундамент для работы с Git:

Git хранит снимки файлов, а не разницу изменений.

Ветка — это просто легкий подвижный указатель на коммит.

HEAD — это указатель на текущую активную ветку.

Для создания веток используется git branch, а для переключения — git checkout или git switch.

Переключение веток изменяет файлы в вашей рабочей директории.

В следующей статье мы разберем, как соединять истории разработки воедино, изучив операции Merge (слияние) и разрешение конфликтов.

Механизмы слияния: Merge Commit, Fast-forward и разрешение конфликтов

В предыдущей статье мы выяснили, что ветка в Git — это всего лишь подвижный указатель на коммит. Мы научились создавать эти указатели и перемещаться между ними. Но создание изолированных веток — это лишь половина дела. Главная сила систем контроля версий заключается в умении объединять результаты параллельной работы.

Сегодня мы разберем магию команды git merge. Мы узнаем, почему иногда Git просто «перематывает» историю, а иногда создает новые коммиты, как работает алгоритм трехстороннего слияния и, самое главное, как без страха разрешать конфликты в коде.

Два типа слияния

Когда вы командуете Git объединить одну ветку с другой (например, влить feature-login в main), Git анализирует историю обеих веток и выбирает одну из двух стратегий: Fast-forward или True Merge (истинное слияние).

1. Стратегия Fast-forward (Перемотка)

Это самый простой и «чистый» сценарий. Он возможен, когда история не расходилась.

Представьте ситуацию:

Вы находитесь в ветке main.

Создаете ветку feature-new.

Делаете три коммита в feature-new.

За это время в main не было сделано ни одного нового коммита.

С точки зрения Git, ветка feature-new содержит всю историю main плюс новые изменения. Между кончиком main и кончиком feature-new лежит прямая линия.

Когда вы выполняете команду:

Git видит, что ему не нужно ничего «сливать» в прямом смысле слова. Ему достаточно просто взять указатель main и перенести его вперед, на тот же коммит, где сейчас находится feature-new.

!Визуализация стратегии Fast-forward: указатель ветки просто догоняет убежавшую вперед историю.

Особенности Fast-forward: * Плюс: История остается идеально линейной, без лишних «узлов» слияния. * Минус: Вы теряете информацию о том, что эти коммиты вообще разрабатывались в отдельной ветке. Группа коммитов просто становится частью основной истории.

2. Стратегия True Merge (Истинное слияние)

Ситуация меняется, если история разошлась (diverged history).

Представьте:

Вы создали ветку feature-new от main и сделали там коммит A.

В это же время ваш коллега сделал коммит B прямо в ветку main (или вы сами сделали хотфикс).

Теперь main указывает на B, а feature-new на A. Прямой линии больше нет. Указатель main нельзя просто «передвинуть» на A, потому что тогда потеряется коммит B.

В этом случае Git прибегает к стратегии 3-way merge (трехстороннее слияние).

#### Алгоритм трехстороннего слияния

Чтобы объединить ветки, Git использует три точки:

Вершину текущей ветки (main).

Вершину вливаемой ветки (feature-new).

Общего предка (Common Ancestor) — последний коммит, когда эти ветки были единым целым.

Git сравнивает изменения в двух ветках относительно общего предка и создает абсолютно новый объект — Merge Commit (коммит слияния).

!Визуализация истинного слияния: две независимые линии разработки объединяются в одном специальном коммите.

Особенности Merge Commit: * У этого коммита два родителя (предыдущий коммит из main и последний коммит из feature-new). * В истории явно видно, когда ветка отделилась и когда вернулась. * Сообщение коммита по умолчанию обычно выглядит как Merge branch 'feature-new'.

Управление стратегиями

Иногда вы хотите создать Merge Commit, даже если возможен Fast-forward (чтобы сохранить историю существования ветки). Для этого используется флаг --no-ff:

Это заставит Git создать отдельный «узел» слияния, сохраняя группировку коммитов фичи.

Разрешение конфликтов

Конфликты — это не ошибка, а нормальная часть командной работы. Они возникают, когда Git не может автоматически решить, как объединить изменения.

Когда возникает конфликт? Чаще всего это происходит при истинном слиянии, если в обеих ветках была изменена одна и та же строка в одном и том же файле, или если один человек удалил файл, а другой его отредактировал.

Анатомия конфликта

Когда вы запускаете git merge и происходит конфликт, Git:

Приостанавливает процесс слияния.

Сообщает вам, какие файлы конфликтуют (CONFLICT (content): Merge conflict in index.html).

Модифицирует содержимое этих файлов, добавляя специальные маркеры.

Если вы откроете конфликтующий файл, вы увидите нечто подобное:

Давайте разберем эти маркеры: * <<<<<<< HEAD: Начало изменений из вашей текущей ветки (куда вы вливаете). * =======: Разделитель. Всё, что выше — ваше, всё, что ниже — пришло из другой ветки. * >>>>>>> feature-new: Конец изменений из вливаемой ветки.

Алгоритм разрешения конфликта

Процесс разрешения всегда следует одному паттерну:

Обнаружение: Git сообщает о конфликте.

Редактирование: Вы открываете файлы и вручную выбираете правильный вариант. Вы должны удалить маркеры (<<<<<<<, =======, >>>>>>>) и оставить только нужный код. Вы можете оставить оба варианта, объединить их или выбрать один.

Фиксация решения: После редактирования вы должны сообщить Git, что файл исправлен. Это делается командой git add.

Завершение слияния: Выполните git commit. Обычно сообщение коммита уже заполнено автоматически, но вы можете его дополнить.

Пример действий в терминале:

Если вы передумали и хотите отменить слияние, используйте:

Слияние в контексте GitLab

В профессиональной среде мы редко делаем слияние важных веток (например, в main) локально через консоль. Вместо этого используется механизм Merge Request (MR) в GitLab.

Когда вы создаете Merge Request:

GitLab показывает разницу (diff) между ветками.

GitLab проверяет наличие конфликтов. Если конфликтов нет, кнопка «Merge» активна.

Если конфликты есть, GitLab предложит разрешить их либо в веб-интерфейсе (для простых случаев), либо локально.

Важный нюанс: GitLab по умолчанию часто настроен на создание Merge Commit, даже если возможен Fast-forward. Это делается для того, чтобы в истории проекта main оставались ссылки на Merge Request'ы, что упрощает аудит изменений и навигацию по истории проекта.

Rebase: Альтернатива слиянию

Существует еще один способ объединения изменений — Rebase (перебазирование). Он позволяет переписать историю так, будто вы начали работу над своей веткой только что, избегая лишних Merge Commit'ов. Но это мощный и опасный инструмент, который требует отдельного разговора. Ему будет посвящена наша следующая статья.

Итоги

Fast-forward происходит, когда история линейна. Указатель просто сдвигается вперед.

Merge Commit создается, когда история разошлась. Он имеет двух родителей и объединяет состояния двух веток.

Флаг --no-ff позволяет принудительно создать коммит слияния для сохранения истории ветки.

Конфликты возникают при изменении одних и тех же строк. Их нужно разрешать вручную, удаляя маркеры и выбирая верный код.

Для завершения разрешения конфликта необходимо выполнить git add и git commit.

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

Перебазирование (Rebase): создание линейной истории и интерактивное редактирование коммитов

В предыдущей статье мы подробно разобрали механизм слияния (git merge). Мы узнали, что это безопасный и надежный способ объединения веток, который сохраняет полную историю разработки, включая момент, когда ветки разошлись и когда они снова сошлись. Однако у слияния есть эстетический недостаток: при активной работе команды история проекта превращается в запутанную схему, напоминающую схему метрополитена или «железнодорожные пути». Обилие Merge Commit (коммитов слияния) может затруднять чтение истории и поиск ошибок.

Сегодня мы познакомимся с Rebase (перебазированием) — инструментом для перфекционистов, который позволяет переписывать историю, делая её идеально прямой и понятной. Мы также научимся редактировать прошлые коммиты, объединять их и менять местами.

Философия Rebase: Что это такое?

Если merge решает задачу «как соединить две ветки», то rebase отвечает на вопрос «как перенести мои изменения на новое основание».

Представьте, что вы начали писать главу книги (ваша ветка feature) на основе черновика (ветка main). Пока вы писали, ваш соавтор переписал вступление в черновике. У вас есть два пути:

Merge: Вы просто дописываете в конце своей главы: «А еще, учитывая новое вступление соавтора, моя глава всё еще имеет смысл». Это создает связующее звено.

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

Технически Rebase берет коммиты из вашей ветки и по очереди применяет их к верхушке другой ветки.

!Визуализация того, как Rebase перемещает базу ветки, выстраивая коммиты в одну линию.

Зачем это нужно?

Главная цель Rebase — линейная история. В ней нет лишних коммитов слияния (Merge branch '...' into '...'). Если вы посмотрите лог проекта (git log), вы увидите прямую линию событий, идущих одно за другим. Это упрощает отладку и использование git bisect (поиск коммита, который сломал сборку).

Как работает Rebase на практике

Допустим, вы находитесь в ветке feature-login и хотите подтянуть свежие изменения из main, чтобы ваша ветка была актуальной.

Вместо git merge main вы выполняете:

Что происходит «под капотом»?

Git находит общего предка двух веток.

Git сохраняет изменения, сделанные в каждом коммите вашей текущей ветки (feature-login), во временные файлы.

Git сбрасывает текущую ветку до состояния main.

Git последовательно применяет сохраненные изменения одно за другим.

Важное отличие: При merge конфликты решаются один раз. При rebase конфликты могут возникать на каждом переносимом коммите. Если у вас в ветке 10 коммитов, теоретически вам, возможно, придется разрешать конфликты 10 раз (хотя на практике это случается редко).

Процесс разрешения конфликтов при Rebase

Если во время переноса коммита возник конфликт, Git остановится и скажет вам об этом. Ваши действия:

Разрешите конфликт в файлах (так же, как при слиянии).

Добавьте файлы в индекс: git add <файл>.

Не делайте коммит! Вместо этого скажите Git продолжить процесс:

Если вы поняли, что всё пошло не так, вы всегда можете прервать операцию и вернуть всё как было:

Золотое правило Rebase

У Rebase есть одна критическая особенность: он меняет хеш-суммы коммитов. Даже если содержимое изменений осталось прежним, у коммита теперь новый родитель и новое время создания. С точки зрения Git, это абсолютно новые коммиты.

Отсюда вытекает главное правило, которое нужно выучить наизусть:

> Никогда не делайте rebase для веток, которые являются публичными (находятся в общем доступе), если кто-то другой мог уже начать основывать на них свою работу.

Если вы сделаете rebase ветки main или общей ветки dev, которую ваши коллеги уже скачали (pull), их история разойдется с вашей. Git посчитает, что истории разветвились, и при попытке синхронизации возникнет хаос из дублирующихся коммитов.

Rebase — это инструмент для вашей личной, локальной работы до того, как вы поделитесь ею с командой.

Интерактивный Rebase: Магия редактирования истории

Помимо выпрямления истории, Rebase обладает мощным режимом — Interactive Mode (-i). Он позволяет вам быть редактором своей истории: менять порядок коммитов, объединять их, переименовывать или удалять.

Это часто используется для «чистки» ветки перед слиянием. Представьте, что вы работали над задачей и сделали такие коммиты:

Реализовал логику входа

Исправил опечатку

Забыл добавить файл

Поправил стили

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

Команда для запуска:

Здесь HEAD~4 означает, что мы хотим отредактировать последние 4 коммита.

Git откроет текстовый редактор (обычно Vim или Nano) со списком коммитов:

Перед каждым коммитом стоит слово pick. Вы можете менять эти команды на другие:

* pick (p): оставить коммит как есть. * reword (r): оставить коммит, но изменить его сообщение (текст). * edit (e): остановиться на этом коммите, чтобы внести изменения в файлы (например, разбить один коммит на два). * squash (s): объединить этот коммит с предыдущим (слить их воедино). * fixup (f): то же, что и squash, но выкинуть сообщение этого коммита (использовать только сообщение предыдущего). * drop (d): удалить коммит полностью.

Чтобы навести порядок в нашем примере, мы изменим файл так:

После сохранения и закрытия редактора Git сожмет все 4 коммита в один единственный, оставив историю чистой и профессиональной.

!Схематичное изображение объединения нескольких коммитов в один с помощью команды squash.

Rebase и GitLab

Как это соотносится с работой в GitLab? Когда вы отправляете изменения на сервер (git push), GitLab видит вашу ветку.

Если вы сделали Rebase локально после того, как уже отправляли ветку на сервер (например, вы запушили черновик, а потом решили его почистить), простой git push не сработает. Git скажет, что удаленная история отличается от вашей.

В этом случае (и только если вы уверены, что никто другой не работает в этой ветке!) нужно использовать форсированный пуш:

Или более безопасный вариант:

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

Настройки Merge Request

В GitLab есть настройки проекта, которые требуют Fast-forward merge. Это означает, что GitLab не позволит вам нажать кнопку «Merge», пока ваша ветка не будет перебазирована на актуальный main. Это принуждает разработчиков поддерживать линейную историю.

Также в интерфейсе Merge Request есть опция Squash commits. Если она включена, GitLab сам сделает «сквош» всех ваших коммитов в один при слиянии, даже если локально у вас их было много. Это позволяет не делать сложный интерактивный rebase вручную, доверяя эту работу GitLab.

Сравнение: Merge vs Rebase

| Характеристика | Merge (Слияние) | Rebase (Перебазирование) | | :--- | :--- | :--- | | История | Нелинейная, сохраняет структуру ветвления | Линейная, выглядит как последовательная работа | | Безопасность | Высокая (не меняет существующие коммиты) | Требует осторожности (переписывает историю) | | Конфликты | Решаются один раз | Могут возникать на каждом шаге | | Применение | Для вливания готовых фич в main | Для обновления личной ветки или чистки истории |

Итоги

Rebase переносит коммиты на новое основание, создавая линейную историю.

Команда git rebase main обновляет вашу ветку данными из main без создания лишнего коммита слияния.

Интерактивный Rebase (git rebase -i) позволяет объединять (squash), переименовывать и удалять коммиты.

Золотое правило: Никогда не делайте rebase публичных веток.

Для отправки переписанной истории на сервер используйте git push --force-with-lease.

Теперь вы владеете полным арсеналом управления историей. В следующих материалах мы рассмотрим конкретные рабочие процессы (Workflows), такие как Gitflow и GitLab Flow, чтобы понять, как применять эти команды в командной разработке.

Специфика GitLab: удаленные репозитории, Merge Requests и процесс Code Review

Мы прошли долгий путь. Мы начали с архитектуры Git, научились создавать ветки, освоили слияние и даже научились переписывать историю с помощью Rebase. Но до сих пор мы работали в вакууме — на одном локальном компьютере.

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

В этой статье мы разберем, как Git работает с сетью, что такое «удаленный репозиторий» (Remote), зачем нужны Merge Requests и как проходит процесс Code Review.

Удаленные репозитории (Remotes)

До этого момента ваш репозиторий жил только в папке .git на вашем диске. Удаленный репозиторий — это версия вашего проекта, которая хранится на сервере (в нашем случае — на серверах GitLab).

Связь между вашим компьютером и сервером не постоянная. Git не синхронизирует файлы в реальном времени, как Dropbox или Google Drive. Вы должны явно отдавать команды: «отправь мои изменения» или «забери чужие изменения».

Понятие Origin

Когда вы клонируете проект с GitLab командой git clone, Git автоматически создает связь с этим сервером и дает ей стандартное имя — origin.

Origin — это просто псевдоним (алиас) для длинного URL-адреса вашего репозитория (например, https://gitlab.com/username/project.git).

Чтобы посмотреть список настроенных удаленных серверов, используйте команду:

Вывод покажет адреса для скачивания (fetch) и отправки (push) данных.

!Схема обмена данными между локальным компьютером и GitLab

Синхронизация: Push, Fetch и Pull

Давайте разберем три главные команды для работы с сетью.

1. Git Push (Отправка)

Команда git push берет ваши локальные коммиты и отправляет их на сервер.

Эта команда говорит Git: «Возьми ветку feature-login и отправь её в удаленный репозиторий origin».

Если вы помните, в первой статье мы использовали флаг -u (git push -u origin ...). Он запоминает связь, чтобы в будущем можно было писать просто git push.

2. Git Fetch (Скачивание информации)

Многие новички путают fetch и pull.

git fetch — это безопасная разведка. Эта команда связывается с сервером и скачивает всю новую информацию (новые ветки, новые коммиты коллег), но не применяет их к вашим файлам.

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

3. Git Pull (Получение и слияние)

git pull — это команда для тех, кто хочет получить актуальный код здесь и сейчас. По сути, это макрос, который выполняет два действия последовательно:

git fetch (скачать изменения).

git merge (влить их в текущую ветку).

> Совет: Если вы хотите избежать лишних коммитов слияния при получении обновлений, профессионалы часто используют git pull --rebase. Это скачает изменения с сервера и перебазирует ваши локальные коммиты поверх них.

Merge Request (MR): Сердце GitLab

В предыдущих статьях мы делали git merge в консоли. В командной разработке прямое слияние в главную ветку (main или master) часто запрещено настройками репозитория (Protected Branches).

Вместо этого используется Merge Request (в GitHub он называется Pull Request, но суть одна).

Merge Request (MR) — это заявка на слияние. Это веб-страница в GitLab, где вы говорите: «Я закончил работу над веткой feature-login, прошу рассмотреть мой код и влить его в main».

Зачем нужен MR?

Визуализация изменений: GitLab показывает красивый diff (разницу) файлов с подсветкой синтаксиса.

Автоматизация (CI/CD): GitLab может автоматически запустить тесты на вашем коде, проверить стиль написания и безопасность.

Обсуждение: Команда может обсуждать конкретные строки кода.

Контроль качества: Слияние происходит только после одобрения (Approve) от старших разработчиков.

!Интерфейс создания заявки на слияние в GitLab

Процесс Code Review (Ревью кода)

Code Review — это этап, когда другие разработчики читают ваш код перед тем, как он попадет в основную ветку. Это не экзамен и не поиск виноватых. Это лучший способ обмена знаниями в команде.

Как это выглядит в GitLab?

Вы создаете MR.

Ваши коллеги заходят на вкладку Changes (Изменения).

Они могут кликнуть на любую строку кода и оставить комментарий. Например: «Здесь возможна утечка памяти» или «Отличное решение, очень элегантно!».

Вы получаете уведомления и отвечаете на комментарии.

Исправление замечаний

Это самый частый вопрос новичков: «Мне оставили замечания. Как мне обновить MR? Нужно создавать новый?»

Нет! Merge Request жестко привязан к вашей ветке.

Чтобы обновить код в MR:

Внесите исправления в код локально на своем компьютере.

Сделайте новый коммит: git commit -m "Fix review comments".

Сделайте git push в ту же самую ветку.

GitLab автоматически увидит новые коммиты и обновит страницу Merge Request. Старые комментарии, которые стали неактуальны, можно пометить как Resolved (Решено).

Сквошинг при слиянии (Squash and Merge)

В статье про Rebase мы говорили о том, как важно иметь чистую историю. В GitLab есть галочка Squash commits when merge request is accepted.

Если она включена, то все ваши 10 коммитов (включая «исправил опечатку» и «поправил замечания ревьювера») при нажатии кнопки Merge превратятся в один аккуратный коммит в ветке main. Это позволяет вам делать сколько угодно черновых коммитов в процессе работы, не беспокоясь о мусоре в истории проекта.

Жизненный цикл задачи в GitLab

Подводя итог всему курсу, вот как выглядит типичный рабочий процесс (Workflow) разработчика:

Получение задачи: Вы берете задачу в работу.

Актуализация: Переключаетесь на main и делаете git pull, чтобы получить свежий код.

Ветвление: Создаете ветку git switch -c feature-task.

Работа: Пишете код, делаете коммиты.

Публикация: Отправляете ветку на сервер: git push -u origin feature-task.

Merge Request: Создаете MR в интерфейсе GitLab.

Review: Коллеги смотрят код, вы вносите правки новыми коммитами и пушите их.

Merge: Когда получены аппрувы (одобрения), нажимается кнопка Merge.

Чистка: Удаляете ветку локально и на сервере, так как она больше не нужна.

Заключение курса

Поздравляю! Вы прошли путь от понимания того, как Git хранит снимки файлов, до профессионального процесса работы с удаленными репозиториями.

Теперь вы знаете: * Как создавать и переключать ветки. * Как разрешать конфликты при слиянии. * Как использовать Rebase для линеаризации истории. * Как работать с GitLab, создавать MR и проходить Code Review.

Эти навыки — фундамент современной разработки ПО. Git — это инструмент, который будет с вами каждый день вашей карьеры. Используйте его мудро, держите историю чистой и не бойтесь экспериментировать в отдельных ветках!

Стратегии ветвления (Git Flow, GitLab Flow) и лучшие практики командной работы

Мы подошли к финальной части нашего курса. В предыдущих статьях мы освоили технический арсенал: научились создавать ветки, сливать их, разрешать конфликты, использовать Rebase и работать с Merge Requests в GitLab. Теперь у вас есть инструменты, но остается главный вопрос: как организовать процесс, чтобы не создать хаос?

Если дать команде из 10 разработчиков полную свободу действий без правил, через неделю репозиторий превратится в запутанный клубок, а релиз продукта станет ночным кошмаром. Чтобы этого избежать, существуют стратегии ветвления (Branching Strategies) или рабочие процессы (Workflows).

В этой статье мы разберем три самых популярных подхода: классический Git Flow, упрощенный GitHub Flow и сбалансированный GitLab Flow. Мы также обсудим «золотые правила» оформления коммитов и ведения истории.

Зачем нужна стратегия ветвления?

Стратегия ветвления — это набор соглашений, который отвечает на вопросы:

От какой ветки нужно отпочковываться для новой задачи?

В какую ветку нужно вливать изменения?

Какие ветки являются стабильными, а какие — рабочими?

Как происходит выкладка (деплой) на продакшн?

Без стратегии вы рискуете случайно удалить рабочий код, заблокировать релиз нестабильной фичей или потерять критическое исправление ошибки.

Git Flow: Классика для релизных циклов

Git Flow, предложенный Винсентом Дриссеном в 2010 году, долгое время считался стандартом индустрии. Это строгая модель, идеально подходящая для продуктов с четкими версиями (например, мобильные приложения или коробочный софт), где релизы выходят раз в месяц или квартал.

!Визуализация структуры Git Flow с ветками master, develop, feature, release и hotfix

Основные роли веток в Git Flow

В этой модели существуют две долгоживущие ветки:

master (или main) — священная ветка. Код в ней всегда должен быть готов к релизу. Сюда попадает только протестированный код.

develop — ветка интеграции. Сюда сливаются все новые функции. Это «черновик» следующего релиза.

И три типа временных веток:

Feature branches (ветки фич): Создаются от develop, вливаются обратно в develop. Здесь идет повседневная разработка.

Release branches (релизные ветки): Когда в develop накоплено достаточно фич, создается ветка release-1.0. В ней исправляются баги и обновляется документация. Новые фичи сюда добавлять нельзя. После завершения она вливается и в master, и в develop.

Hotfix branches (ветки исправлений): Единственный способ внести изменения прямо в master. Используются для экстренного исправления багов на продакшене. Вливаются в master и develop.

Плюсы и минусы Git Flow

* Плюсы: Четкая структура, идеально для поддержки нескольких версий продукта, параллельная работа над фичами и стабилизацией релиза. * Минусы: Избыточная сложность для веб-сервисов. Слишком много переключений контекста и слияний. Сложно внедрять CI/CD (непрерывную доставку), так как путь кода до продакшена очень долгий.

GitHub Flow: Простота и скорость

В противовес тяжеловесному Git Flow появилась модель GitHub Flow. Она создана для веб-приложений, где деплой может происходить несколько раз в день.

Суть проста: есть только одна долгоживущая ветка — main.

Алгоритм работы

Все, что находится в ветке main, должно быть готово к деплою.

Для любой задачи (фича или багфикс) создается ветка от main.

Разработка идет в этой ветке.

Открывается Pull Request (Merge Request).

После ревью и тестов ветка вливается в main.

Важно: Сразу после слияния main автоматически деплоится на продакшн.

!Простая схема GitHub Flow: создание ветки от main и возвращение обратно

* Плюсы: Максимальная простота, высокая скорость доставки ценности (Time to Market). * Минусы: Рискованно для больших команд без идеального покрытия автотестами. Если сломать main, сломается продакшн.

GitLab Flow: Золотая середина

GitLab Flow пытается объединить лучшее из двух миров. Он признает, что GitHub Flow слишком прост для корпоративных систем (где нужны среды тестирования: Staging, Pre-prod), а Git Flow слишком сложен.

Главный принцип GitLab Flow: Upstream First (Сначала в основной поток). Все изменения сначала должны попасть в main, и только потом — в релизные ветки или ветки окружений.

Вариант 1: Ветки окружений (Environment Branches)

Используется, когда у вас есть сервер staging (для тестов) и сервер production (для пользователей).

Разработка идет в фича-ветках, которые вливаются в main.

Когда код в main проверен, он вливается (merge) в ветку staging. Это триггерит деплой на тестовый сервер.

После проверки на стейджинге, ветка staging вливается в production. Это триггерит деплой пользователям.

Поток данных строго однонаправленный: feature -> main -> staging -> production.

!Схема движения кода в GitLab Flow через ветки окружений

Вариант 2: Релизные ветки (Release Branches)

Используется для софта с версиями (как в Git Flow), но проще.

Вся работа идет в main.

Когда main стабилен, от него создается ветка stable-1.0.

В этой ветке ничего не разрабатывается, только фиксятся критические баги (cherry-pick из main).

Ветка живет столько, сколько поддерживается версия 1.0.

Почему GitLab Flow хорош?

Он позволяет адаптировать процесс под реальную инфраструктуру компании, сохраняя при этом чистоту истории и логику «одного источника правды» в main.

Сравнительная таблица стратегий

| Характеристика | Git Flow | GitHub Flow | GitLab Flow | | :--- | :--- | :--- | :--- | | Сложность | Высокая | Низкая | Средняя | | Частота релизов | Раз в месяц/квартал | Несколько раз в день | Гибко (по ситуации) | | Основные ветки | master, develop | main | main + production/stable | | Для кого | Коробочный софт, мобильные приложения | Стартапы, веб-сервисы, SaaS | Enterprise, сложные системы |

Лучшие практики командной работы

Какую бы стратегию вы ни выбрали, культура работы с Git важнее схемы.

1. Атомарные коммиты

Один коммит должен решать одну задачу. Не смешивайте в одном коммите исправление бага в базе данных и изменение цвета кнопки на фронтенде.

* Плохо: Fix login bug and update footer style * Хорошо: Два отдельных коммита.

Это позволяет легко откатить (revert) изменение стиля, не ломая логин.

2. Осмысленные сообщения коммитов (Commit Messages)

Сообщение fix или update не несет информации. Используйте стандарт Conventional Commits.

Структура: тип(область): описание

Примеры: * feat(auth): add google oauth login (добавлена новая фича) * fix(api): handle timeout error (исправлен баг) * docs: update readme (обновление документации) * refactor: simplify user controller (улучшение кода без изменения логики)

Используйте повелительное наклонение (Imperative mood): «Add», а не «Added» или «Adding».

3. Защита веток (Protected Branches)

В настройках GitLab (Settings -> Repository -> Protected branches) обязательно защитите ветки main и production.

* Запретите Force push (чтобы никто случайно не переписал историю). * Запретите прямой Push (разрешите только Merge через Merge Request). * Требуйте одобрения (Approve) от 1-2 коллег перед слиянием.

4. Держите ветки свежими

Не держите фича-ветку открытой неделями. Чем дольше вы не вливаете код в main, тем сложнее будет разрешать конфликты (это называется «Integration Hell» — ад интеграции). Старайтесь делать задачи, которые можно выполнить и слить за 1-2 дня.

5. Удаляйте старые ветки

После того как Merge Request принят и слит, ветка feature-login больше не нужна. GitLab предлагает кнопку «Delete source branch» при слиянии. Пользуйтесь ею. Замусоренный список веток усложняет навигацию.

Заключение курса

Мы прошли большой путь в курсе «Git и GitLab: Мастерство ветвления, слияния и Rebase».

Теперь вы понимаете: * Что Git хранит снимки, а не разницу файлов. * Как элегантно решать конфликты и не бояться их. * В чем сила Rebase для создания красивой истории. * Как выбрать правильную стратегию ветвления для вашего проекта.

Git — это инструмент, который легко выучить за выходные, но в котором можно совершенствоваться годами. Практикуйтесь, уважайте историю проекта и пишите код, который приятно читать вашим коллегам. Удачи в разработке!