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

|
||||||
|
|
||||||
|
**Модель 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.
|
||||||
Reference in New Issue
Block a user