Git и GitLab для начинающих: практический курс

Установка Git и настройка рабочего окружения

Представьте: вы открыли файл проекта, внесли десяток изменений, а потом поняли, что всё сломали. Идеальная версия была вчера — но её нигде не сохранили. Без системы контроля версий вы работаете вслепую, и каждое изменение — это лотерея. Git решает эту проблему раз и навсегда: он запоминает каждое состояние вашего проекта, как машина времени.

Что такое Git простыми словами

Git — это распределённая система контроля версий (distributed version control system). Распределённая означает, что полная копия истории проекта хранится на каждом компьютере разработчика, а не на одном сервере. Это принципиально отличает Git от централизованных систем вроде SVN, где без сервера вы не можете работать вообще.

Зачем вам Git, даже если вы работаете в одиночку:

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

Эксперименты: создаёте ветку, пробуете идею — если не получилось, просто удаляете ветку

История: видите, кто, когда и какие изменения внёс (даже если «кто» — это вы сами три месяца назад)

Установка Git на Windows

Скачайте установщик с официального сайта git-scm.com и запустите его. На этапе выбора редактора оставьте Notepad или выберите VS Code, если он у вас установлен. Всё остальное можно оставить по умолчанию — нажимайте Next до конца.

После установки откройте командную строку (нажмите Win + R, введите cmd) и проверьте:

Если выводится что-то вроде git version 2.43.0.windows.1 — всё установлено корректно.

Установка Git на macOS

Откройте Терминал (найдите через Spotlight: Cmd + Space, введите «Terminal») и введите:

Если Git не установлен, macOS предложит установить Xcode Command Line Tools — согласитесь. Это единственный шаг, который нужен.

Установка Git на Linux

Для Ubuntu или Debian:

Для Fedora:

Первая настройка: кто вы для Git

Git требует минимум две настройки перед первым использованием — ваше имя и email. Без них Git не даст сделать первый коммит. Эти данные будут вшиты в каждый ваш коммит навсегда.

Флаг --global означает, что настройка применяется ко всем репозиториям на вашем компьютере. Если для конкретного проекта нужен другой email (например, рабочий), можно задать его отдельно:

Настройка редактора и других полезных параметров

По умолчанию Git использует Vim для написания сообщений коммитов. Если вы не знакомы с Vim, это может стать источником стресса — вы откроете редактор и не поймёте, как из него выйти. Лучше сразу сменить редактор:

Ещё несколько полезных настроек:

Последняя настройка особенно удобна: если вы наберёте git st вместо git status, Git сам скорректирует команду через 1 секунду (10 десятых).

Проверка текущей конфигурации

Чтобы увидеть все текущие настройки Git:

Вывод будет длинным — там и имя, и email, и все остальные параметры. Если нужно проверить конкретную настройку:

SSH-ключи: подготовка к работе с GitLab

Для работы с удалёнными репозиториями на GitLab вам понадобится SSH-ключ — это способ безопасной идентификации вашего компьютера без ввода пароля каждый раз.

Генерация ключа:

Система спросит, куда сохранить ключ — нажмите Enter, приняв путь по умолчанию. Затем предложит задать пароль (passphrase) — можете оставить пустым для простоты или ввести надёжный пароль.

Теперь нужно скопировать публичный ключ:

Скопируйте вывод целиком — это длинная строка, начинающаяся с ssh-ed25519. Её нужно будет вставить в GitLab (об этом подробно в пятой статье курса).

Проверка подключения:

Если увидите сообщение Welcome to GitLab, @username! — SSH настроен правильно.

Терминал: минимум, который нужен

Git работает через командную строку. Если вы не привыкли к терминалу, вот шпаргалка по базовым командам навигации:

| Команда | Что делает | |---------|-----------| | pwd | Показывает текущую директорию | | ls | Список файлов и папок (macOS/Linux) | | dir | Список файлов и папок (Windows cmd) | | cd папка | Перейти в папку | | cd .. | Подняться на уровень выше | | mkdir имя | Создать папку |

> Не нужно знать все команды терминала наизусть. Достаточно уметь перемещаться между папками и запускать команды Git — всё остальное придёт с практикой.

Что дальше

Теперь у вас есть установленный и настроенный Git, SSH-ключ для безопасного подключения и базовые навыки работы с терминалом. Этого достаточно, чтобы создать первый репозиторий и начать отслеживать изменения в проекте — именно об этом следующий шаг курса.

Работа с репозиториями: создание и клонирование

Вы настроили Git и готовы начать. Но где хранить код? Репозиторий — это папка на вашем компьютере, в которой Git отслеживает все изменения файлов. Без репозитория Git просто не знает, за чем следить. Есть два способа получить репозиторий: создать новый с нуля или скопировать существующий с GitLab.

Создание нового репозитория

Допустим, вы начинаете личный проект — сайт-портфолио. Создайте папку и инициализируйте в ней репозиторий:

Команда git init создаёт скрытую папку .git — именно в ней Git хранит всю историю, настройки и метаданные. Не удаляйте эту папку, иначе вы потеряете всю историю проекта.

Проверьте, что репозиторий создан:

Вывод будет таким:

Git сообщает: вы на ветке main, коммитов пока нет, отслеживать нечего. Это нормально — вы только что создали пустой репозиторий.

Структура репозитория

Когда вы работаете с Git, ваши файлы находятся в одном из трёх состояний:

| Состояние | Что значит | Аналогия | |-----------|-----------|----------| | Modified (изменён) | Файл изменён, но ещё не зафиксирован | Черновик на столе | | Staged (подготовлен) | Файл помечен для включения в следующий коммит | Документ в конверте, готовый к отправке | | Committed (зафиксирован) | Изменения сохранены в истории Git | Письмо, отправленное и зарегистрированное |

Это ключевая концепция: вы не просто «сохраняете файлы» — вы проходите через три этапа. Сначала изменяете, затем подготавливаете (staging), затем фиксируете (commit). Подробно staging и коммиты разберём в третьей статье.

Клонирование существующего репозитория

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

На GitLab найдите проект, который хотите клонировать. Нажмите кнопку Clone и скопируйте ссылку. Есть два формата:

HTTPS (проще, но требует ввода credentials):

SSH (удобнее, если настроены SSH-ключи из первой статьи):

После клонирования у вас появится папка project-name с полным содержимым проекта и всей историей коммитов.

Клонирование в конкретную папку

Если вы хотите, чтобы скачанный проект лежал в папке с другим именем:

Проект скачается в папку my-local-folder вместо project-name.

Что происходит при клонировании

Когда вы клонируете репозиторий, Git делает несколько вещей автоматически:

Скачивает все файлы проекта

Скачивает всю историю коммитов (каждую версию каждого файла)

Создаёт удалённый (remote) с именем origin, указывающий на исходный репозиторий

Переключается на ветку main (или другую ветку по умолчанию)

Проверить список удалённых репозиториев можно командой:

Вывод:

origin — это стандартное имя для основного удалённого репозитория. fetch означает «откуда скачивать изменения», push — «куда отправлять свои изменения». Обычно они указывают на один и тот же адрес.

Добавление удалённого репозитория к существующему проекту

Бывает ситуация: вы создали локальный репозиторий через git init, поработали, а теперь хотите отправить его на GitLab. В этом случае нужно вручную привязать удалённый репозиторий:

Команда git remote add создаёт связь между вашим локальным проектом и удалённым репозиторием. После этого вы сможете отправлять изменения командой git push.

Проверка статуса репозитория

Команда git status — ваш главный помощник. Запускайте её постоянно, когда сомневаетесь в состоянии проекта. Она покажет:

На какой ветке вы находитесь

Есть ли несохранённые изменения

Какие файлы подготовлены к коммиту

Есть ли файлы, которые Git пока не отслеживает

Пример вывода после создания нового файла index.html:

Git говорит: «Есть файл index.html, который я пока не отслеживаю. Если хотите, добавьте его через git add».

Файл .gitignore: что не нужно отслеживать

Не все файлы в проекте стоит хранить в Git. Файлы с паролями, логи, кэш, папки с зависимостями — всё это мусорит в истории и может создать проблемы. Для исключения таких файлов используется .gitignore.

Создайте файл .gitignore в корне репозитория:

Пример содержимого для Node.js-проекта:

Каждая строка — паттерн для исключения:

node_modules/ — игнорировать всю папку

.env — игнорировать конкретный файл

*.log — игнорировать все файлы с расширением .log

.DS_Store — системный файл macOS

> Правило: никогда не коммитьте файлы с паролями, токенами и секретными ключами. Если они попали в историю Git, удалить их оттуда сложно — даже после удаления файла они останутся в истории коммитов.

Практический сценарий: начало нового проекта

Давайте соберём всё вместе. Вот типичный сценарий начала проекта:

На этом этапе у вас есть репозиторий с одним файлом README.md и настроенным .gitignore. В следующей статье мы научимся фиксировать изменения — делать коммиты.

Управление изменениями: staging, коммиты и история

Вы создали репозиторий и добавили файлы. Теперь наступает самый важный этап — фиксация изменений. Представьте, что вы пишете диплом: вы не отправляете каждое исправленное предложение научному руководителю. Вы накапливаете правки, проверяете их, и только потом сохраняете «чистовик». Git работает точно так же — через промежуточный этап staging.

Трёхэтапный процесс: изменение → staging → коммит

Разберём на конкретном примере. У вас есть проект с файлом index.html. Вы открыли его и добавили заголовок. Что происходит на каждом этапе:

Этап 1. Изменение файла. Вы редактируете index.html в любом редакторе. Git видит, что файл изменился, но пока ничего не делает.

Этап 2. Staging (подготовка). Вы говорите Git: «Я хочу включить это изменение в следующий коммит». Это как сложить вещи в чемодан перед поездкой — вы ещё не уехали, но уже решили, что берёте с собой.

Этап 3. Commit (фиксация). Вы создаёте снимок всех подготовленных изменений. Это необратимая запись в истории — как фотография, которую нельзя «отфотошопить» после щелчка затвора.

Staging: подготовка изменений

Создадим файл и посмотрим, как работает staging:

Git покажет файл в секции Untracked files — он знает о нём, но не отслеживает. Чтобы начать отслеживать, добавьте файл в staging:

Теперь git status покажет файл в секции Changes to be committed — он готов к фиксации.

Полезные варианты git add

Добавить все изменённые файлы разом:

Добавить все файлы определённого типа:

Добавить все файлы из конкретной папки:

Отменить staging (убрать файл из подготовленных, но не удалить изменения):

> Совет: используйте git add . с осторожностью. Если у вас есть файлы с паролями или логами, которые не в .gitignore, они тоже попадут в коммит. Лучше добавлять файлы по одному или проверять git status перед коммитом.

Commit: фиксация изменений

Когда нужные файлы подготовлены, создайте коммит:

Флаг -m позволяет написать сообщение коммита прямо в командной строке. Это короткое описание того, что вы сделали.

Правила хорошего сообщения коммита

Сообщение коммита — это записка для будущего вас (и ваших коллег). Через полгода вы будете благодарны за понятные описания.

| Плохо | Хорошо | |-------|--------| | fix | Исправлена ошибка валидации email на форме регистрации | | update | Добавлена пагинация на страницу списка товаров | | changes | Рефакторинг функции расчёта стоимости доставки | | asdf | (надеюсь, вы так не делаете) |

Конвенция Conventional Commits предлагает структуру: тип: описание. Типы:

feat — новая функция

fix — исправление ошибки

docs — документация

refactor — рефакторинг (без изменения поведения)

style — форматирование кода

Пример: feat: добавлена сортировка задач по дате создания

Длинное сообщение коммита

Если изменение сложное, можно написать и заголовок, и подробное описание:

Первый -m — заголовок, второй — тело. Или просто запустите git commit без флага -m — откроется редактор, где можно написать многострочное сообщение.

Просмотр истории: git log

Чтобы увидеть все коммиты в проекте:

Вывод будет примерно таким:

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

Компактный формат истории

Полный git log может быть очень длинным. Для быстрого обзора используйте:

Вывод:

Каждый коммит — одна строка: короткий хеш и сообщение. Удобно для быстрого просмотра.

Ещё полезные варианты:

Что изменилось: git diff

Перед коммитом полезно проверить, что именно вы изменили. Команда git diff показывает разницу между версиями файлов.

Изменения, которые ещё не добавлены в staging:

Изменения, которые уже в staging (готовы к коммиту):

Вывод git diff использует формат unified diff:

Строки с - — удалённые, с + — добавленные. Если вы видите только + — это новый файл.

Практический сценарий: полный цикл

Давайте пройдём полный цикл от изменения до фиксации:

Теперь изменим файл и сделаем второй коммит:

Отмена изменений до коммита

Если вы изменили файл, но передумали — верните его к последней зафиксированной версии:

Внимание: эта команда удаляет все незафиксированные изменения в файле безвозвратно. Нет кнопки «Отменить отмену».

Если вы уже добавили файл в staging, но ещё не сделали коммит:

Отмена последнего коммита

Сделали коммит и сразу поняли, что забыли добавить файл? Не проблема:

Флаг --amend заменяет последний коммит новым — с тем же сообщением, но с обновлённым содержимым. Это работает только с последним коммитом и только если вы ещё не отправили изменения на GitLab.

> Важно: не используйте --amend для коммитов, которые уже отправлены в общий репозиторий. Это создаст расхождение истории между вашим компьютером и сервером, и ваши коллеги столкнутся с проблемами.

Ветки и слияние: параллельная разработка

Представьте, что вы работаете над интернет-магазином. Сайт работает, поступают заказы. Но вам нужно добавить новую платёжную систему — это займёт неделю. Вы не можете неделю держать рабочий сайт в «полусломанном» состоянии. Ветки решают эту задачу: вы создаёте параллельную версию проекта, работаете в ней изолированно, а когда всё готово — объединяете с основной версией.

Что такое ветка

Ветка (branch) — это независимая линия разработки. По сути, это указатель на конкретный коммит. Когда вы делаете новый коммит на ветке, указатель сдвигается вперёд.

Ветка main — это основная, стабильная версия проекта. Все остальные ветки — это ответвления от неё (или друг от друга). Каждая ветка живёт своей жизнью: коммиты в одной ветке не влияют на другую.

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

Посмотреть все ветки в проекте:

Вывод:

Звёздочка * показывает текущую ветку. Создадим новую ветку для разработки платёжной системы:

Префикс feature/ — это не техническое требование, а договорённость. Так сразу понятно, что ветка добавляет новую функцию. Распространённые префиксы:

feature/ — новая функция

bugfix/ — исправление ошибки

hotfix/ — срочное исправление на продакшене

release/ — подготовка релиза

Но создать ветку — не значит переключиться на неё. Переключение:

Или современный синтаксис:

Теперь git branch покажет:

Создание и переключение в одну команду:

Работа в ветке

Находясь в ветке feature/payment-system, вы работаете как обычно — создаёте файлы, редактируете, делаете коммиты:

Этот коммит существует только в ветке feature/payment-system. Если вы переключитесь на main, файла payment.js там не будет:

Слияние веток

Когда функция готова, нужно объединить изменения с основной веткой. Это называется слияние (merge).

Git создаст новый коммит слияния, который объединяет обе истории. Теперь в main есть и payment.js, и все коммиты из feature-ветки.

Быстрое слияние (fast-forward)

Если после создания ветки main не изменилась, Git выполнит fast-forward — просто сдвинет указатель main вперёд. Никакого коммита слияния не создаётся, история остаётся линейной.

Слияние с конфликтом

Если в обеих ветках изменён один и тот же файл в одном и том же месте, Git не сможет решить, какую версию оставить. Это конфликт слияния (merge conflict). Разберём подробно.

Разрешение конфликтов

Создадим конфликт намеренно. Допустим, в main и в feature/payment-system обе изменили файл config.js:

Git сообщит:

Откройте config.js — вы увидите маркеры конфликта:

Между <<<<<<< HEAD и ======= — ваша версия (текущая ветка main)

Между ======= и >>>>>>> feature/payment-system — версия из сливаемой ветки

Вам нужно вручную выбрать правильный вариант. Отредактируйте файл, убрав маркеры:

Затем зафиксируйте разрешённый конфликт:

Стратегии предотвращения конфликтов

Конфликты неизбежны в командной работе, но их частоту можно снизить:

Синхронизируйтесь часто: регулярно делайте git pull из основной ветки, чтобы ваша ветка не отставала

Договоритесь о зонах ответственности: если два разработчика работают с разными файлами, конфликтов не будет

Делайте маленькие ветки: чем дольше ветка живёт отдельно, тем выше шанс конфликта

Удаление ветки после слияния

После успешного слияния ветка больше не нужна. Удалите её, чтобы не засорять список:

Визуализация ветвления

Когда в проекте много веток, полезно видеть их структуру в виде графа:

Вывод:

Здесь видно, что ветки разошлись от общего коммита 9h0i1j2 и пошли各自的 путями.

Практический сценарий: типичный рабочий процесс

Вот как выглядит стандартный цикл разработки с ветками:

Rebase: альтернатива слиянию

Помимо merge, есть способ перебазировать (rebase) ветку. Вместо создания коммита слияния, git rebase «переписывает» историю: берёт ваши коммиты и ставит их поверх актуальной main.

Разница между merge и rebase:

| | Merge | Rebase | |---|-------|--------| | История | Сохраняет ветвление | Делает историю линейной | | Коммиты | Создаёт коммит слияния | Переписывает коммиты | | Безопасно для общих веток | Да | Нет — не делайте rebase общедоступных веток |

> Правило: используйте merge для общих веток и rebase для личных feature-веток, которые ещё никто не видел. И никогда не делайте rebase ветки main.

Взаимодействие с GitLab: пуши, мердж-реквесты и командная работа

Вы научились работать с Git локально: создавать ветки, делать коммиты, сливать изменения. Но настоящая сила Git раскрывается, когда вы работаете в команде через GitLab — платформу, которая хранит ваш код, автоматизирует проверки и организует совместную разработку. Именно здесь локальные навыки превращаются в профессиональный рабочий процесс.

Отправка изменений: git push

Все ваши коммиты пока живут только на вашем компьютере. Чтобы поделиться ими с командой (и сохранить на сервере), нужно отправить их на GitLab командой push:

Команда отправляет коммиты из вашей локальной ветки main в удалённый репозиторий origin (который указывает на GitLab).

При первой отправке новой ветки Git может попросить указать связку:

Или короче:

Флаг -u (upstream) связывает вашу локальную ветку с удалённой. После этого достаточно писать просто git push — Git будет знать, куда отправлять.

Получение изменений: git pull и git fetch

Пока вы работали, коллеги могли отправить свои изменения. Чтобы синхронизироваться:

git pull делает две вещи: скачивает изменения с GitLab (fetch) и сливает их в вашу текущую ветку (merge). По сути, это git fetch + git merge в одной команде.

Иногда полезно разделить эти шаги:

Это даёт контроль: вы видите изменения до того, как они попадут в вашу ветку.

Pull с rebase вместо merge

Стандартный git pull создаёт коммиты слияния, которые засоряют историю. Альтернатива:

Это скачивает изменения и переставляет ваши коммиты поверх них. История остаётся линейной и чистой. Чтобы сделать это поведение по умолчанию:

Merge Request: сердце командной работы в GitLab

Merge Request (MR) — это запрос на слияние одной ветки в другую. Это не просто кнопка «слить» — это площадка для кода-ревью (code review), где коллеги проверяют ваши изменения перед включением в основную ветку.

Создание Merge Request

После того как вы отправили ветку на GitLab:

GitLab покажет уведомление: «You pushed to feature/payment-system. Create a merge request?» Нажмите кнопку или перейдите в раздел Merge Requests → New merge request.

Заполните форму:

| Поле | Что указать | |------|------------| | Source branch | feature/payment-system (ваша ветка) | | Target branch | main (куда сливать) | | Title | Краткое описание: «Добавлена платёжная система» | | Description | Подробное описание: что сделано, как тестировать, скриншоты | | Assignee | Назначьте себя или reviewer'а | | Reviewers | Коллеги, которые должны проверить код |

Описание Merge Request

Хорошее описание MR экономит время всей команды. Используйте шаблон:

Ключевое слово Closes #42 автоматически закроет задачу №42 в трекере GitLab при слиянии MR.

Код-ревью: как проверяют изменения

Когда вы создали MR, ревьюеры получают уведомление. Они открывают MR и видят diff — сравнение изменений. GitLab показывает каждый изменённый файл с выделением добавленных и удалённых строк.

Ревьюер может:

Оставить комментарий к конкретной строке кода — нажмите на номер строки в diff

Оставить общий комментарий в разделе обсуждения

Одобрить MR — кнопка Approve

Запросить изменения — оставить комментарии и отправить на доработку

Как отвечать на комментарии

Если ревьюер оставил замечание:

Внесите исправления локально

Сделайте коммит с исправлением

Отправьте на GitLab: git push

Ответьте на комментарий в GitLab: «Исправлено в коммите abc1234»

MR обновится автоматически — ревьюер увидит новые коммиты.

Настройка MR: approvals и автоматизация

GitLab позволяет настраивать правила для MR:

Обязательные одобрения: в настройках проекта можно указать, что MR требует минимум N одобрений перед слиянием. Это гарантирует, что код проверили.

Проверки при пуше (CI/CD pipelines): можно настроить автоматические проверки — запуск тестов, проверку стиля кода, сборку проекта. MR нельзя будет слить, пока все проверки не пройдут успешно.

Удаление ветки после слияния: в настройках MR поставьте галочку «Delete source branch when merge request is accepted». После слияния ветка автоматически удалится и на GitLab, и у вас локально при следующем git pull.

Стратегии слияния в GitLab

При создании MR можно выбрать стратегию слияния:

| Стратегия | Что делает | |-----------|-----------| | Merge commit | Создаёт коммит слияния, сохраняя историю ветвления | | Fast-forward merge | Сливает только если возможен fast-forward (без коммита слияния) | | Squash and merge | Объединяет все коммиты MR в один перед слиянием |

Squash and merge особенно полезен: ваша feature-ветка может содержать 15 промежуточных коммитов («WIP», «fix typo», «ещё одна попытка»), но в main попадёт один чистый коммит с понятным описанием.

Типичный рабочий день разработчика

Соберём всё в реальный сценарий. Утро, вы пришли на работу:

Разрешение конфликтов через GitLab

Если при создании MR GitLab показывает конфликт, у вас есть два пути:

Через интерфейс GitLab: нажмите кнопку Resolve conflicts. GitLab покажет конфликтные файлы с маркерами — отредактируйте прямо в браузере.

Локально (надёжнее для сложных конфликтов):

Issues и связь с кодом

Issues — это задачи, баги и предложения в GitLab. Каждый issue имеет номер (например, #42). Связывая MR с issue через ключевые слова, вы создаёте прозрачную цепочку: задача → код → проверка → закрытие.

Ключевые слова для автоматического закрытия:

Closes #42

Fixes #42

Resolves #42

Когда MR с таким описанием сливается, issue #42 автоматически закрывается. Это экономит время и не даёт задачам «зависнуть».

Безопасность: что нельзя делать

Несколько правил, которые сэкономят вам и команде часы нервов:

Никогда не пушьте в main напрямую — всегда через MR. Даже если вы единственный разработчик

Не force-push в общие ветки (git push --force). Это переписывает историю и может удалить чужие коммиты

Не коммитьте секреты — пароли, API-ключи, токены. Если случайно закоммитили — меняйте ключ немедленно, даже если удалили из кода

Не оставляйте MR открытыми на недели — маленькие и частые MR проще ревьюить и сливать

Что вы освоили

За пять статей вы прошли путь от установки Git до полноценной командной работы через GitLab. Вы умеете создавать репозитории, фиксировать изменения, работать с ветками, разрешать конфликты и использовать merge request для код-ревью. Это фундамент, на котором строится профессиональная разработка — дальше только практика.