Dmitry
86 lines
6.4 KiB
Markdown
86 lines
6.4 KiB
Markdown
---
|
|
status: seed
|
|
type: concept
|
|
tags: []
|
|
created: 2025-12-17
|
|
updated: 2026-04-30
|
|
aliases:
|
|
- Git
|
|
---
|
|
# Git
|
|
## Знакомство с Git
|
|
|
|
**Git** — система управления версиями с распределенной архитектурой, разработанная Линусом Торвальдсом в 2005 году.
|
|
|
|
Среди всех доступных систем управления версиями (*Git*, *Mercurial*, *CVS*, *SVN*), Git является абсолютным лидером и признанным стандартом.
|
|
|
|
Неоспоримыми преимуществами Git являются:
|
|
|
|
- Высокая производительность.
|
|
- Безопасность.
|
|
- Гибкость в распределенных системах.
|
|
- Прекрасные возможности для командной работы.
|
|
|
|
### Производительность
|
|
|
|
Высокая производительность Git обусловлена подходом по *оптимизации* *внутренних* *процедур* и использованию анализа содержимого файлов Git работает с файлами, храня объекты с содержимым каталога и метаданными их версий.
|
|
|
|
### Безопасность
|
|
|
|
Безопасность при работе с Git обеспечивается целостностью исходного кода и применением алгоритма шифрования SHA1.
|
|
Использование Git гарантирует подлинность истории изменений и защищает исходный код от тайного внесения изменений.
|
|
|
|
### Гибкость
|
|
|
|
Гибкость при работе с Git достигается за счет поддержки линейных и нелинейных циклов разработки, совместимости со множеством других информационных систем и популярных протоколов.
|
|
|
|
### Возможности для командной работы
|
|
|
|
Git обладает впечатляющими возможностями для командной работы за счет поддержки множества разнообразных моделей управления исходным кодом, удовлетворяющих нужды больших и маленьких команд, простых и сложных распределенных проектов.
|
|
|
|
## Модели управления исходным кодом
|
|
|
|
Работа с версиями исх. кода в git построена на основе использования:
|
|
- коммитов (*commit*)
|
|
- веток (*branches*)
|
|
- слияния веток (*merge*)
|
|
- сравнивания версий (*diff*)
|
|
|
|
На основе этих сущностей строятся разнообразные *модели управления исходным кодом*.
|
|
|
|
Большой популярностью пользуется модель под названием *gitflow*.
|
|
|
|
### GitFlow
|
|
|
|
**gitflow** - модель ветвления в git, в которой используются *основные ветки* (main, release, develop) и *функциональные* (features, fix).
|
|
|
|
1) *main* - официальная история релизов;
|
|
2) *release* - концентрация готового к выпуску в прод функционала;
|
|
3) *develop* - ветка для разработки функционала;
|
|
4) *feature* - работа над любым новым функционалом ведется командой в этой ветке, после завершения разработки, ветка сливается с develop-ветки.
|
|
|
|
Когда в *Develop*-ветке оказывается достаточно функционала для выпуска нового релиза, на основе *Develop*-ветки создается ветка *Release*.
|
|
|
|
После прохождения всех тестов и проверок, *Release*-ветка сливается с остальными основными ветками — *Main* и *Develop*.
|
|
|
|
![[Pasted image 20260430152221.png|597]]
|
|
Недостатки *gitflow*:
|
|
1) Не очень хорошая совместимость с CI/CD;
|
|
2) Не для рабочих процессах, связанных с редким выпуском релизов;
|
|
3) Потенциально запутанная схема веток и трудности в восстановлении историчности их слияний в сложных проектах.
|
|
|
|
Предпочтительной моделью сегодня стала модель магистральных рабочих процессов (**TBD**).
|
|
|
|
### TBD
|
|
|
|
**TBD (Trunk Based Development)** - альтернативная модель управления исходным кодом в git на основе ветвления (как замена gitflow).
|
|
Основана на принципе одной главной ветки, называемой "магистралью" (**trunk**).
|
|
|
|
Вся работа над новым функционалом ведется разработчиками в магистральной ветке, что исключает ошибки слияния и неработающие сборки.
|
|
|
|
Команда разработки, ведущая работу над функционалом, сохраняет свои изменения только в **trunk-ветку** и обеспечивает непрерывную сборку, тестирование и доставку нового функционала, не привязываясь к срокам и частоте выпуска релизов (выпуск релиза в любой момент).
|
|
|
|
![[Pasted image 20260430153712.png]]
|
|
|
|
Модель TBD быстро завоевала популярность в разветвленных проектах и прекрасно зарекомендовала себя в распределенных больших командах разработки за счет своей понятности, динамичности и совместимости с CI/CD-процессами.
|