---
status: seed
type: concept
tags: []
created: 2025-12-17
updated: 2026-06-10
aliases: []
---

# Система контроля версий. Знакомство с Git

## Git

Неоспоримыми преимуществами Git являются:

- Высокая производительность.
- Безопасность.
- Гибкость в распределенных системах.
- Прекрасные возможности для командной работы.

### Производительность

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

### Безопасность

Безопасность при работе с Git обеспечивается целостностью исходного кода и применением алгоритма шифрования SHA1.

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

### Гибкость

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

### Возможности для командной работы

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

## Часть 3. Модели управления исходным кодом

Работа с версиями исходного кода в Git построена на основе использования:

- Коммитов (Commits).
- Веток (Branches).
- Слияния веток (Merge).
- Сравнения версий (Diff).

Большой популярностью до сих пор пользуется модель под названием Gitflow.

### Gitflow

**Gitflow** — модель ветвления в Git, в которой используются основные ветки (Main, Кelease, Вevelop) и функциональные ветки (Feature).

В качестве основных веток в Gitflow часто используются:

- Main (Ex. master).
- Release.
- Develop (Dev).

В ветке Main хранится официальная история релизов, в Release ветках концентрируется функционал готово к выпуску релиза продукта, а ветка Develop предназначена для разработки функционала.

В качестве функциональных веток в `Gitflow` используются *Feature* ветки, ответвленные от основной ветки *Develop*.

Работа над каждым новым функционалом ведется командой в собственной *Feature-ветке*.
После завершения разработки функционала, каждая *Feature-ветка* **сливается** с *Develop-веткой*.

Когда в *Develop-ветке* оказывается достаточно функционала для выпуска нового релиза, на основе *Develop-ветки* создается ветка **Release**.

После прохождения всех тестов и проверок, Release-ветка сливается с остальными основными ветками — Main и Develop.

**Весь цикл разработки в модели Gitflow можно визуализировать** **следующим образом:**

![](https://legacy.merionet.ru/images/devops/images/3756/img_01.png)

**Модель Gitflow обладает и недостатками:**

- Не лучшая совместимость с современными процессами CI/CD.
- Не подходит для рабочих процессов, основывающихся на подходах, отличных от регулярного выпуска релизов.
- Потенциально запутанная схема веток и трудности в восстановлении историчности их слияний в сложных проектах.

На данный момент, Gitflow является *недостаточно универсальной моделью* рабочего процесса разработки и считается **устаревшей**.

Предпочтительной для современных процессов разработки является модель магистральных рабочих процессов (TBD).

### TBD

**TBD (Trunk Based Development)** — альтернативная модель управления исходным кодом в Git на основе ветвления, пришедшая на смену устаревшей модели Gitflow.

Модель TBD основана на принципе использования одной главной ветки, называемой “магистралью” (Trunk).

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

Команда разработки, ведущая работу над новым функционалом, сохраняет свои изменения только в Trunk-ветку и обеспечивает непрерывную сборку, тестирование и доставку нового функционала, не привязываясь к срокам и частоте выпуска релизов.

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

**Модель TBD можно визуализировать следующим образом:**

![](https://legacy.merionet.ru/images/devops/images/3756/img_02.png)

Модель TDB быстро завоевала популярность в разветвленных проектах и прекрасно зарекомендовала себя в распределенных больших командах разработки за счет своей понятности, динамичности и совместимости с CI/CD-процессами.

## Часть 4. Знакомство с Gitlab

### Gitlab

**Gitlab** — это веб-приложение, обеспечивающее управление репозиториями программного кода в системе контроля версий Git.

Установить и использовать Gitlab можно на собственном сервере или в облачной инфраструктуре.

Gitlab позволяет:

- Создавать, изменять и удалять репозитории.
- Управлять пользователями и их правами.
- Автоматизировать процессы CI/CD и тестирования.
- Полнофункционально взаимодействовать с исходным кодом из веб-интерфейса.

Основные преимущества Gitlab:

- Гибкие возможности по планированию командной разработки.
- Создание и управление проектами.
- Построение процессов тестирования кода.
- Непрерывная сборка и доставка (CI/CD).
- Наблюдаемость (Observability).

Gitlab позволяет эффективно поддерживать и развивать выбранный вами подход по управлению исходным кодом и командной разработкой (Gitflow, TDB и другие).

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

Функциональность Gitlab позволяет задействовать инструменты по управлению ветками и коммитами пользователей, обеспечивая слаженную командную работу.

В Gitlab реализованы инструменты для проведения следующих операций над исходным кодом:

- Code-review.
- Оценка качества кода.
- Тестирование.

Возможна настройка модели приемки качества исходного кода, его проверки и тестирования.

Gitlab обладает интегрированными инструментами, позволяющими автоматизировать рутинные операции с исходным кодом:

- Непрерывную сборку и доставку (CI/CD).
- Тестирование новых версий.
- Релизный цикл продукта.
- Проверки по безопасности.

Gitlab позволяет отслеживать и обрабатывать множество важной информации о процессе разработки:

- Трекинг затраченного рабочего времени на разработку функционала и выпуск новых релизов.
- Мониторинг работоспособности приложения.
- Расширенный сбор и анализ метрик.

## Часть 5. Основные команды git

### Команды Git

#### `git init`

Создание нового Git-репозитория (преобразование существующего проекта или создание нового пустого репозитория).

#### `git clone`

Создание локальной копии удаленного Git-репозитория.

#### `git branch`

Создание отдельной ветки на основе существующей для осуществления в новой ветке процесса разработки с возможным последующим слиянием.

#### `git checkout`

Переключение между различными версиями целевого объекта (файлы, коммиты и ветки).

#### `git status`

Отображение рабочего состояния файлов в локальной копии отслеживаемого проекта.

#### `git add`

Индексирование изменений в локальной копии отслеживаемого проекта.

#### `git commit`

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

#### `git push`

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

#### `git pull`

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

#### `git restore`

Отмена индексации изменений в локальном репозитории.

#### `git revert`

Отмена подготовленных к отправке проиндексированных изменений в локальном репозитории с сохранением истории.

#### `git merge`

Слияние ответвления (ветки ответвленной с веткой изначальной). Изменения часто проходят процедуру согласования с участниками команды разработки через механизм merge Request.

#### `git rebase`

Операция, подобная слиянию (Git merge).

**Команды Git merge и Git rebase решают одну и ту же проблему –** **слияние одной ветки в другую, но делают это по-разному.**

**Git merge** — это неразрушающая операция, существующие ветки никак не изменяются.

![](https://legacy.merionet.ru/images/devops/images/3756/img_04.png)

**Git rebase** — это операция фактического перебазирования ответвленной ветки в исходную, с созданием идеальной линейной истории проекта.

![](https://legacy.merionet.ru/images/devops/images/3756/img_03.png)

Золотое правило перебазирования:

**“Never rebase while you're on a public branch”** (никогда не используйте git rebase в публичных репозиториях) Если вы предпочитаете иметь чистую линейную историю без ненужных коммитов слияния – используйте Git rebase.

Если вам необходимо сохранить полную историю проекта и избежать перезаписи публичных коммитов – используйте команду Git merge.