Что такое Git простыми словами: ветки, коммиты и merge request

Вячеслав Степанов — проджект-менеджер, ментор · 12 октября 2026

«Код в ветке, MR на ревью», «конфликт при мерже», «уже влили в main» — разработчики говорят так каждый день, а задача проджекта — понимать, что за этими словами стоит для сроков. Код писать не нужно: достаточно понять несколько понятий, и статус любой задачи станет прозрачным. Ниже — что такое Git, коммиты, ветки и merge request, откуда берутся конфликты и как проджект использует всё это в работе. Видео-версия — мой открытый урок, где весь путь проходим руками в браузере.

Если видео не открывается — смотри на YouTube (может понадобиться VPN).

Что такое Git

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

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

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

Репозиторий, GitHub и GitLab

Репозиторий (repository, «репа») — хранилище кода проекта вместе со всей историей изменений. Обычно у продукта отдельный репозиторий на бэкенд и отдельный на фронтенд.

Сам Git — это программа. А хранят репозитории и работают с ними вместе на платформах:

• GitHub — крупнейшая платформа в мире, с 2018 года принадлежит Microsoft. На ней живут открытые проекты и многие компании.
• GitLab — устроен похоже, но его можно поставить на собственные серверы компании, чтобы код не уходил в чужое облако. Поэтому в российских компаниях его выбирают часто.

Отличаются в основном интерфейсом и названиями: в GitHub заявка на вливание кода называется pull request (PR), в GitLab — merge request (MR). По смыслу это одно и то же.

Коммит

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

Хорошая практика — указывать в подписи коммита номер задачи из трекера. Тогда Jira, связанная с Git, показывает прямо в карточке задачи, какие коммиты и ветки к ней относятся. Проджекту это даёт картину без вопросов «как там дела»: открыл задачу — видишь, что код уже пишется.

Ветки

Ветка (branch) — параллельная версия кода. Разработчик берёт задачу, делает от основной ветки свою, спокойно пишет код там и ничего не ломает остальным. Типичная схема веток:

• main (иногда master) — основная ветка: код, который сейчас работает у пользователей;
• test — промежуточная ветка, куда сливают готовые задачи для проверки тестировщиком;
• feature/название — временная ветка под конкретную задачу.

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

Merge request и код-ревью

Когда задача готова, разработчик открывает merge request — заявку влить свою ветку в общую. Внутри MR видно, какие строки изменились, и коллеги оставляют замечания. Это и есть код-ревью: обычно другой разработчик или техлид проверяет, понятен ли код, нет ли в нём ошибок и рисков.

Параллельно с ревью запускаются автоматические проверки — тесты и проверки стиля. Если что-то упало, MR помечается красным крестом и влить его нельзя, пока разработчик не исправит. Когда ревью одобрено и проверки зелёные, ветку вливают — это называется мерж (merge). Как устроены эти автоматические проверки и выкатка на серверы, разберу в отдельной статье про CI/CD.

Конфликт слияния

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

Для проджекта частые конфликты — сигнал о процессе: двое регулярно правят одно и то же, ветки живут слишком долго, задачи нарезаны крупно. Решается это планированием: дробить задачи мельче и вливать чаще.

Зачем Git проджект-менеджеру

• Видеть реальный статус. Задача «в работе» уже неделю, а коммитов нет — повод спросить на дейлике, не застряла ли она.
• Замечать узкое место на ревью. Если MR по два-три дня ждут проверки, задачи копятся перед тестированием. Это проблема процесса, и её решает проджект вместе с техлидом.
• Честно считать «готово». Задача сделана, когда код влит и проверен, а не когда разработчик сказал «я закончил».
• Разбирать инциденты. История коммитов показывает, что и когда изменилось перед сбоем, — это помогает быстро найти причину и откатить изменение.
• Говорить с командой на одном языке. На дейлике и планировании разработчики оперируют ветками и MR — проджект понимает, о чём речь, и задаёт точные вопросы.

Как попробовать самому

Устанавливать ничего не нужно. Заведи бесплатный аккаунт на GitHub и прямо в браузере создай репозиторий, добавь файл, сделай ветку, измени файл в ней и открой pull request. За полчаса ты пройдёшь тот же цикл, что разработчик проходит каждый день, — и слова «ветка», «коммит» и «мерж» перестанут быть абстракцией.

Типичные ошибки

• Путать Git и GitHub. Git — программа для истории изменений, GitHub и GitLab — платформы, где хранят репозитории. Лекарство — запомнить: Git — инструмент, GitHub — сервис вокруг него.
• Считать задачу готовой после «я закончил». Код ещё в ветке, ревью не пройдено. Лекарство — «готово» означает «влито и проверено».
• Не замечать очередь на ревью. MR висят днями, а спринт срывается в конце. Лекарство — смотреть открытые MR и договориться с техлидом о сроке проверки.
• Огромные ветки. Задачу пишут две недели в одной ветке — и получают тяжёлые конфликты. Лекарство — дробить задачи так, чтобы ветка жила день-два.
• Пугаться слова «конфликт». Это не авария, а обычная развилка в коде. Лекарство — спросить разработчика, сколько времени займёт решение, и планировать спокойно.

Частые вопросы