Обзор_системы_контроля_версий_Git_1

1.

Обзор системы контроля
версий Git
Работу выполнила: студентка группы 2ПК1 Кирдан С

2.

Что такое Git?
*Это система коммитов
В программировании за сохранение кода в контрольных
точках отвечает система контроля версий — специальная
технология, которую можно подключить к любому
проекту. Система контроля версий страхует от ошибок
и возвращает код в то состояние, когда всё работало.
Контрольные точки называются коммитами. Один
коммит — это пакет изменений, хранящий информацию
с добавленными, отредактированными или удалёнными
файлами кода. В один коммит принято добавлять не более
десяти изменений — так получается длинная история
версий, которая позволяет в случае ошибки откатиться
с минимальной потерей работоспособного кода.

3.

*Это комплекс связанных веток
Коммиты располагаются на master-ветке —
основной версии проекта, которая после завершения
работы превратится в продукт.
Система контроля версий позволяет создавать
ответвления от master-ветки и экспериментировать
с проектом, не мешая другим участника команды.
Возьмём предыдущую схему, где мы обнаружили
ошибку и Откатились на коммит до ошибки. Создали
несколько веток для тестирования разных решений.
Найдя рабочее решение, перенесли его в master.
Лишние ветки можно удалить — они остаются
локальными черновиками.

4.

*Это инструмент совместного создания кода
Система контроля версий позволяет не ждать
обновления master-ветки и разрешает всем участникам
команды свободно перемещаться между ветками других
разработчиков для копирования нужных фрагментов
кода.
Бывают и обратные ситуации, когда несколько
разработчиков одновременно дописывают код, заливают
его в master-ветку и сталкиваются с конфликтом — один
файл получает несколько несогласованных изменений.
В этом случае Git попробует автоматически исправить
ошибки. Если не получится, разработчики это увидят
и смогут поправить код вручную.

5.

Как работает Git?
Системы контроля версий бывают локальными,
централизованными или распределёнными.
Локальная система хранит файлы на одном устройстве,
централизованная использует общий сервер,
а распределённая — общее облачное хранилище и локальные
устройства участников команды. В локальной системе удобно
работать с большими проектами, но сложно взаимодействовать
с удалённой командой.
В централизованной системе налажена удалённая работа,
но всё привязано к одному серверу. Любой сбой или взлом
может повредить файлы проекта.
В распределённой системе налажена удалённая работа. Если
с файлами основного репозитория что-то случится — проект
легко восстановить из копии любого участника команды.
Из-за удобства и гибкости распределённая система версий Git
считается современным форматом. Это стандарт для
большинства IT-команд.

6.

В системе Git локальные операции — это
действия, которые выполняются в локальном
репозитории разработчика, без обращения к
серверу. К таким операциям относятся
создание репозитория, добавление изменений
в индекс, создание коммитов и
синхронизация с удалённым репозиторием.
Создание репозитория
Команда git init создаёт в папке проекта скрытый репозиторий —
директорию .git, где будет храниться информация о версиях файлов.
После выполнения команды Git начнёт отслеживать изменения в
проекте.

7.

Добавление изменений
Команда git add добавляет изменённые файлы в индекс — промежуточную
зону перед репозиторием. В индекс можно добавить один файл, несколько или
все сразу. После попадания в индекс файлы становятся подготовленными к
коммиту (staged)

8.

Коммиты
Команда git commit создаёт новый
коммит с заданным сообщением.
Сообщение коммита описывает,
какие изменения были внесены и
почему.
Важно: до выполнения команды
локальные изменения никуда не
запишутся

9.

Синхронизация
Git pull обновляет текущую локальную рабочую
ветку и все удалённые отслеживаемые
ветки. Рекомендуется регулярно запускать Git pull
для веток, с которыми вы работаете локально.
Без Git pull или его эквивалента) в вашей
локальной ветке не будет обновлений, которые
есть в удалённой ветке.
Когда использовать git pull:
Для получения последних актуальных
изменений — при командной работе участники
проекта периодически вносят изменения, и
нужно получить все последние изменения в
локальный репозиторий.
Для быстрого обновления ветки — если
необходимо быстро актуализировать ветку без
предварительного анализа.

10.

Три состояния Git
Git управляет файлами через три основных состояния, обеспечивая полный контроль над изменениями кода.
Working Directory
Staging Area
Git Repository
Рабочая директория содержит
текущие версии файлов проекта, с
которыми вы непосредственно
работаете.
Промежуточная область для
подготовки изменений к коммиту.
Здесь формируется снимок
будущего коммита.
Локальное хранилище, где Git
сохраняет метаданные и базу
данных объектов проекта.

11.

Установка Git и первые шаги
Установка системы
Добавление данных
Git доступен для всех основных
операционных систем. После
установки необходимо
настроить базовую
конфигурацию пользователя.
Процесс фиксации изменений в
Git включает добавление
файлов в staging area и создание
коммита.
• git config --global user.name
"Ваше имя"
• git config --global user.email
"email@example.com"
• git init - создание
репозитория
• git add . - добавить все
файлы
• git commit -m "сообщение" создать коммит
• git status - проверить
состояние

12.

После установки нужно проверить, что Git корректно работает: открыть
командную строку и ввести git --version. Если указана установленная версия,
значит всё прошло успешно.
Настройка
После установки Git необходимо настроить его для работы с именем
пользователя и электронной почтой. Это нужно, чтобы в истории репозитория
коммиты отражались под именем и почтой.
Самый удобный способ изменения конфигурации — встроенная утилита git config.
Настройки Git имеют три уровня:
Параметры из файла [path]/etc/gitconfig (системные) могут работать для всех
пользователей системы и репозиториев. Они редактируются командой git config –
system.
Параметры из файла ~/.gitconfig или ~/.config/git/config (глобальные) применяются к
одному пользователю, если запустить команду git config –global.
Локальные параметры из файла config в рабочем каталоге .git/config сохраняют
только для выбранного репозитория. Ему соответствует команда git config —local.
Если запускать git config без параметров, будет использоваться локальный уровень,
никакие из более глобальных настроек не изменятся.

13.

14.

15.

Протоколы передачи данных
Git поддерживает несколько протоколов для взаимодействия с
удалёнными репозиториями, каждый со своими особенностями.
HTTP/HTTPS
Простой в настройке протокол,
работает через веб-интерфейс.
Поддерживает аутентификацию
через логин/пароль или токены.
• Легкая настройка
• Работа через файрволы
• Медленнее SSH
SSH
Самый популярный протокол
для разработчиков. Использует
ключи для аутентификации,
обеспечивая высокую
безопасность.
• Высокая безопасность
• Быстрая работа
• Требует настройки ключей
Git Protocol
Специальный протокол Git для максимальной скорости передачи
данных. Используется редко из-за отсутствия аутентификации.
• Максимальная скорость
• Нет аутентификации
• Только для чтения

16.

GitHub: мощная платформа разработки
Хостинг репозиториев
Облачное хранение Git-репозиториев с веб-интерфейсом для
управления кодом, версиями и совместной работы команды.
Совместная разработка
Инструменты для code review, issue tracking, wiki, и управления
проектами. Поддержка pull requests и merge requests.
CI/CD интеграция
GitHub Actions для автоматизации сборки, тестирования и
развертывания. Интеграция с популярными инструментами
DevOps.

17.

GitHub — это облачная платформа для хостинга ITпроектов и совместной разработки, под капотом которой
находится популярная система контроля версий Git,
а также полноценная социальная сеть для разработчиков.
Здесь можно найти кучу open-source-проектов на разных
языках и поучаствовать в них, разместить своё портфолио
с примерами кода, чтобы приложить ссылку к резюме,
подглядывать в открытых проектах интересные
архитектурные решения, смотреть, как опытные
разработчики пишут код, и скачивать огромное количество
полезных в разработке и бесплатных инструментов для
разработки.

18.

19.

GitLab: полнофункциональная DevOps платформа
GitLab предоставляет полный цикл разработки - от планирования до
мониторинга. Доступен как облачный сервис и для самостоятельного
размещения.
01
Планирование
Issue boards, milestone tracking, time tracking
02
Разработка
Git repository, merge requests, code review
03
Автоматическая сборка, тестирование, развертывание
04
Мониторинг
Performance monitoring, error tracking

20.

Git хуки: автоматизация процессов
Хуки позволяют автоматически выполнять скрипты на различных этапах
работы с Git, обеспечивая контроль качества и автоматизацию рутинных
задач.
1
pre-commit
Выполняется перед созданием коммита. Проверка стиля
кода, запуск линтеров, валидация сообщений.
2
pre-push
Запускается перед отправкой изменений в
удаленный репозиторий. Запуск тестов, проверка
безопасности.
3
post-receive
Серверный хук, выполняется после получения
push. Автоматическое развертывание,
уведомления команды.

21.

GitHub API: программное
взаимодействие
REST API возможности
GraphQL API
Современный подход к API,
• Управление репозиториями и
позволяющий получать точно те
файлами
данные, которые нужны, одним
• Работа с issues и pull requests
запросом.
• Управление пользователями и
query { repository(owner:
командами
"user", name: "repo") {
• Получение статистики и аналитики
issues(first: 10) { nodes {
title state } } }}

22.

Администрирование проекта
Эффективное управление проектом включает настройку прав доступа,
организацию команд и контроль безопасности.
Управление пользователями
Создание команд, назначение ролей, управление доступом к репозиториям.
Интеграция с корпоративными системами аутентификации.
Безопасность
Настройка branch protection rules, обязательный code review, проверка на
уязвимости, двухфакторная аутентификация.
Конфигурация
Настройка webhooks, интеграций, templates для issues и PR, автоматических
проверок качества кода.

23.

Журнал регистрации (log) в системе контроля версий
Git — это запись истории коммитов (изменений в
репозитории). Он помогает разработчикам понимать, какие
изменения были внесены, кто их сделал и когда.
В Git коммиты связаны как цепочка: A → B → C.
Ветвь — это просто указатель на конкретный
коммит (например, на C), что делает создание
веток очень легким.
Главное отличие Git от централизованных систем
(CVCS) в том, что у каждого разработчика есть
полная локальная копия репозитория. Чтобы
синхронизировать её с удалённым репозиторием
(обычно называемым origin), используется
команда:
git pull origin main
Эта команда загружает новые коммиты из
удалённой ветки main и перемещает вашу
локальную ветку на самый свежий коммит.

24.

25.

26.

27.

Запросы на включение изменений (pull requests) в
системе Git (GitHub) — это механизм, который позволяет
разработчикам предлагать изменения (новый код,
исправления ошибок или улучшения) другим участникам
проекта для проверки, обсуждения и одобрения. Термин
образовался из сочетания английских слов pull («тянуть»)
и request («запрос»)
Примеры использования:
участник внёс исправления в код проекта и отправил запрос на
их включение в основную версию;
добавил новую функциональность в проект и предложил её
для рассмотрения перед использованием;
обновил документацию в проекте и хочет, чтобы изменения
были просмотрены и приняты.

28.

Шаг 1: Создание ветки и внесение изменений
Шаг 2: Создание Pull Request в интерфейсе GitHub

29.

Шаг 3: Заполнение формы Pull Request

30.

Рассмотрение
После создания pull request другие участники проекта
могут просмотреть и обсудить изменения. Некоторые
возможности:
Просмотр предлагаемых изменений — можно просматривать и
обсуждать фиксации, изменённые файлы и различия (diff) между
файлами.
Комментирование — участники могут комментировать сравнение
файлов между двумя указанными ветвями или добавлять
комментарии общего характера к проекту в целом.
Проверка изменений зависимостей — если запрос содержит
изменения зависимостей, можно просмотреть сводку изменений,
чтобы узнать о наличии известных уязвимостей в любой из
зависимостей.

31.

Разрешение
Запрос на включение изменений (pull request) может быть принят или
отклонён:
Принять — участники утверждают изменения.
Отклонить — можно указать, какие изменения необходимо внести. Для
возможности слияния в основную ветку человек, отклонивший запрос,
должен обязательно снова его просмотреть и утвердить.
Если для репозитория требуются проверки, запросы на включение
изменений должны содержать определённое количество утверждений от
пользователей с разрешениями на запись или разрешениями
администратора для репозитория, прежде чем их можно будет объединить