ada-pc: 2026-06-10 22:22:37 | 1

Affected files:
00 Inbox/Система контроля версий. Знакомство с Git.md
This commit is contained in:
Dmitry
2026-06-10 22:22:37 +03:00
parent 62d50b94b1
commit 7247dca120
@@ -9,6 +9,8 @@ aliases: []
# Система контроля версий. Знакомство с Git
## Git
Неоспоримыми преимуществами Git являются:
- Высокая производительность.
@@ -16,20 +18,207 @@ aliases: []
- Гибкость в распределенных системах.
- Прекрасные возможности для командной работы.
## Производительность
### Производительность
Высокая производительность Git обусловлена подходом по оптимизации внутренних процедур и использованию анализа содержимого файлов Git работает с файлами, храня объекты с содержимым каталога и метаданными их версий.
## Безопасность
### Безопасность
Безопасность при работе с Git обеспечивается целостностью исходного кода и применением алгоритма шифрования SHA1.
Использование Git гарантирует подлинность истории изменений и защищает исходный код от тайного внесения изменений.
## Гибкость
### Гибкость
Гибкость при работе с 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.