Глава 2. Системы контроля версий

1. Цель занятия и обзор плана

На этом занятии мы разберемся, зачем нужны системы контроля версий, где они применяются, и освоим базовые операции в Git и GitLab — клонирование, коммит, push.

1.1. Обзор плана занятия

Введение: зачем нужны системы контроля версий
Где они применяются: примеры из программирования и инженерии
Основные понятия Git: репозиторий, commit, push, branch
GitLab и совместная работа
Практическая часть:
- подключение к серверу (логин/пароль или SSH-ключ);
- клонирование репозитория;
- внесение изменений и сохранение коммита;
- отправка изменений на сервер (push);
- наблюдение результата на GitLab.

2. Теоретический материал

2.1. Зачем нужны системы контроля версий

Представьте, что вы работаете над проектом, где много файлов, и время от времени нужно вернуть старую версию.

Чтобы не потерять нужные изменения, часто приходится копировать папки и придумывать имена вроде проект_новый, проект_финал, проект_финал2.

Разработка ПО, в каком-то смысле, так же является написанием текстов, и при разработке сложностей ещё больше (как минимум - нам надо синхронизировать труд нескольких программистов).

В итоге возможны два варианта:

Придумать надёжную систему, в которой будет удобно хранить все версии.
Запутаться окончательно и хранить кучу файлов, больше напоминающую мусор, и бояться удалить что-то важное.

Второй путь --- не наш, значит остаётся первый путь. Хорошая новость заключается в том, что первый путь уже давно пройден людьми, которые значительно опытнее и умнее нас, а нам остаётся только по нему пройти.

Этот путь --- использование систем контроля версий (СКВ или VCS).

Зачем вообще нужны системы контроля версий

Системы контроля версий решают целый ряд организационных и технических проблем, которые возникают при работе над проектами, состоящими из множества файлов и участников. Ниже перечислены основные из них.

Потеря данных и изменений

Когда проект развивается, файлы часто изменяются, и существует риск потерять важные данные. Без СКВ участники копируют папки вручную, создавая хаос с версиями вроде проект_финал, проект_финал_новый, проект_точно_финал. Система контроля версий сохраняет все этапы развития проекта, что позволяет в любой момент восстановить любую версию.

Несогласованная работа в команде

Если несколько человек редактируют одни и те же файлы, возникает конфликт — чьи изменения считать правильными? СКВ позволяют объединять разные правки, фиксировать их авторов и автоматически показывать различия между версиями. Это делает возможной работу десятков участников без постоянных накладок и перезаписи данных.

Отсутствие истории и ответственности

Без контроля версий невозможно понять, кто, когда и зачем изменил тот или иной файл. СКВ сохраняют подробную историю изменений: имя автора, дату, комментарий и конкретные различия в коде или тексте. Это повышает прозрачность, облегчает поиск ошибок и улучшает дисциплину в команде.

Параллельная разработка

Во многих проектах нужно вести несколько направлений работы одновременно — например, поддерживать текущую стабильную версию и разрабатывать новую. Системы контроля версий позволяют создавать параллельные линии развития проекта и затем объединять их. Такая гибкость особенно важна для сложных инженерных и программных систем.

Исправление ошибок и откат к стабильным версиям

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

Совместная работа и координация

Современные проекты часто выполняются большими распределёнными командами. Системы контроля версий предоставляют механизм синхронизации и обмена изменениями между участниками, позволяя им работать независимо и при этом сохранять единое состояние проекта.

Контроль качества и автоматизация

На основе систем контроля версий можно выстраивать автоматическую проверку, тестирование и сборку проектов. Каждое изменение может сопровождаться автоматической проверкой, что помогает поддерживать стабильность и качество продукта.

2.2. Историческая справка

Первые системы контроля версий появились ещё в 1970-е годы, когда разработка программ стала командной работой, а исходный код — сложным и постоянно меняющимся.

Одной из первых таких систем была SCCS (Source Code Control System), созданная в компании AT&T в 1972 году. Она позволяла сохранять разные версии файлов и восстанавливать их при необходимости.

Современные системы контроля версий строятся на схожих принципах, но стали быстрее, удобнее и приспособлены к работе через интернет, с десятками и сотнями участников.

2.3. Почему мы будем использовать Git

Git — это современная система контроля версий, созданная в 2005 году Линусом Торвальдсом — тем самым программистом, который разработал операционную систему Linux.

В начале 2000-х разработчики ядра Linux столкнулись с проблемой: существующие системы контроля версий были медленными и зависели от центрального сервера. Торвальдс создал Git как инструмент, который должен быть:

очень быстрым
полностью распределённым (каждый участник хранит полную копию истории проекта)
надёжным и защищённым от потери данных

Git быстро стал стандартом в мире программирования. Сегодня его доля на рынке СКВ (по разным оценкам) от 80% до 95% — т.е. это самая популярная система контроля версий.

Мы будем работать именно с Git, потому что он:

бесплатный и открытый
одинаково хорошо работает на Windows, Linux и macOS
даёт возможность учиться на тех же принципах, по которым работают профессиональные разработчики и инженеры по всему миру
позволяет легко организовать совместную работу через наш сервер (GitLab), сохраняя при этом всю историю проекта на каждом компьютере участника

2.4. Основные понятия Git

Чтобы понимать, как работает система контроля версий, важно разобраться в нескольких базовых терминах. Git хранит проект в виде снимков состояния (версий), позволяя перемещаться между ними и передавать изменения другим участникам.

Рисунок 1. Схема локальных и удалённых репозиториев

Рисунок 2. Схема локальных и удалённых репозиториев

Репозиторий

Репозиторий — это хранилище проекта и всей его истории изменений. В нём находятся все файлы, папки и метаданные о том, кто и когда их изменял.

Репозиторий может быть:

локальным — на вашем компьютере;
удалённым — на сервере, куда отправляются изменения для совместной работы.

Каждый участник имеет свою копию репозитория и может работать независимо от других, синхронизируя изменения позже.

Commit (коммит)

Коммит — это сохранение набора изменений в истории проекта. Он содержит:

список изменённых файлов,
дату и имя автора,
комментарий с описанием, что было сделано.

Можно представить коммит как снимок состояния проекта в определённый момент времени. Коммиты образуют цепочку, где каждый следующий основан на предыдущем.

На курсе рекомендуем придерживаться следующих рекомендаций:

Коммиты должны быть атомарными.

Это значит: в каждом коммите должно быть одно логически завершённое изменение. Пример неправильного коммита: "Добавлен расчёт квадратного корня и исправлены опечатки". В таком коммите имеются следующие проблемы:

здесь сразу две разные задачи: новая функция и правки текста;
если нужно будет отменить одно из изменений, сделать это будет сложно.

Правильнее бы было разделить на два коммита: "Добавлен расчёт квадратного корня" и отдельный коммит: "Исправлены опечатки в комментариях".

Формулируйте комментарии по правилу “Если применить этот коммит, то будет…”

Описание должно читаться как продолжение фразы:

“Если применить этот коммит, то будет…”

Например: "Добавлена ссылка на автора исходного текста"

(Если применить этот коммит, то будет добавлена ссылка на автора исходного текста)

Пишите:

с большой буквы в начале;
без точки в конце;
кратко и по сути (до 50–70 символов);
в настоящем времени — будто вы описываете, что делает изменение.

Примеры хороших сообщений:

Исправлена ошибка при вводе отрицательных чисел
Добавлено отображение даты последнего сохранения
Удалён лишний файл примера

Push (отправка изменений)

Когда вы делаете коммиты локально, они сохраняются только в вашей копии проекта. Команда push («толкнуть») отправляет эти изменения на удалённый сервер, где они становятся видимыми для других участников.

Таким образом:

commit — это сохранение локально,
push — это передача изменений в общий репозиторий.

Ветка (branch)

Ветка — это отдельная линия развития проекта. В ней можно экспериментировать, добавлять новые функции или исправлять ошибки, не мешая основной версии.

Обычно существует главная ветка (main или master) и дополнительные ветки для разработки отдельных функций (feature-login, fix-typo и т.п.). Когда работа завершена, ветку можно объединить с основной (операция merge).

Правило курса: названия веток пишутся на английском языке, начинаются с маленькой буквы, слова разделяются нижним подчеркиванием: “ivanov_fix_typo”.

Git flow

Рисунок 3. Схема работы по процессу git flow

Git Flow — это удобная схема организации работы с ветками в Git, которая помогает команде сохранять порядок в проекте. Она задаёт правила, какие ветки должны существовать, как и когда их объединять.

Эта модель была предложена разработчиком Винсентом Дриссеном (Vincent Driessen) и стала одним из самых популярных подходов к работе с Git.

Главная мысль Git Flow — разделить постоянные ветки проекта и временные. Постоянные ветки хранят стабильные версии программы, а временные — используются для разработки, исправлений и экспериментов.

main (или master) — главная ветка, в ней хранятся только стабильные версии, которые готовы к использованию или выпуску. На схеме это верхняя линия с коммитами A1, A2, A3, A4.
feature-ветки — создаются для добавления отдельных функций. Например, «feature-1», «feature-2», «feature-3» на схеме. Они начинаются от стабильной версии (A1 или A2), затем в них выполняются изменения (B1, B2, C1, C2, D1), а после завершения работа вливается обратно в основную ветку.

В текущем задании (и далее на курсе) мы будем работать по процессу Git Flow.

2.5. Что такое GitLab и где мы будем работать

GitLab — это веб-платформа для работы с системой контроля версий Git. Она объединяет в себе инструменты для хранения репозиториев, командной работы и автоматической проверки проектов. GitLab позволяет:

хранить проекты централизованно на сервере;
отслеживать историю изменений и участников;
комментировать и обсуждать правки;
автоматически собирать и тестировать программы (через систему CI/CD).

Можно сказать, что GitLab — это «рабочая площадка» для всей команды, где каждый видит общий проект, свои задачи и результаты других участников.

В рамках курса мы будем работать на сервере студенческого конструкторского бюро Санкт-Петербургского морского технического университета:

https://sdb.smtu.ru/gitlab/

2.6. Что такое Merge Request и зачем он нужен

Когда несколько человек работают над одним проектом, важно не только вносить изменения, но и делать это аккуратно — чтобы никто случайно не повредил чужую работу. Для этого в GitLab используется механизм Merge Request (сокращённо MR), что в переводе означает «запрос на слияние».

Merge Request — это специальный запрос, который отправляется, когда вы хотите объединить свою ветку (например, ivanov) с основной (main или develop). Он создаётся на сервере GitLab и позволяет другим участникам просмотреть, обсудить и одобрить ваши изменения перед тем, как они попадут в основную версию проекта (процедура Code Review).

На практике это выглядит так: . Вы работаете в своей ветке, выполняете нужные задачи и делаете коммиты. . Когда работа закончена, вы отправляете изменения на сервер (git push origin ivanov). . На сайте GitLab появляется кнопка Create merge request — вы нажимаете её, чтобы создать запрос на слияние. . Преподаватель или другой участник проверяет ваш код, оставляет комментарии или одобряет изменения. . После одобрения ветка объединяется с основной.

Merge Request решает сразу несколько важных задач:

Контроль качества. Перед слиянием другие участники могут проверить код и убедиться, что он работает правильно.
Обсуждение изменений. В комментариях к MR можно задать вопросы, предложить улучшения или объяснить решения.
Прозрачность. Все видят, какие изменения готовятся и кто их предложил.
Безопасность. Основная ветка проекта защищена: изменения попадают в неё только после проверки.

3. Практическое занятие

3.1. Клонирование репозитория

В домашнем задании прошлого занятия, вам нужно было склонировать репозиторий. Возможно, на тот момент вы плохо представляли, что делаете, но сейчас вы это делаете более осознанно.

Используем команду:

$ git clone адрес_репозитория

После выполнения появляется локальная копия проекта, при помощи команд cd, ls исследуйте склонированный проект, и найдите файл README.md

Что такое папка .git

Когда вы создаёте репозиторий Git (например, командой git init или git clone), внутри папки проекта появляется скрытая директория с именем .git - вы могли найти её при исследовании репозитория.

Это — сердце репозитория. В ней хранится вся информация, которая делает Git возможным:

история всех коммитов (в виде специальных записей);
данные о ветках, тегах и авторах;
ссылки на удалённые репозитории;
временные файлы, которые Git использует для сравнения и слияния изменений.

Если удалить папку .git, проект останется на диске, но Git «забудет» всю историю и перестанет считать эту папку репозиторием. Поэтому .git — это не просто техническая деталь, а вся память проекта.

Для обычной работы эту папку открывать не нужно, но важно знать, что именно она хранит весь «внутренний мозг» системы контроля версий.

3.2. Просмотр истории изменений

$ git log

Рисунок 4. История репозитория в терминале

Рисунок 5. История репозитория в gitlab

Создание и переключение на собственную ветку

В этом задании вы создадите свою личную ветку в репозитории. Ветка позволит вам работать независимо от основной версии проекта, не мешая другим участникам.

Создайте новую ветку с названием, соответствующим вашей фамилии, и переключитесь на неё. Например, если ваша фамилия Иванов, ветка должна называться ivanov.

Помните о правилах именования веток на курсе.

Пошаговая инструкция

Убедитесь, что вы находитесь в папке репозитория.
```
$ cd имя_папки_проекта
```
Проверьте, в какой ветке вы находитесь сейчас:
```
$ git branch
```
Звёздочкой (*) будет отмечена активная ветка — обычно это main.
Создайте новую ветку с вашей фамилией:
```
$ git branch ivanov
```
(замените ivanov на свою фамилию латинскими буквами).
Переключитесь на созданную ветку:
```
$ git checkout ivanov
```
Убедитесь, что переключение прошло успешно:
```
$ git branch
```
Теперь звёздочка должна стоять рядом с вашей веткой (* ivanov).

3.3. Внесение изменений и коммит

Откройте файл при помощи редактора nano и исправьте в нём несколько опечаток.

$ git commit -am "Изменен файл README"

Помните о правилах именования коммитов!

Если вы ранее не делали коммитов, то git попросит вас указать имя и пароль. Сделайте это:

$ git config --global user.name "Ваше Имя"
$ git config --global user.email "ваша@почта.com"

3.4. Отправка изменений на сервер

$ git push

После этого вы получите следующее сообщение:

$ git push
fatal: The current branch mnc has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin ivanov

To have this happen automatically for branches without a tracking
upstream, see 'push.autoSetupRemote' in 'git help config'.

Вам действительно нужно прислушаться к рекомендации (это нужно делать только для новой ветки):

$ git push --set-upstream origin ivanov

Либо можно каждый раз выполнять push следующим образом:

$ git push origin ivanov

После выполнения проверяем на GitLab, что изменения появились в репозитории.

3.5. Наблюдение результатов

Открываем проект на GitLab, вкладку Code→branches. Видим свою ветку, свои коммиты, имя автора, время и комментарий.

3.6. Сделать merge request

Далее вам нужно перейти в GitLab и сделать merge request (см. скриншот).

4. Шпаргалка

5. Домашнее задание

Для того, чтобы закрепить навыки, полученные на этом занятии, вам нужно:

$ git clone http://sdb.smtu.ru/gitlab/marinerobotics/lesson-02.git

склонировать репозиторий
создать новую ветку, используя ваши ФИО
отредактировать файл README.md
сделать commit и push
проконтролировать появление ветки на gitlab
сделать merge request в gitlab
задача со звёздочкой: поработать не через логин-пароль а через ssh

6. Дополнительные материалы

Как работать с gitlab через ssh - чтобы не вводить каждый раз логин и пароль

https://docs.gitlab.com/ee/user/ssh.html

https://docs.gitlab.com/ee/user/ssh.html

Книга "ProGit"

https://git-scm.com/book/ru/v2

https://git-scm.com/book/ru/v2