Dmitry
223 lines
15 KiB
Markdown
223 lines
15 KiB
Markdown
---
|
||
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 можно визуализировать** **следующим образом:**
|
||
|
||
|
||
|
||
**Модель Gitflow обладает и недостатками:**
|
||
|
||
- Не лучшая совместимость с современными процессами CI/CD.
|
||
- Не подходит для рабочих процессов, основывающихся на подходах, отличных от регулярного выпуска релизов.
|
||
- Потенциально запутанная схема веток и трудности в восстановлении историчности их слияний в сложных проектах.
|
||
|
||
На данный момент, Gitflow является *недостаточно универсальной моделью* рабочего процесса разработки и считается **устаревшей**.
|
||
|
||
Предпочтительной для современных процессов разработки является модель магистральных рабочих процессов (TBD).
|
||
|
||
### TBD
|
||
|
||
**TBD (Trunk Based Development)** — альтернативная модель управления исходным кодом в Git на основе ветвления, пришедшая на смену устаревшей модели Gitflow.
|
||
|
||
Модель TBD основана на принципе использования одной главной ветки, называемой “магистралью” (Trunk).
|
||
|
||
Вся работа над новым функционалом ведется разработчиками именно в магистральной ветке, что исключает трудности, связанные со слиянием и неработающими сборками.
|
||
|
||
Команда разработки, ведущая работу над новым функционалом, сохраняет свои изменения только в Trunk-ветку и обеспечивает непрерывную сборку, тестирование и доставку нового функционала, не привязываясь к срокам и частоте выпуска релизов.
|
||
|
||
При использовании модели TBD и регулярном добавлении в основную Trunk-ветку функционала, а также настроенных стабильных процессов сборки и доставки продукта (CI/CD), выпустить релиз можно практически в любой момент.
|
||
|
||
**Модель TBD можно визуализировать следующим образом:**
|
||
|
||
|
||
|
||
Модель 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** — это неразрушающая операция, существующие ветки никак не изменяются.
|
||
|
||
|
||
|
||
**Git rebase** — это операция фактического перебазирования ответвленной ветки в исходную, с созданием идеальной линейной истории проекта.
|
||
|
||
|
||
|
||
Золотое правило перебазирования:
|
||
|
||
**“Never rebase while you're on a public branch”** (никогда не используйте git rebase в публичных репозиториях) Если вы предпочитаете иметь чистую линейную историю без ненужных коммитов слияния – используйте Git rebase.
|
||
|
||
Если вам необходимо сохранить полную историю проекта и избежать перезаписи публичных коммитов – используйте команду Git merge. |