Git и GitLab: Практическое руководство для разработчиков на Windows

Установка и настройка Git в Windows и интеграция с VS Code

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

Скачивание и установка Git

Перейдите на официальный сайт Git и скачайте установщик для Windows. На момент написания актуальная версия — 2.x. Запустите .exe-файл и пройдите по шагам мастера установки.

Большинство параметров можно оставить по умолчанию, но на нескольких экранах стоит обратить внимание:

| Экран установки | Рекомендуемый выбор | Зачем | |---|---|---| | Default editor | Visual Studio Code | Git будет открывать VS Code для редактирования сообщений коммитов | | Initial branch name | Override — main | Современный стандарт вместо устаревшего master | | PATH environment | Git from the command line and also from 3rd-party software | Команды Git будут доступны в любом терминале | | HTTPS transport | Use the OpenSSL library | Стандартное шифрование для работы с GitLab | | Line ending conversions | Checkout Windows-style, commit Unix-style | Корректная работа переносов строк между Windows и Linux |

После установки откройте PowerShell или CMD и проверьте:

Если выводится версия — всё установлено корректно.

Первая конфигурация Git

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

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

Полезно сразу настроить поведение по умолчанию при git pull:

Эта настройка говорит Git'у использовать rebase вместо создания лишних merge-коммитов при получении изменений из удалённого репозитория. На практике это даёт более чистую историю.

Проверьте все настройки командой:

Установка Visual Studio Code

Скачайте VS Code с официального сайта и установите. На этапе выбора дополнительных параметров отметьте галочками:

После первого запуска VS Code уже содержит встроенный терминал и базовую поддержку Git. Но для полноценной работы стоит установить несколько расширений.

Расширения для работы с Git

Откройте панель расширений в VS Code (Ctrl+Shift+X) и установите:

GitLens — самое важное расширение. Оно добавляет информацию о каждом авторе прямо в код: кто и когда написал конкретную строку. Это называется blame — при наведении на строку вы увидите, кто её создал, в каком коммите и когда. GitLens также показывает историю файла, сравнение версий и граф веток.

Git Graph — визуализация истории репозитория в виде дерева. Удобно, когда в проекте работают несколько человек и создаются параллельные ветки.

После установки расширений перезапустите VS Code.

Интеграция Git с терминалом VS Code

VS Code имеет встроенный терминал (Ctrl+ — обратный апостроф). По умолчанию он открывает PowerShell. Этого достаточно для большинства Git-операций, но можно настроить Git Bash — оболочку, которая даёт Unix-подобные команды на Windows.

Для смены терминала нажмите стрелку рядом с плюсом в терминале и выберите Git Bash. Теперь вы можете использовать команды вроде ls, cat, grep прямо на Windows — это экономит время, когда вы следуете инструкциям, написанным для Linux.

Проверка интеграции

Создайте тестовую папку, откройте её в VS Code и инициализируйте Git:

Теперь создайте файл index.html с любым содержимым. В панели Source Control (иконка с тремя точками-ветками слева) вы увидите файл с пометкой U (untracked) — VS Code автоматически распознал, что Git отслеживает эту папку.

> Если панель Source Control показывает ошибку «Git not found», проверьте, что Git добавлен в переменную PATH. Откройте системные настройки → Переменные среды → Path и убедитесь, что там есть путь к папке bin внутри директории установки Git.

Настройка SSH-ключа для GitLab

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

Сгенерируйте ключ в терминале:

Нажмите Enter три раза (принять путь по умолчанию, без парольной фразы — для упрощения, или задайте passphrase для безопасности). Ключи сохранятся в C:\Users\Имя\.ssh\`.

Скопируйте публичный ключ:

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

Что дальше

Инструменты установлены и настроены. VS Code видит Git, терминал работает, SSH-ключ готов. В следующей статье мы создадим первый репозиторий, сделаем несколько коммитов и посмотрим, как Git хранит историю изменений.

Основы Git: инициализация репозитория, коммиты и история изменений

Когда вы работаете над документом в Word, вы периодически нажимаете Ctrl+S. Но что если вы хотите вернуться к версии от вчерашнего дня? Или сравнить, что изменилось за неделю? Обычное сохранение файла этого не даёт. Git решает именно эту задачу — он не просто сохраняет текущее состояние, а фиксирует снимки всего проекта в разные моменты времени, связывая их в цепочку.

Инициализация репозитория

Репозиторий — это папка проекта, в которой Git отслеживает изменения. Создать его можно двумя способами.

Первый способ — инициализировать в существующей папке:

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

Второй способ — клонировать существующий репозиторий (подробнее в статье о GitLab):

После git init создайте файл .gitignore — он говорит Git'у, какие файлы игнорировать. Например, для Node.js-проекта:

Без .gitignore в репозиторий попадут временные файлы, папки зависимостей и другие ненужные данные. Сайт gitignore.io генерирует готовые шаблоны под разные технологии.

Три области Git

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

Working directory (рабочая директория) — ваши файлы в папке проекта. Всё, что вы видите в проводнике.

Staging area (область подготовки) — промежуточная зона, куда вы отбираете файлы для следующего коммита. Это как корзина в магазине: вы кладёте туда товары, но ещё не оплатили.

Repository (репозиторий) — зафиксированная история. Сюда попадают только те изменения, которые вы сознательно закоммитили.

Переход между областями выглядит так:

Первый коммит

Создайте файл app.js с любым содержимым и выполните:

Git покажет, что app.js — untracked (неотслеживаемый). Добавьте его в staging:

Теперь git status покажет файл в секции Changes to be committed. Зафиксируйте изменение:

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

> Хорошее сообщение коммита отвечает на вопрос: «Если применить этот коммит, что изменится в проекте?» Плохо: «фикс». Хорошо: «Исправлена валидация email при регистрации».

Просмотр истории

Посмотреть все коммиты можно командой:

Вывод будет длинным — хеш, автор, дата, сообщение. Для компактного просмотра используйте:

Каждый коммит отобразится одной строкой: короткий хеш и сообщение. Это удобно для быстрого ориентирования в истории.

В VS Code история доступна через панель Source Control → иконка ветки внизу слева → View Branch History. С расширением Git Graph вы получите наглядное дерево коммитов.

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

Перед коммитом полезно проверить, что именно изменилось:

Покажет разницу между рабочей директорией и последним коммитом. Если файл уже добавлен в staging, используйте:

В VS Code это работает ещё проще: кликните на файл в панели Source Control, и откроется inline diff — удалённые строки будут подчёркнуты красным, добавленные — зелёным.

Отмена действий

Git позволяет откатить практически любое действие.

Убрать файл из staging (но не удалить сам файл):

Отменить изменения в рабочей директории (вернуть файл к состоянию последнего коммита):

> Внимание: git restore без флага --staged перезаписывает файл. Если вы написали код и не закоммитили — он пропадёт безвозвратно.

Изменить последний коммит (например, исправить опечатку в сообщении):

Это перезапишет последний коммит. Не используйте --amend для коммитов, которые уже отправлены в удалённый репозиторий — это нарушит историю у других участников.

Практический сценарий

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

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

Работа с ветками и слияние кода в VS Code

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

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

Ветка — это указатель на конкретный коммит. Когда вы создаёте ветку, Git просто ставит ещё одну метку на текущий коммит. Никакого копирования файлов не происходит — это мгновенная и дешёвая операция.

По умолчанию в репозитории есть ветка main (или master в старых проектах). Она считается основной и содержит стабильный, работающий код.

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

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

Эта команда делает две вещи: создаёт ветку feature/cart из текущей позиции и переключает рабочую директорию на неё. Префикс feature/ — это не техническое требование Git, а договорённость команды о соглашении об именовании. Распространённые префиксы:

| Префикс | Назначение | Пример | |---|---|---| | feature/ | Новая функциональность | feature/cart | | bugfix/ | Исправление бага | bugfix/login-error | | hotfix/ | Срочное исправление на продакшене | hotfix/payment-crash | | release/ | Подготовка релиза | release/v2.1 |

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

Текущая ветка будет отмечена звёздочкой. Переключиться между ветками:

В VS Code текущая ветка отображается в левом нижнем углу. Клик по ней открывает список всех веток для быстрого переключения.

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

В ветке feature/cart вы работаете как обычно — создаёте файлы, редактируете код, делаете коммиты. Все изменения изолированы от main. Если коллега в это время работает в ветке feature/search, ваши изменения не пересекаются.

Когда функция готова, нужно слить изменения обратно в main.

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

Переключитесь на целевую ветку и выполните слияние:

Git попытается автоматически объединить изменения. Если в main и feature/cart были изменены разные файлы или разные части одних и тех же файлов — слияние пройдёт гладко, и Git создаст автоматический merge-коммит.

В VS Code процесс слияния можно запустить через панель Source Control: нажмите на имя ветки → выберите ветку для слияния → Merge Branch.

Типы слияний

Git выполняет слияние двумя способами.

Fast-forward — если с момента создания ветки main не получала новых коммитов, Git просто переместит указатель main вперёд. История останется линейной, без дополнительных коммитов.

Three-way merge — если в main появились свои коммиты, Git создаёт новый коммит слияния, который объединяет обе линии. В истории появится точка, где две ветки соединились.

Принудительно создать merge-коммит даже при fast-forward:

Это полезно, когда вы хотите явно зафиксировать в истории, что ветка была создана и слита — особенно при code review.

Удаление ветки

После успешного слияния ветку можно удалить:

Флаг -d безопасен: Git не даст удалить ветку, если в ней есть неслитые изменения. Для принудительного удаления используйте -D.

Практический сценарий: две параллельные задачи

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

Обратите внимание: обе ветки отпочковались от одного состояния main. Если бы вы создали bugfix/contact-form из feature/about-page, то при слиянии в main попали бы изменения обеих веток — а это может быть нежелательно.

Визуализация веток в VS Code

Расширение Git Graph показывает дерево веток наглядно: main идёт по центру, feature-ветки отклоняются в стороны и возвращаются точками слияния. Это особенно ценно, когда в проекте работают несколько человек — вы сразу видите, кто над чем работает и какие ветки ещё не слиты.

> Совет: регулярно обновляйте свою ветку из main, пока работаете над задачей. Команда git merge main (находясь в feature-ветке) подтянет последние изменения и снизит вероятность крупных конфликтов при финальном слиянии.

Интеграция с GitLab и работа с удаленными репозиториями

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

Создание проекта в GitLab

Зарегистрируйтесь на GitLab и нажмите кнопку New project. Вам предложат три варианта:

Create blank project — пустой репозиторий, куда вы загрузите существующий локальный проект.

Create from template — проект с готовой структурой (например, шаблон для Node.js, Python и других технологий).

Import project — перенос репозитория с GitHub или другого сервиса.

Выберите Create blank project, задайте имя, отметьте Initialize repository with a README и создайте проект. GitLab автоматически добавит файл README.md и ветку main.

Подключение локального репозитория к GitLab

Если у вас уже есть локальный проект, нужно связать его с удалённым репозиторием. Скопируйте URL вашего проекта в GitLab (кнопка Clone → вариант с SSH, если вы настроили ключ в первой статье).

Команда git remote add создаёт удалённое подключение с именем origin — это стандартное название для основного удалённого репозитория. Проверить список удалённых подключений:

Вывод покажет URL для fetch (получение) и push (отправка).

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

Загрузите локальные коммиты в GitLab:

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

Если вы работаете в feature-ветке, отправьте и её:

После первого push ветка появится в GitLab, и вы сможете создать merge request — запрос на слияние.

Получение изменений с сервера

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

Эта команда делает две вещи: скачивает новые коммиты (git fetch) и сливает их с вашей текущей веткой (git merge). Если вы настроили pull.rebase true в первой статье, слияние произойдёт через rebase — история останется линейной.

Альтернативный подход — сначала посмотреть, что изменилось, а потом решить, сливать или нет:

Merge Request в GitLab

Merge Request (MR) — это механизм code review. Вы предлагаете слить вашу ветку в main, а коллеги проверяют код, оставляют комментарии и одобряют или запрашивают изменения.

Создать MR можно двумя способами:

Через интерфейс GitLab: после git push GitLab сам предложит создать MR — кнопка появится на главной странице проекта.

Через VS Code: расширение GitLab Workflow позволяет создавать MR прямо из редактора.

При создании MR укажите:

> Хороший MR содержит не только код, но и контекст: ссылку на задачу в трекере, описание edge cases, инструкцию по проверке. Это экономит время ревьюеров и ускоряет процесс.

Настройка CI/CD (краткий обзор)

GitLab умеет автоматически запускать тесты и сборку при каждом push. Для этого в корне проекта создайте файл .gitlab-ci.yml:

После push GitLab автоматически запустит пайплайн и покажет результат на вкладке CI/CD. Это базовый пример — реальные конфигурации включают сборку, тестирование, деплой на стейджинг и продакшен.

Клонирование чужого проекта

Если вы хотите работать с существующим проектом в GitLab:

Команда git clone скачивает весь репозиторий с историей и автоматически настраивает origin. После клонирования вы можете создавать ветки, вносить изменения и отправлять их через MR.

Практический сценарий: командный workflow

Типичный день разработчика в проекте с GitLab выглядит так:

Этот цикл — feature branch workflow — стандарт для большинства команд. Каждая задача живёт в своей ветке, проходит code review через MR и сливается в main только после одобрения.

Разрешение конфликтов и лучшие практики командной работы

Вы работаете в ветке feature/header, коллега — в feature/footer. Оба изменили файл index.html: вы переписали шапку, он — подвал. Git сливает оба изменения без проблем, потому что затронуты разные части файла. Но что если оба изменили одну и ту же строку? Git остановится и скажет: конфликт. Это не ошибка — это запрос на ваше решение. И умение разрешать конфликты — один из ключевых навыков в командной разработке.

Как возникает конфликт

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

Создадим конфликт намеренно, чтобы понять механизм. Допустим, в main есть файл style.css:

Вы создаёте ветку feature/dark-theme и меняете цвет:

Коллега создаёт ветку feature/brand-color и тоже меняет цвет:

Коллега сливает свою ветку первым. Когда вы пытаетесь слить свою — Git сообщает о конфликте.

Как выглядит конфликт в файле

Открыв style.css, вы увидите маркеры конфликта:

Эти маркеры означают:

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

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

Откройте конфликтный файл и примите решение:

Удалите все маркеры (<<<<<<<, =======, >>>>>>>) и лишние строки. Сохраните файл. Затем добавьте его в staging и завершите слияние:

> Сообщение коммита при разрешении конфликта должно объяснять, почему выбран именно этот вариант. Это помогает коллегам понять ваше решение при чтении истории.

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

VS Code делает процесс значительно нагляднее. При открытии конфликтного файла вы увидите три панели:

Над каждым блоком конфликта появятся кнопки:

После выбора VS Code автоматически удалит маркеры. Когда все конфликты разрешены, файл перестанет подсвечиваться красным в панели Source Control.

Отмена неудачного слияния

Если конфликтов слишком много или вы поняли, что пошли не по тому пути, можно отменить слияние целиком:

Эта команда вернёт репозиторий в состояние до начала git merge. Аналогично для rebase:

Используйте это, когда чувствуете, что проще начать слияние заново, чем разбираться с десятком конфликтов.

Стратегии минимизации конфликтов

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

Часто синхронизируйтесь с main. Пока вы работаете над веткой три дня, main может получить десяток коммитов. Регулярно подтягивайте изменения:

Чем меньше расхождение между вашей веткой и main, тем проще будет финальное слияние.

Делайте маленькие ветки. Ветка, живущая один день, почти гарантированно не конфликтует. Ветка, живущая две недели, конфликтует почти гарантированно.

Разделяйте ответственность за файлы. Если два разработчика одновременно правят один и тот же файл — это сигнал о проблеме в архитектуре или в организации работы. Обсудите с командой, кто за что отвечает.

Лучшие практики коммитов

Атомарные коммиты. Один коммит — одна логическая задача. Не смешивайте рефакторинг с исправлением бага в одном коммите. Если потребуется откатить багфикс, вы потеряете и рефакторинг.

Осмысленные сообщения. Используйте формат: «Глагол в повелительном наклонении + что сделано». Примеры:

Не коммитьте незавершённую работу в main. Используйте draft commits или WIP-коммиты только в feature-ветках. Перед merge request сделайте squash — объединение нескольких промежуточных коммитов в один финальный:

Откроется список коммитов, где вы сможете объединить (squash) или переформулировать сообщения.

Лучшие практики веток

Называйте ветки по шаблону. feature/, bugfix/, hotfix/ — это не просто формальность. Такая структура помогает понять назначение ветки без чтения описания.

Удаляйте слитые ветки. Захламлённый список веток мешает ориентироваться. После merge request удалите ветку и локально, и в GitLab.

Защитите main. В настройках GitLab (Settings → Repository → Protected Branches) запретите прямой push в main. Все изменения должны проходить через Merge Request с одобрением хотя бы одного ревьюера. Это гарантирует, что в основную ветку попадает только проверенный код.

Лучшие практики Merge Request

Небольшие MR. Merge Request на 500 строк кода ревьюер будет проверять час и с высокой вероятностью пропустит баг. MR на 100 строк — за 15 минут с вниманием к деталям.

Описывайте контекст. Шаблон MR должен включать: что сделано, как тестировать, скриншоты (для UI), ссылки на задачи. GitLab позволяет создать шаблон MR в файле .gitlab/merge_request_templates/default.md.

Используйте черновики. Создавайте MR как Draft, когда код ещё не готов к ревью. Коллеги увидят прогресс, но не будут тратить время на проверку незавершённой работы. Переключить MR из Draft в Ready — одна кнопка в интерфейсе GitLab.

Рабочий процесс команды: итоговая схема

Вся цепочка от задачи до продакшена выглядит так:

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