SecondBrain/.trash/Система контроля версий. Знакомство с Git.md

status, type, tags, created, updated, aliases

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

Система контроля версий. Знакомство с 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.