Git для начинающих: полное руководство с нуля до первого pull request

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

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

Зачем разработчику знать Git

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

Приведу конкретику. Когда я собеседую начинающих разработчиков, я почти никогда не спрашиваю про сложные алгоритмы. Зато обязательно прошу показать GitHub-профиль и рассказать, как устроен их рабочий процесс с ветками. Причина простая: человек, который умеет работать с Git, вольётся в команду за неделю. Человек, который не умеет, будет ломать общий репозиторий и отнимать время у коллег ещё месяц.

Есть и вторая, менее очевидная причина. Git — это ваша страховка. Он позволяет экспериментировать без страха: испортили код — вернулись к рабочей версии одной командой. Удалили нужный файл — восстановили. Три дня писали фичу, а она оказалась тупиковой — откатились к точке, где всё было хорошо. Для новичка это огромное облегчение, потому что снимает главный страх: «а вдруг я всё сломаю».

Что такое Git

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

Представьте, что вы пишете диплом и делаете копии файла: diplom.docx, diplom_финал.docx, diplom_финал_точно_последний.docx, diplom_финал_правки_научрука.docx. Знакомо? Это ручная и очень плохая система контроля версий. Git делает то же самое, только автоматически, аккуратно и без свалки файлов: вся история хранится в одном месте, а каждая версия подписана и доступна.

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

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

Почему появился Git и кто его создал

Git написал в 2005 году Линус Торвальдс — тот самый человек, который создал ядро Linux. И появился Git не от хорошей жизни. До этого разработчики ядра Linux пользовались проприетарной системой BitKeeper, но компания-владелец отозвала бесплатную лицензию для open-source. Тысячам разработчиков внезапно стало нечем работать.

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

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

Git и GitHub: в чём разница

Git — это программа для контроля версий, которая работает на вашем компьютере. GitHub — это онлайн-сервис (сайт), где можно хранить Git-репозитории в интернете, показывать код другим и работать над проектом командой. Git может существовать без GitHub, а вот GitHub без Git — нет. Проще говоря: Git — это инструмент, GitHub — это площадка, где результаты работы этим инструментом хранятся и обсуждаются.

Эту пару путают чаще всего, поэтому разберём подробнее. Аналогия, которая хорошо заходит студентам: Git — это как программа для работы с документами на вашем ноутбуке, а GitHub — как облачное хранилище, куда вы эти документы выгружаете, чтобы поделиться с коллегами и вести совместную работу. GitHub не единственный такой сервис — есть ещё GitLab, Bitbucket, Gitea и другие. Все они делают примерно одно и то же и работают поверх одного и того же Git.

Критерий	Git	GitHub
Что это	Программа (система контроля версий)	Онлайн-сервис для хранения репозиториев
Где работает	Локально, на вашем компьютере	В интернете, на серверах компании
Нужен ли интернет	Нет, для базовой работы не нужен	Да
Кто создал	Линус Торвальдс, 2005	Компания GitHub, 2008 (сейчас часть Microsoft)
Главная задача	Отслеживать изменения в коде	Хранить код онлайн, совместная работа, review
Аналоги	Mercurial, SVN (устаревает)	GitLab, Bitbucket, Gitea
Стоимость	Бесплатный, open-source	Бесплатный тариф + платные планы

Ещё одна деталь, которую полезно понять сразу. GitHub добавляет к Git много вещей, которых в самом Git нет: веб-интерфейс, pull request'ы, issue-трекер, code review, GitHub Actions для автоматизации, доску проектов. Всё это — «надстройка» над Git. Поэтому когда говорят «pull request», технически это функция GitHub, а не Git. В Git есть похожая, но более низкоуровневая команда git request-pull, которой на практике почти никто не пользуется.

Как работает контроль версий

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

Ключевая идея, которую нужно уложить в голове: в Git файл проходит через три «зоны». Понимание этих зон снимает 80% путаницы у новичков.

• Рабочая директория (working directory) — обычная папка проекта, где вы редактируете файлы. Здесь живут ваши актуальные изменения, которые Git ещё не зафиксировал.
• Индекс, или staging area — «зона подготовки». Сюда вы кладёте изменения, которые хотите включить в следующий commit. Это как корзина в магазине: вы уже положили товар, но ещё не оплатили.
• Репозиторий (.git) — хранилище, где Git сохраняет коммиты навсегда. После git commit изменения переезжают сюда, в постоянную историю.

Путь любого изменения выглядит так: вы правите файл (working directory) → командой git add отправляете его в staging area → командой git commit фиксируете в репозитории. Разделение на staging и commit кажется лишним усложнением, но оно даёт важную свободу: вы можете сделать десять правок, а закоммитить только три связанные между собой, оставив остальные на потом. Это позволяет держать историю аккуратной и осмысленной.

Ключевые понятия Git, которые нужно понять первыми

Дальше — словарь терминов, который вы будете слышать постоянно. Я разберу каждый на простом примере, а не сухим определением. Если освоите эти восемь понятий, всё остальное в Git будет наращиваться поверх них естественно.

Репозиторий (repository)

Репозиторий — это папка проекта, за которой следит Git, вместе со всей историей её изменений. Технически это ваш обычный каталог с кодом плюс скрытая подпапка .git, где хранится вся история, ветки и настройки. Пока папки .git нет — это просто набор файлов; как только вы выполнили git init, папка превращается в репозиторий.

Репозитории бывают локальные (у вас на компьютере) и удалённые (на GitHub). Обычно это две связанные копии одного и того же проекта: вы работаете в локальном, а результаты отправляете в удалённый, чтобы они были доступны команде и не потерялись.

Commit (коммит)

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

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

Ветка (branch)

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

Представьте книгу, в которой вы дошли до определённой страницы, и вдруг захотели написать альтернативную концовку, не портя оригинал. Вы делаете «ответвление» от текущей страницы и пишете там. Если концовка удалась — вклеиваете её в основную книгу. Если нет — просто выбрасываете ветку, оригинал не пострадал. Основную ветку по умолчанию сейчас называют main (раньше было master). Рабочие ветки обычно называют по смыслу задачи: feature/login, fix/header-bug.

Слияние (merge)

Merge — это операция объединения изменений из одной ветки в другую. Когда вы закончили работу в своей ветке и хотите, чтобы её изменения попали в основную, вы делаете merge: Git берёт коммиты из вашей ветки и вплетает их в целевую. Если правки не пересекаются, всё проходит автоматически.

Иногда возникает конфликт слияния (merge conflict) — это когда два человека изменили одну и ту же строку файла по-разному, и Git не может решить, чья версия правильная. Новичков это пугает, но ничего страшного тут нет: Git просто помечает спорное место в файле, а вы вручную выбираете, какой вариант оставить. Конфликты — обычная часть командной работы, а не признак того, что вы что-то сломали.

Pull Request (пул-реквест)

Pull request — это запрос на добавление ваших изменений в основную ветку проекта, оформленный на GitHub. Вы говорите команде: «Вот код, который я написал в своей ветке, посмотрите и, если всё хорошо, влейте его в main». Это точка, где происходит code review — коллеги читают ваш код, оставляют комментарии, просят что-то поправить.

Pull request (на GitLab его называют merge request) — сердце командной разработки. Именно через него код попадает в продукт, и именно умение грамотно оформлять и обсуждать pull request'ы отличает junior'а, готового к работе, от того, кто «только курсы прошёл». На собеседовании вопрос «расскажи, как ты работаешь с pull request'ами» встречается очень часто.

Clone (клонирование)

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

Отличие клонирования от простого скачивания архива в том, что clone создаёт настоящий Git-репозиторий, связанный с оригиналом. Вы получаете не мёртвый набор файлов, а живую копию, из которой можно тянуть обновления (git pull) и в которую можно отправлять свои (git push).

Fork (форк)

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

Fork нужен в основном для open-source. Допустим, вы нашли баг в популярной библиотеке и хотите его исправить. Прав на изменение чужого репозитория у вас нет. Тогда вы форкаете проект к себе, чинитё баг в своей копии и открываете pull request в оригинал — авторы посмотрят и, если исправление хорошее, примут его. Так работает вся культура открытого кода.

Удалённый репозиторий (remote)

Remote — это версия вашего репозитория, размещённая на сервере (например, на GitHub), с которой синхронизируется ваша локальная копия. По умолчанию главный удалённый репозиторий называют origin. Когда вы делаете git push, вы отправляете коммиты в remote; когда делаете git pull — забираете оттуда чужие изменения.

Можно думать о remote как о точке встречи команды. У каждого разработчика своя локальная копия, где он спокойно работает, а remote — общее место, куда все стекаются, чтобы синхронизироваться. Без remote Git работает, но только для вас одного; командная работа начинается именно с удалённого репозитория.

Как установить Git

Установить Git несложно, процесс зависит от операционной системы. После установки проверьте, что всё встало, командой git --version — если она показала номер версии, Git готов к работе.

• Windows: скачайте установщик с git-scm.com и пройдите мастер, оставляя настройки по умолчанию. Вместе с Git установится Git Bash — терминал, в котором удобно выполнять команды.
• macOS: проще всего через Homebrew командой brew install git. Либо Git подтянется сам при установке инструментов разработчика через xcode-select --install.
• Linux: через пакетный менеджер, например sudo apt install git для Ubuntu/Debian или sudo dnf install git для Fedora.

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

git config --global user.name "Ваше Имя"
git config --global user.email "[email protected]"

Email лучше указывать тот же, что и на GitHub, — тогда ваши коммиты будут правильно привязываться к профилю. Флаг --global означает, что настройка применится ко всем вашим проектам на этом компьютере. Это разовое действие: настроили один раз — и забыли.

Типичный рабочий процесс разработчика

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

1. Забрать свежие изменения из общего репозитория: git pull. Так вы получаете то, что коллеги сделали, пока вас не было.
2. Создать ветку под свою задачу: git switch -c feature/login. Работать сразу в main — плохая практика.
3. Писать код, время от времени фиксируя логические куски: git add → git commit. Несколько маленьких осмысленных коммитов лучше одного огромного.
4. Отправить ветку на GitHub: git push. Теперь ваш код виден команде.
5. Открыть pull request и попросить коллег о review. Обсудить, внести правки, снова запушить.
6. После одобрения — merge в main. Ветку удалить, задача закрыта.

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

Git-команды, которые должен знать каждый

Команд в Git много, но в повседневной работе вы пользуетесь небольшим набором. Ниже — те, что нужны буквально каждый день, с объяснением на человеческом языке. Освоите этот список — покроете 90% реальных задач.

Команда	Что делает	Когда используется
git init	Превращает папку в Git-репозиторий	В начале нового проекта
git clone	Скачивает удалённый репозиторий на компьютер	Когда присоединяетесь к готовому проекту
git status	Показывает состояние: что изменено, что готово к коммиту	Постоянно, чтобы понимать, где вы находитесь
git add	Добавляет изменения в staging area	Перед каждым коммитом
git commit	Фиксирует изменения в истории	Когда закончили логический кусок работы
git push	Отправляет коммиты на удалённый репозиторий	Когда хотите поделиться кодом с командой
git pull	Забирает чужие изменения с сервера	В начале работы и перед push
git branch	Показывает список веток / создаёт ветку	Когда нужно увидеть или создать ветку
git switch	Переключается между ветками	Когда меняете задачу
git merge	Объединяет ветки	Когда вливаете готовую фичу в main
git log	Показывает историю коммитов	Когда нужно вспомнить, что и когда делали

Отдельно поясню про git switch и git checkout. Раньше переключение веток делали через git checkout, и вы до сих пор встретите этот вариант в старых статьях. Но checkout перегружен — он умеет слишком много разных вещей, и это путало новичков. Поэтому в современном Git появились две отдельные команды: git switch для переключения веток и git restore для отмены изменений в файлах. Учите сразу их — это чище и понятнее.

Реальные примеры: от нуля до push

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

Сценарий 1: новый проект с нуля

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

# создаём папку и заходим в неё
mkdir portfolio
cd portfolio

# превращаем папку в Git-репозиторий
git init

# создаём файл (для примера)
echo "<h1>Привет, я разработчик</h1>" > index.html

# смотрим состояние — Git видит новый неотслеживаемый файл
git status

# добавляем файл в staging area
git add index.html

# фиксируем первый commit с сообщением
git commit -m "Первый коммит: добавил главную страницу"

Разберём, что произошло. git init создал скрытую папку .git — с этого момента Git следит за проектом. git status показал index.html как «untracked» — то есть Git его видит, но пока не отслеживает. git add перевёл файл в staging, а git commit -m сохранил снимок с описанием. Флаг -m — это message, сообщение коммита; без него Git откроет текстовый редактор и попросит его ввести.

Теперь свяжем проект с GitHub. Сначала создайте пустой репозиторий на сайте GitHub, скопируйте его адрес и выполните:

# добавляем удалённый репозиторий под именем origin
git remote add origin https://github.com/username/portfolio.git

# переименовываем ветку в main (если нужно)
git branch -M main

# отправляем код на GitHub впервые
git push -u origin main

Флаг -u в последней команде связывает вашу локальную ветку с удалённой один раз, чтобы дальше можно было писать просто git push и git pull без указания, куда и откуда. После этой команды обновите страницу репозитория на GitHub — ваш код будет там.

Сценарий 2: подключение к существующему проекту

Второй частый случай — вы пришли в команду или хотите поработать с чужим открытым проектом. Здесь всё начинается с клонирования:

# скачиваем проект целиком
git clone https://github.com/company/project.git
cd project

# создаём ветку под свою задачу и сразу переключаемся на неё
git switch -c feature/contact-form

# ... пишем код ...

# смотрим, что изменилось
git status

# добавляем все изменения разом
git add .

# коммитим
git commit -m "Добавил форму обратной связи"

# отправляем свою ветку на GitHub
git push -u origin feature/contact-form

Обратите внимание на git add . — точка означает «добавить все изменения в текущей папке». Это удобно, но опасно: так легко случайно закоммитить лишнее. Поэтому перед git add . всегда полезно сделать git status и посмотреть, что именно попадёт в commit. После push зайдите на GitHub — он предложит кнопку «Compare & pull request». Нажимаете, описываете, что сделали, и открываете pull request. Дальше — review, обсуждение и merge.

Когда что-то пошло не так: базовые спасательные команды

Рано или поздно вы захотите что-то откатить. Вот три команды, которые снимают панику:

# посмотреть, что именно изменилось в файлах
git diff

# отменить изменения в файле, вернуть к последнему коммиту
git restore index.html

# посмотреть историю коммитов кратко, по одной строке
git log --oneline

Здесь важна одна установка, которую я всегда даю студентам: пока изменения не отправлены на GitHub, почти всё можно исправить локально и никто не увидит. Git очень трудно «сломать по-настоящему», если вы уже сделали хотя бы один commit. Это даёт свободу экспериментировать.

Как читать то, что показывает Git

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

Вот типичный вывод git status, когда вы изменили один файл и создали другой:

On branch main
Changes to be committed:
  (use "git restore --staged ..." to unstage)
        modified:   index.html

Untracked files:
  (use "git add ..." to include in what will be committed)
        style.css

Читается это буквально. On branch main — вы находитесь в ветке main. Changes to be committed — файл index.html уже в staging area и попадёт в следующий commit. Untracked files — файл style.css Git видит, но ещё не отслеживает, и без git add он в commit не войдёт. Обратите внимание: Git прямо в скобках пишет, какой командой что отменить или добавить. Он вам подсказывает — надо просто читать.

Второй важный экран — история коммитов через git log --oneline:

a3f9c21 (HEAD -> main, origin/main) Добавил форму обратной связи
7b2e5d8 Исправил валидацию email
1c4a9f0 Первый коммит: добавил главную страницу

Слева — короткие хеши коммитов, справа — их сообщения (вот зачем нужны осмысленные тексты). Пометка HEAD -> main означает «вы сейчас находитесь здесь, на верхушке ветки main». origin/main рядом показывает, что удалённая версия на GitHub совпадает с локальной — то есть всё запушено. Если бы origin/main оказался на коммите ниже, это значило бы, что у вас есть незапушенные изменения. Умение видеть эти указатели — половина уверенности в работе с Git.

Частые ошибки новичков и как их избежать

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

Ошибка	Чем плоха	Как правильно
Коммиты с сообщениями «fix», «asdf», «работает»	Через месяц невозможно понять историю	Писать осмысленно: «исправил валидацию email в форме»
Коммитить всё подряд, включая пароли и .env	Секреты утекают в публичную историю навсегда	Использовать .gitignore для секретов и мусора
Работать напрямую в ветке main	Легко сломать общий рабочий код	Всегда создавать отдельную ветку под задачу
Один гигантский commit на весь день работы	Невозможно ни отревьюить, ни откатить частично	Дробить на маленькие логические коммиты
Не делать git pull перед началом работы	Постоянные конфликты и работа на устаревшем коде	Начинать день с git pull
Паниковать при merge conflict	Люди делают резкие движения и теряют код	Спокойно разобрать конфликт руками — это норма
Класть в Git тяжёлые файлы, node_modules, сборки	Репозиторий раздувается до сотен мегабайт	Добавить их в .gitignore

Отдельно про .gitignore — это простой текстовый файл в корне проекта, где вы перечисляете, что Git должен игнорировать. Туда обычно добавляют папки зависимостей (node_modules/), файлы окружения с секретами (.env), артефакты сборки (dist/, build/) и системный мусор (.DS_Store). Настроить .gitignore в самом начале проекта — привычка, которая отличает аккуратного разработчика.

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

Roadmap изучения Git с нуля

Учить Git лучше слоями: сначала минимум для соло-работы, потом командные вещи, потом продвинутое. Не пытайтесь освоить всё сразу — большинство «сложных» команд вам не понадобятся месяцами. Вот последовательность, которую я рекомендую студентам.

Этап	Что освоить	Результат
1. База (1–2 дня)	init, add, commit, status, log	Ведёте историю личного проекта
2. Работа с GitHub (2–3 дня)	clone, remote, push, pull, аккаунт на GitHub	Выкладываете код онлайн, есть портфолио
3. Ветки (3–5 дней)	branch, switch, merge, разрешение конфликтов	Работаете как в реальной команде
4. Командный процесс (1 неделя)	Pull request, code review, fork, .gitignore	Готовы к стажировке и первой работе
5. Продвинутое (по мере роста)	rebase, stash, cherry-pick, reset, revert	Уверенно решаете сложные ситуации

Важный момент про пятый этап: не трогайте rebase, reset --hard и cherry-pick, пока прочно не освоите первые четыре. Это мощные команды, но именно ими новички чаще всего «стреляют себе в ногу». Они нужны, вы к ним придёте, но не в первую неделю. Сначала — уверенная база.

Практический совет по темпу: заведите личный проект (хоть простой сайт, хоть учебные задачи) и с первого же дня ведите его в Git. Навык Git ставится не чтением, а руками. Десять реальных коммитов дадут больше понимания, чем десять статей, включая эту.

Вопросы про Git на собеседовании Junior

На собеседованиях Git спрашивают почти всегда, и вопросы обычно базовые — проверяют, что вы реально работали, а не только читали. Разберём самые частые, чтобы вы не терялись.

• В чём разница между Git и GitHub? Git — программа контроля версий на вашем компьютере, GitHub — сервис для хранения репозиториев онлайн. Классический первый вопрос, отсекающий тех, кто путается в базе.
• Чем отличается git pull от git fetch? fetch только скачивает изменения с сервера, но не применяет их к вашей ветке. pull — это fetch плюс автоматический merge, то есть скачивает и сразу вливает.
• Что такое merge conflict и что с ним делать? Это ситуация, когда двое изменили одну строку по-разному. Нужно открыть файл, найти пометки конфликта, выбрать правильную версию руками и закоммитить.
• Что делает git add? Переводит изменения в staging area — зону подготовки к коммиту. Многие путают его с сохранением; на самом деле сохраняет только commit.
• Чем merge отличается от rebase? Оба объединяют ветки, но merge создаёт отдельный коммит слияния и сохраняет ветвистую историю, а rebase «переписывает» коммиты поверх другой ветки, делая историю линейной.
• Как отменить последний commit? Зависит от ситуации: git revert создаёт новый коммит, отменяющий изменения (безопасно для общей истории), а git reset убирает коммит из истории (только для локальной, ещё не запушенной работы).
• Что такое .gitignore? Файл со списком того, что Git должен игнорировать: зависимости, секреты, артефакты сборки.

Совет по подготовке: не заучивайте ответы наизусть. Лучше реально поработайте с Git пару недель — тогда вы будете отвечать своими словами и на основе опыта, а это интервьюеры чувствуют сразу. Заученный ответ виден за версту, а рассказ «я на своём проекте вот так делал» звучит убедительно.

Практические советы, которые экономят время

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

• Делайте git status постоянно. Это ваш компас. Перед каждым add и commit проверяйте, в каком вы состоянии. Со временем это станет рефлексом.
• Пишите сообщения коммитов в повелительном наклонении и по делу: «добавь», «исправь», «удали». Так принято в большинстве команд, и история читается как список действий.
• Коммитьте часто, пушьте регулярно. Незапушенный код существует только у вас на диске. Сломался ноутбук — работа пропала. Пуш — это ещё и бэкап.
• Не бойтесь веток. Ветка в Git — дешёвая операция. Создавайте отдельную ветку под каждую задачу, даже мелкую. Это норма, а не излишество.
• Настройте .gitignore в самом начале. Проще не пускать мусор в репозиторий, чем потом его оттуда выковыривать.
• Освойте один графический клиент, но понимайте команды. GUI вроде GitHub Desktop, GitKraken или встроенного в VS Code удобны для повседневности. Но понимать, что происходит под капотом в терминале, обязательно — иначе в нестандартной ситуации вы застрянете.

Часто задаваемые вопросы про Git

Сложно ли выучить Git новичку?

Нет. Базовый Git осваивается за один-два вечера, а уверенная работа с ветками и pull request'ами — за пару недель практики. Git кажется сложным из-за терминологии, но ежедневно вам нужны всего около семи команд. Главное — не читать, а сразу пробовать на своём проекте.

Нужно ли знать Git для первой работы?

Да, это обязательный навык для любого junior-разработчика. Весь код в компаниях хранится в Git-репозиториях, и без умения работать с ветками, коммитами и pull request'ами влиться в команду невозможно. На собеседованиях Git спрашивают почти всегда.

Можно ли пользоваться Git без GitHub?

Да. Git работает полностью локально и не требует ни интернета, ни GitHub. Вы можете вести историю проекта только на своём компьютере. GitHub нужен, когда вы хотите хранить код онлайн, показывать его другим или работать командой.

Git и GitHub — это одно и то же?

Нет. Git — это программа для контроля версий, которая работает на вашем компьютере. GitHub — это сайт, где Git-репозитории хранятся в интернете. Git создан в 2005 году, GitHub — в 2008. Можно использовать Git без GitHub, но не наоборот.

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

Commit — это сохранённый снимок вашего проекта на определённый момент, с описанием того, что изменилось. Он как «точка сохранения» в игре: в любой момент можно вернуться к ней. Каждый commit подписан автором, датой и текстовым сообщением.

Чем ветка отличается от основного кода?

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

Что делать при merge conflict?

Не паниковать — это нормальная ситуация. Git помечает в файле спорные места специальными маркерами. Нужно открыть файл, выбрать правильную версию (свою, чужую или комбинацию), убрать маркеры конфликта и сделать commit. Современные редакторы вроде VS Code показывают конфликты наглядно.

Как отменить изменения в Git?

Зависит от того, на каком этапе изменения. Незакоммиченные правки в файле отменяются командой git restore. Последний локальный commit убирается через git reset. Уже запушенный commit безопаснее отменять через git revert, который создаёт новый обратный коммит, не переписывая историю.

Что такое pull request и зачем он нужен?

Pull request — это запрос на добавление ваших изменений в основную ветку проекта на GitHub. Через него проходит code review: коллеги читают код, комментируют, просят поправить. Это основной способ, которым код попадает в продукт в командной разработке.

Чем clone отличается от fork?

Clone создаёт локальную копию репозитория на вашем компьютере. Fork создаёт копию чужого репозитория на сервере GitHub, под вашим аккаунтом. Fork нужен для open-source: вы форкаете чужой проект, вносите правки в свою копию и предлагаете их автору через pull request.

Можно ли выучить Git бесплатно?

Да. Официальная документация на docs.github.com, бесплатная книга Pro Git и интерактивные тренажёры вроде Learn Git Branching покрывают всё необходимое бесплатно. Но самый быстрый способ — вести реальный учебный проект в Git с первого дня и разбирать возникающие ситуации по мере их появления.

Что делать, если случайно закоммитил пароль?

Немедленно отзовите этот пароль или ключ и выпустите новый — считайте его скомпрометированным. Просто удалить его следующим коммитом недостаточно: секрет остаётся в истории. Чтобы такого не случалось, добавляйте файлы с секретами (например, .env) в .gitignore ещё до первого коммита.

Какие Git-команды нужны новичку в первую очередь?

Семь команд закрывают почти всё: git init, git add, git commit, git status, git push, git pull и git switch. Освоив их, вы сможете вести проект, выкладывать его на GitHub и работать с ветками. Остальное добавляется по мере необходимости.

Что дальше

Git — это не отдельный предмет, который учат ради галочки, а рабочий инструмент, которым вы будете пользоваться каждый день до конца карьеры. Именно поэтому его не нужно зубрить — его нужно прожить на практике. Заведите проект сегодня, сделайте первый git init и первый commit прямо после прочтения этой статьи. Через неделю ежедневных коммитов страх перед Git исчезнет, а через месяц вы будете работать с ветками не задумываясь.

И ещё одна мысль напоследок. Git — это фундамент, на который встаёт остальная профессия: код-ревью, командная работа, CI/CD, деплой. Освоив его в начале пути, вы снимаете один из главных барьеров между «человеком, который прошёл курс» и «разработчиком, готовым к работе». Это вложение, которое окупается с первого рабочего дня.

Если вы хотите не просто разобраться с Git, а системно войти в профессию с ментором и реальными проектами, посмотрите наши программы. На курсе Python Developer + AI и Java Developer + AI работа с Git встроена в учебный процесс с первых недель — вы ведёте проекты в репозиториях так же, как в настоящих командах. Тем, кто идёт в веб, подойдут Frontend и Full Stack, где Git и pull request'ы — часть каждого практического задания. А если вас тянет к данным или автоматизации, посмотрите Data Analytics и AI Automation — там Git тоже неотъемлемая часть работы. Во всех программах вы учитесь не в вакууме, а с наставником, который разбирает ваш код так, как это делают на реальном code review.