Что такое Git и как им пользоваться: от коммита до пулл-реквеста

Ты работаешь над проектом. Всё работает. Ты вносишь изменения — и всё ломается. Как откатиться назад? Без Git — никак. С Git — одной командой.

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

Содержание

1. Что такое Git и зачем он нужен
2. Установка и первый запуск
3. Создаём первый репозиторий и делаем коммит
4. Ветки: работаем над фичей, не ломая основную версию
5. GitHub и удалённые репозитории
6. Пулл-реквесты: как участвовать в командной разработке
7. Типичные ошибки новичков и как их исправлять
8. Частые вопросы
9. Шпаргалка: 20 команд Git на каждый день
10. Что дальше: куда расти

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

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

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

Сегодня ты установишь Git, создашь первый репозиторий, сделаешь коммит, поработаешь с ветками, подключишь GitHub и узнаешь, что такое пулл-реквест. Это не магия. Это навык. И он даётся быстрее, чем кажется.

Что такое Git и зачем он нужен

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

Git решает три главные проблемы разработчика.

Проблема первая: история изменений. Без Git ты, скорее всего, хранишь версии проекта в папках: project_v1, project_v2_final, project_v2_final_real. Через месяц ты не помнишь, чем эти версии отличаются. Git ведёт аккуратный журнал. Ты всегда знаешь, кто, когда и зачем изменил каждую строку кода.

Проблема вторая: откат. Ты вносишь изменения, и что-то ломается. Без Git ты пытаешься вспомнить, что именно ты менял, и вручную возвращать старый код. С Git ты одной командой возвращаешь проект к любому предыдущему состоянию. Это как машина времени.

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

Важно не путать Git и GitHub. Git — это программа, которая работает у тебя на компьютере. Она управляет историей изменений, ветками, коммитами. GitHub — это сайт, где хранятся копии репозиториев. Он нужен для совместной работы, резервного копирования и публикации кода. Это как разница между текстовым редактором на твоём компьютере и Google Docs в браузере.

Короткая историческая справка. Git создал Линус Торвальдс в 2005 году. Тот самый Линус, который создал Linux. Ему нужна была быстрая, надёжная и бесплатная система контроля версий для разработки ядра Linux. Существовавшие на тот момент инструменты его не устраивали. Он написал Git за несколько недель. С тех пор Git стал стандартом в индустрии. Сегодня его используют миллионы разработчиков по всему миру — от одиночек-фрилансеров до гигантов вроде Google и Microsoft.

Установка и первый запуск

Git работает на Windows, macOS и Linux. Установка занимает пару минут.

Windows. Зайди на официальный сайт git-scm.com. Скачай установщик для Windows. Запусти его. Оставь все настройки по умолчанию, они оптимальны для новичка. На этапе выбора редактора по умолчанию выбери тот, которым пользуешься — VS Code, Notepad++ или другой. После установки у тебя появится Git Bash. Это специальный терминал для работы с Git. Он работает так же, как командная строка, которую ты уже освоил в предыдущей статье.

macOS. Открой терминал и введи git --version. Если Git не установлен, система предложит установить Command Line Tools. Соглашайся. Через пару минут Git будет готов к работе.

Linux. Всё просто. Открой терминал и введи команду установки. Для Debian и Ubuntu: sudo apt install git. Для Fedora: sudo dnf install git. Для Arch: sudo pacman -S git.

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

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

git config --global user.name "Твоё Имя"
git config --global user.email "Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript."

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

Проверь, что всё работает: git config --list. Ты увидишь список настроек, включая имя и почту.

Создаём первый репозиторий и делаем коммит

Репозиторий — это папка, за которой следит Git. Все изменения внутри неё отслеживаются и записываются в историю. Давай создадим твой первый репозиторий.

Создай новую папку для проекта. Назови её, например, my-first-git. Перейди в неё в терминале. Теперь инициализируй репозиторий:

git init

Git ответит: Initialized empty Git repository in .../my-first-git/.git/. Он создал скрытую папку .git. В ней хранится вся история изменений, настройки и служебная информация. Не трогай эту папку вручную. Git сам о ней позаботится.

Теперь разберёмся, как Git видит файлы. У каждого файла в репозитории есть три возможных состояния.

Изменённый (modified). Ты изменил файл, но ещё не сказал Git об этом. Git видит изменение, но пока не готов его сохранить в историю.

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

Зафиксированный (committed). Ты сделал коммит. Изменения сохранены в истории. Теперь к ним можно вернуться в любой момент.

Рабочий цикл выглядит так: изменил файл → добавил в индекс → закоммитил. Повтори.

Создадим первый файл. В папке проекта создай index.html с простым содержимым:

<!DOCTYPE html>
<html>
<head><title>Мой проект</title></head>
<body><h1>Привет, Git!</h1></body>
</html>

Теперь посмотрим, что видит Git. Введи git status. Ты увидишь примерно такое:

Untracked files:
    index.html

Git видит файл, но пока не отслеживает его. Файл находится в состоянии «изменённый». Давай добавим его в индекс:

git add index.html

Можно добавить все изменённые файлы разом: git add . Точка означает «все файлы в текущей папке и подпапках». Снова введи git status. Теперь файл отмечен зелёным цветом — он в индексе, готов к коммиту.

Теперь самое важное — коммит. Он фиксирует изменения в истории:

git commit -m "Создать главную страницу"

Флаг -m означает message — сообщение коммита. В кавычках пиши краткое описание того, что ты сделал.

Как писать хорошие сообщения коммитов? Начинай с глагола: «Добавить», «Исправить», «Обновить», «Удалить». Пиши на том языке, который принят в команде. Хороший пример: git commit -m "Добавить форму регистрации". Сразу понятно, что внутри. Плохой пример: git commit -m "правки". Через месяц ты не вспомнишь, что это были за правки.

Поздравляю. Ты только что сделал первый коммит. Теперь посмотри историю:

git log

Ты увидишь автора, дату и сообщение коммита. Для компактного вида используй git log --oneline — каждый коммит в одну строку.

Ветки: работаем над фичей, не ломая основную версию

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

Ветка — это отдельная линия разработки. Ты ответвляешься от основного кода, экспериментируешь, а когда всё готово — сливаешь обратно. Аналогия простая: основная ветка (main) — это чистовик. Ветка для фичи — это черновик. Пока фича не готова, черновик не попадает в чистовик. Никто не видит твоих экспериментов, пока ты сам не решишь их показать.

Посмотрим, какие ветки есть в нашем репозитории:

git branch

Звёздочкой отмечена текущая ветка. Сейчас это main. Создадим новую ветку для работы над формой входа:

git branch feature/login

Ветка создана, но ты всё ещё на main. Переключись на новую ветку:

git switch feature/login

Можно совместить создание и переключение: git switch -c feature/login. Флаг -c означает create. Ты создал ветку и сразу на неё переключился.

Теперь ты на ветке feature/login. Все изменения, которые ты сделаешь, будут сохраняться здесь. Основная ветка main останется нетронутой.

Создай файл login.html с простой формой входа. Добавь его в индекс и закоммить:

git add login.html
git commit -m "Добавить страницу входа"

Теперь вернись на основную ветку:

git switch main

Посмотри на папку проекта. Файла login.html нет. Он существует только в ветке feature/login. Основная ветка чистая и стабильная.

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

git merge feature/login

Git возьмёт все изменения из feature/login и применит их к main. Если конфликтов нет, слияние пройдёт автоматически. Теперь файл login.html есть и в основной ветке.

Ветка feature/login больше не нужна. Удалим её:

git branch -d feature/login

Что такое конфликт? Представь, что два разработчика изменили одну и ту же строку в одном файле. Один написал color: red, другой — color: blue. Git не знает, какую версию оставить. Он останавливает слияние и просит тебя решить конфликт вручную. В файле появятся маркеры:

<<<<<<< HEAD
color: red
=======
color: blue
>>>>>>> feature/other

Ты решаешь, что оставить. Можешь выбрать красный, синий или написать что-то другое. Удаляешь маркеры, сохраняешь файл, выполняешь git add . и затем git merge --continue. Конфликт разрешён. Это нормальная рабочая ситуация, а не катастрофа.

GitHub и удалённые репозитории

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

GitHub — это облачное хранилище для Git-репозиториев. Он решает три задачи. Первая — резервное копирование. Если с твоим компьютером что-то случится, код останется на GitHub. Вторая — совместная работа. Несколько разработчиков могут работать с одним репозиторием, не передавая файлы через флешку. Третья — портфолио. Для многих работодателей GitHub-профиль важнее резюме.

Создадим репозиторий на GitHub. Зайди на github.com, нажми кнопку «New repository» (или «Create repository» — интерфейс может немного отличаться). Дай ему имя, например, my-first-git. Выбери Public или Private — это решать тебе. Важный момент: не ставь галочку «Initialize this repository with a README», если у тебя уже есть локальный репозиторий. Иначе GitHub создаст свой коммит, и при связывании возникнет конфликт.

GitHub покажет инструкцию. Нас интересует раздел «…or push an existing repository from the command line». Скопируй эти команды и выполни в терминале:

git remote add origin https://github.com/твой_логин/my-first-git.git
git branch -M main
git push -u origin main

Разберём, что здесь происходит. git remote add origin — мы говорим локальному Git: «Вот адрес удалённого репозитория, назовём его origin». origin — это общепринятое имя для основного удалённого репозитория. git branch -M main — переименовываем текущую ветку в main, если она называлась иначе. git push -u origin main — отправляем ветку main на GitHub и запоминаем связь. В следующий раз достаточно будет просто git push.

Твой код теперь на GitHub. Зайди на страницу репозитория и убедись — файлы там.

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

git push

Если кто-то из коллег тоже работает с репозиторием и отправил свои изменения, тебе нужно их скачать:

git pull

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

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

git clone https://github.com/автор/репозиторий.git

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

Пулл-реквесты: как участвовать в командной разработке

Ты освоил локальный Git и GitHub. Теперь пора научиться главному — командной работе. Её сердце — пулл-реквест.

Пулл-реквест (Pull Request, PR) — это запрос на вливание твоих изменений в чужой репозиторий. Ты говоришь владельцу проекта: «Я сделал полезную фичу в своей копии, посмотри и добавь в основной проект, если всё хорошо». Это стандартный способ внести вклад в open-source проекты и рабочие репозитории компаний.

Разберём типичный сценарий. Допустим, ты хочешь улучшить документацию популярного open-source проекта.

Шаг 1: Форк. Зайди на страницу проекта на GitHub и нажми кнопку «Fork» в правом верхнем углу. GitHub создаст твою личную копию репозитория. Она полностью независима от оригинала. Ты можешь делать с ней что угодно.

Шаг 2: Клонирование. Склонируй свой форк на компьютер:

git clone https://github.com/твой_логин/проект.git

Теперь у тебя есть локальная копия, с которой можно работать.

Шаг 3: Ветка и изменения. Создай ветку для своей доработки:

git switch -c docs/improve-readme

Внеси изменения. Например, добавь инструкцию по установке в README.md. Закоммить:

git add README.md
git commit -m "Добавить инструкцию по установке"

Шаг 4: Отправка. Отправь ветку в свой форк на GitHub:

git push -u origin docs/improve-readme

Шаг 5: Пулл-реквест. Вернись на GitHub. Ты увидишь зелёную кнопку «Compare & pull request». Нажми её. Теперь самое важное — правильно описать свой пулл-реквест. Хорошее описание помогает ревьюеру быстро понять суть изменений. Вот шаблон, который можно использовать:

Заполни описание по шаблону и нажми «Create pull request». Готово. Теперь владелец оригинального репозитория увидит твой запрос. Он может просмотреть изменения, оставить комментарии, попросить что-то поправить или сразу принять пулл-реквест.

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

Как вести себя в код-ревью? Пиши понятные описания к пулл-реквестам. Разбивай большие изменения на маленькие запросы — их проще проверять. Спокойно относись к замечаниям: они про код, а не про тебя. Если не согласен — обсуждай аргументированно.

Типичные ошибки новичков и как их исправлять

Ошибки в Git — это нормально. Их совершают все. Главное — знать, как исправлять.

«Я закоммитил в main вместо ветки». Ты забыл переключиться на feature-ветку и сделал коммит прямо в main. Решение: git reset --soft HEAD~1. Эта команда отменит последний коммит, но сохранит изменения в файлах. Потом создай ветку и закоммить туда.

«У меня конфликт, и я не знаю, что делать». Это самая частая паника у новичков. Решение: открой файл с конфликтом. Git пометил конфликтующие строки маркерами <<<<<<<, =======, >>>>>>>. Выбери нужную версию, удали маркеры, сохрани файл. Затем git add . и git merge --continue. Эта команда завершит прерванное слияние. Конфликт разрешён.

«Я не могу запушить — пишет rejected». Причина: кто-то успел запушить изменения, пока ты работал. Решение: git pull, затем разреши конфликты, если они есть, и снова git push.

«Я удалил файл, но Git его помнит». Сценарий первый: ты удалил файл через git rm имя_файла. Git сам добавил удаление в индекс. Осталось только закоммитить. Сценарий второй (более частый): ты удалил файл через проводник или файловый менеджер. Git видит удаление, но не индексирует его. Используй git add -A — эта команда добавит в индекс все изменения, включая удаления. Затем git commit.

«Сообщение коммита написано с ошибкой». Опечатка в сообщении — не трагедия. git commit --amend -m "Новое сообщение" изменит сообщение последнего коммита. Но не делай так с уже запушенными коммитами — это собьёт историю у коллег.

Универсальный совет. Если ты запутался и не понимаешь, что происходит, введи git status. Эта команда показывает текущее состояние и часто сама подсказывает, что делать дальше. Это твой спасательный круг в любой непонятной ситуации.

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

Вот ответы на вопросы, которые чаще всего возникают у новичков после первых недель работы с Git.

Что делать, если я случайно удалил ветку? Не паникуй. Git хранит историю коммитов ещё некоторое время после удаления ветки. Введи git reflog — ты увидишь список всех операций с хэшами коммитов. Найди последний коммит удалённой ветки и выполни git branch имя_ветки хэш_коммита. Ветка восстановлена.

Как отменить git push? Если ты запушил ошибочный коммит, не используй git push --force для его удаления. Правильный способ — git revert <хэш_коммита>. Эта команда создаст новый коммит, который отменяет изменения ошибочного, и запушит его. История остаётся чистой и понятной всей команде.

В чём разница между git revert и git reset? git reset удаляет коммиты из истории — как будто их никогда не было. Это безопасно только для локальных коммитов, которые ты ещё не запушил. git revert создаёт новый коммит, который отменяет изменения старого. История не переписывается, и это безопасно для общих репозиториев. Золотое правило: если коммит уже запушен — используй git revert.

Как мне отменить git add? Ты добавил файл в индекс, но ещё не закоммитил. Чтобы убрать его из индекса, введи git restore --staged имя_файла. Файл останется изменённым, но не будет включён в следующий коммит.

Шпаргалка: 20 команд Git на каждый день

Сохрани эту шпаргалку. В первые недели она будет твоей опорой.

Что дальше: куда расти

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

Файл .gitignore. В проекте всегда есть файлы, которые не нужно хранить в Git. Временные файлы редактора, папка node_modules с зависимостями, файлы с паролями и ключами. Файл .gitignore говорит Git, какие файлы игнорировать. Создай его в корне проекта и перечисли в нём игнорируемые пути. Вот минимальный пример для типичного веб-проекта:

# Зависимости
node_modules/

# Файлы с секретами
.env
*.key

# Временные файлы редактора
*.swp
.DS_Store

Готовые шаблоны для разных языков и сред можно найти на gitignore.io — просто введи название своего стека и скачай готовый файл.

GitHub Actions. Это инструмент для автоматизации, встроенный прямо в GitHub. Можно настроить автоматический запуск тестов при каждом пуше. Или автодеплой на сервер при пуше в main. Это тема для отдельной статьи.

Интерактивный rebase. Продвинутый инструмент для наведения порядка в истории коммитов. Позволяет объединять несколько мелких коммитов в один, менять порядок коммитов, редактировать старые сообщения. Пока достаточно знать, что он существует. Придёт время — освоишь.

Следующая статья. Когда освоишь Git, пора браться за первый язык программирования. Читай наш гайд «Как начать писать на C++: установка среды, компиляция и первые программы». Ты уже умеешь пользоваться терминалом и контролировать версии кода — теперь пора писать сам код. Если хочешь углубиться в Git прямо сейчас — изучи .gitignore и попробуй git rebase в учебном репозитории.

Полезные ссылки:

• Официальная документация Git — полное руководство по всем командам
• Документация GitHub на русском — всё о работе с GitHub
• gitignore.io — генератор шаблонов .gitignore для любого стека
• Learn Git Branching — интерактивный туториал по веткам и слиянию

Заключение

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

Ты узнал, зачем нужен Git и чем он отличается от GitHub. Установил Git и настроил его. Создал первый репозиторий и сделал коммит. Научился работать с ветками — создавать, переключаться, сливать. Подключил GitHub и отправил код в облако. Узнал, что такое пулл-реквест и код-ревью. Разобрался с типичными ошибками и узнал, как их исправлять.

Это база. С ней ты уже можешь участвовать в реальных проектах. Всё остальное — практика.

Что делать прямо сейчас? Выбери один из трёх шагов: настроить .gitignore в своём проекте, найти open-source проект и отправить первый пулл-реквест, или пройти интерактивный туториал по Git из полезных ссылок выше. Это займёт полчаса, а польза останется на всю карьеру.

Дальше будет C++, Docker и много практики. Подпишись на обновления блога, чтобы не пропустить следующие статьи.