Git встречает разработчика в первый же день работы. Кто-то слышал о нём ещё на курсах, кто-то впервые увидел в корпоративном чате. Но рано или поздно перед каждым специалистом встаёт одна и та же задача: понять, что именно надо набрать в терминале, чтобы не сломать проект и не потерять свои правки.
Шпаргалок в интернете много. Почти все они устроены как словарь — команды по алфавиту, от add до revert. С практической точки зрения это бесполезно. Разработчик не думает: «какая у меня сейчас команда по списку?» Он думает: «я только что написал код, как его сохранить?» или «всё сломалось, как откатить?»
Поэтому в нашем материале команды сгруппированы по сценариям. Выбор зависит от того, что вы делаете на текущем этапе. От момента, когда вы только создали репозиторий, до ситуации, когда случайно удалили файл и хотите его вернуть.
Одно важное замечание. Все примеры в статье предполагают, что дефолтная ветка называется main. В старых проектах она может называться master — это наследие прошлого. С 2020 года GitHub и другие платформы перешли на main. Если видите в своём репозитории master, просто мысленно подставляйте main.
ВАМ ПРИШЛО ПРИГЛАШЕНИЕ 💌
Приходите к нам в соцсети поделиться своим мнением и почитать, что пишут другие. А ещё там выходит дополнительный контент, которого нет на сайте — шпаргалки, опросы и разная дурка. В общем, вот тележка, вот ВК — велком!
Как устроен Git: три состояния файла
Перед тем как вводить команды, полезно понять, как Git вообще видит ваши файлы. Без этого многие действия покажутся нелогичными: «я добавил файл, а он не сохранился», «я изменил код, а Git говорит, что ничего не поменялось».
У Git три основные зоны, в которых может находиться файл:
- Рабочая директория. Это просто ваши файлы на диске. Те, что вы открываете в редакторе, правите, сохраняете. Git видит, что они изменились, но пока ничего с ними не делает.
- Индекс — его ещё называют staging area или областью подготовленных файлов. Это промежуточное хранилище. Сюда вы добавляете файлы, которые хотите включить в следующий коммит. Индекс — это список того, что попадёт в сохранённую версию.
- Репозиторий (директория Git). Здесь хранятся все зафиксированные коммиты. Это история проекта, которая уже сохранена надёжно.
Жизненный цикл файла выглядит так. Вы редактируете файл в рабочей директории — он становится изменённым (modified). Выполняете git add — файл попадает в индекс, становится подготовленным (staged). Выполняете git commit — содержимое индекса сохраняется в репозитории как новый коммит.
Большинство ошибок новичков связаны с тем, что они путают эти зоны. «Я сохранил файл, а Git его не видит» — потому что не сделали git add. «Я сделал git add, но коммита нет» — потому что забыли git commit. Запомните эту цепочку: рабочая директория → git add → индекс → git commit → репозиторий.
Старт: создание и клонирование репозитория
Есть два варианта. Вы либо создаёте новый репозиторий с нуля, либо скачиваете существующий.
Создать новый репозиторий в текущей папке
git init
После этой команды в папке появится скрытая директория .git. Там будет вся служебная информация: история коммитов, настройки, ветки. Если удалить эту папку, Git перестанет считать проект репозиторием — все коммиты исчезнут.
Скопировать существующий репозиторий
git clone <url>
Команда скачивает полную копию проекта с удалённого сервера (например, с GitHub). Вместе с файлами приезжает вся история коммитов, все ветки.
Важно. Некоторые новички скачивают проект через кнопку «Download ZIP» на GitHub. Это работает, но только для просмотра. ZIP-архив не содержит папку .git — вы не сможете делать коммиты, пуши и пуллы. Для работы нужен именно git clone.
Настройка пользователя
Первый коммит без настройки имени и почты выдаст ошибку. Git должен знать, кто автор изменений.
git config –global user.name “Ваше Имя”
git config –global user.email “your.email@example.com”
Флаг –global означает, что настройки применяются ко всем репозиториям на компьютере. Если нужно задать имя только для одного проекта, уберите –global и выполните команду внутри папки репозитория.
Привязать удалённый репозиторий
Если вы создали репозиторий через git init, а потом завели пустой репозиторий на GitHub, нужно сказать Git, куда отправлять изменения.
git remote add origin <url>
origin — стандартное имя для удалённого репозитория. Можно назвать иначе, но все привыкли к origin.
Ежедневный цикл: status, add, commit, push
Это ядро работы с Git. Цикл, который разработчик повторяет десятки раз за день.
Проверить состояние
git status
Первая команда, которую стоит запускать перед любыми действиями. Она показывает, какие файлы изменены, какие добавлены в индекс, какие вообще не отслеживаются Git.
Вывод git status делится на несколько секций:
- Changes to be committed — файлы, которые уже в индексе и попадут в следующий коммит.
- Changes not staged for commit — файлы, которые изменены, но ещё не добавлены в индекс.
- Untracked files — новые файлы, о которых Git не знает.
Добавить изменения в индекс
git add <файл>
Добавляет конкретный файл в индекс.
git add .
Добавляет все изменения в текущей папке и подпапках.
git add -A
Добавляет все изменения во всём репозитории, включая удалённые файлы.
Создать коммит
git commit -m “Сообщение”
Фиксирует всё, что находится в индексе, и сохраняет снимок состояния в репозитории.
git commit -am “Сообщение”
Удобный вариант, который одновременно добавляет в индекс все изменения в отслеживаемых файлах и создаёт коммит. Работает только для файлов, которые Git уже отслеживает. Новые файлы эта команда не видит — их нужно добавлять отдельно через git add.
Исправить последний коммит
git commit –amend
Если вы забыли добавить какой-то файл или опечатались в сообщении, не нужно создавать отдельный коммит для правки. –amend заменяет последний коммит новым. Вы можете добавить забытый файл в индекс, а затем выполнить git commit –amend — старый коммит исчезнет, появится новый, объединяющий все изменения.
Важно. –amend переписывает историю. Если коммит уже был отправлен на сервер ( git push ), использовать –amend не стоит — это создаст конфликт у коллег.
Отправить изменения на сервер
git push
Отправляет локальные коммиты в удалённый репозиторий.
Если вы работаете над новой веткой, которую ещё не отправляли на сервер, Git попросит указать, куда именно пушить: git push -u origin main
Флаг -u (или –set-upstream) связывает локальную ветку с удалённой. После этого можно будет писать просто git push без дополнительных аргументов.
Про сообщения коммитов
Грамотное сообщение коммита отвечает на вопрос «почему это изменение сделано?» Не «исправил баг», а «исправил падение при вводе пустой строки в поле email». Длина — 50 символов для заголовка, дальше можно более подробное описание через пустую строку. Это не жёсткое правило, но хорошая привычка. В командах с флагом -m сообщение должно быть кратким.
Закрепите Git на настоящем проекте
Команды Git проще запоминаются, когда рядом есть код, который действительно жалко потерять. На курсах Практикума можно пройти полный рабочий цикл: создать проект, завести репозиторий, работать в отдельных ветках и отправлять изменения на ревью.
Для старта подойдут «Python-разработчик» и «Фронтенд-разработчик».
По промокоду: KOD (можно просто нажать).
Бесплатная вводная часть тоже есть — карту привязывать не нужно.
Получение изменений: pull и fetch
Коллеги тоже работают над проектом. Их изменения нужно забирать.
Скачать изменения без слияния
git fetch
Команда скачивает все новые коммиты из удалённого репозитория, но не вливает их в вашу текущую ветку. Вы можете посмотреть, что изменилось, прежде чем применять изменения к своей работе.
Скачать и влить изменения
git pull
git pull — это git fetch и git merge одной командой. Она скачивает изменения и сразу объединяет их с вашей веткой.
Когда использовать fetch, а когда pull ? Если вы хотите сначала посмотреть, что изменилось, оценить масштаб, — выбирайте fetch. Если уверены, что готовы принять изменения сразу, — pull.
Есть ещё вариант git pull –rebase. Он не создаёт коммит слияния, а перекладывает ваши локальные коммиты поверх новых изменений. История становится линейной и чище, но требует понимания, что такое rebase.
Ветки: создание, переключение, слияние
Ветки — главный инструмент для параллельной работы. Каждая новая задача или исправление бага обычно делаются в отдельной ветке.
Посмотреть ветки
git branch
Показывает список локальных веток. Текущая ветка помечена звёздочкой.
Создать ветку
git branch feature/login
Создаёт новую ветку с именем feature/login, но не переключается на неё.
Переключиться на ветку
Современный способ:
git switch feature/login
Переключает на существующую ветку.
git switch -c feature/login
Создаёт новую ветку и сразу переключается на неё.
Старый способ (всё ещё работает, но switch удобнее и безопаснее):
git checkout feature/login
git checkout -b feature/login
Почему switch лучше? У checkout слишком много задач: переключение веток, восстановление файлов, работа с отдельным HEAD. Это порождает путаницу. В Git 2.23 (август 2019) функциональность разделили: switch для веток, restore для файлов. Новичкам стоит использовать именно их.
Влить ветку в текущую
git merge feature/login
Берёт все коммиты из ветки feature/login и объединяет их с текущей веткой.
Конфликты слияния
Конфликт возникает, когда в двух ветках меняются одни и те же строки одного файла. Git не знает, какой вариант правильный, и просит помощи.
Выглядит конфликт в файле так:
<<<<<<< HEAD
console.log("Hello from main");
=======
console.log("Hello from feature");
>>>>>>> feature/login
Верхняя часть (между <<<<<<< HEAD и =======) — код из текущей ветки. Нижняя (между ======= и >>>>>>> feature/login) — код из вливаемой ветки.
Что делать:
- Открыть файл в редакторе
- Убрать маркеры (
<<<<<<<,=======,>>>>>>>) - Оставить нужный код (или скомбинировать оба варианта)
- Сохранить файл
- Выполнить
git add <файл> - Выполнить
git commit
Git запомнит, что конфликт разрешён, и завершит слияние.
Отмена изменений: restore, reset, revert
Этот раздел спасает разработчиков каждый день. Три команды для трёх разных ситуаций.
Отменить незакоммиченные правки в файле
git restore <файл>
Если вы изменили файл, но ещё не сделали git add, эта команда вернёт его к состоянию последнего коммита. Все правки исчезнут безвозвратно.
git restore –staged <файл>
Если вы уже сделали git add, но передумали включать файл в коммит, эта команда убирает его из индекса. Сам файл остаётся изменённым.
Передвинуть ветку назад (переписать историю)
git reset –soft <коммит>
Отменяет коммиты, но оставляет изменения в индексе. Можно перекоммитить заново.
git reset –mixed <коммит>
Отменяет коммиты и убирает изменения из индекса. Файлы остаются изменёнными в рабочей директории. Это поведение по умолчанию.
git reset –hard <коммит>
Отменяет коммиты, стирает изменения из индекса и из рабочей директории. Всё, что вы не закоммитили, исчезнет навсегда. Эта опция опасна. Используйте –hard только если абсолютно уверены, что незакоммиченные правки вам не нужны.
Важное предупреждение: git reset переписывает историю. Никогда не используйте его для коммитов, которые уже были отправлены на сервер ( git push ). Коллеги, которые успели скачать эти коммиты, получат конфликты.
Безопасно отменить уже опубликованный коммит
git revert <коммит>
Создаёт новый коммит, который отменяет изменения указанного коммита. История не переписывается, просто добавляется новый коммит с обратными изменениями. Это единственный безопасный способ откатить изменения, которые уже на сервере.
Stash: отложить изменения на потом
Ситуация: вы пишете код, всё в процессе, коммитить рано. Внезапно прилетает срочная задача в другой ветке. Переключиться нельзя — Git не даст, потому что есть незакоммиченные изменения.
Решение — git stash.
git stash
Убирает все незакоммиченные изменения из рабочей директории и индекса, сохраняя их в отдельном хранилище. Рабочая директория становится чистой, как после последнего коммита. Можно спокойно переключаться на другую ветку.
git stash list
Показывает список сохранённых наборов изменений.
git stash pop
Возвращает последние сохранённые изменения в рабочую директорию и удаляет их из списка stash.
git stash apply
Возвращает изменения, но оставляет их в списке stash.
Разница между pop и apply: pop удаляет stash после применения, apply — оставляет. Если вы планируете использовать одни и те же изменения в нескольких местах, берите apply. В остальных случаях — pop, чтобы не засорять список.
Важный нюанс: stash легко забыть. Если вы сохранили изменения через stash, ушли на другую задачу, а потом вернулись и забыли применить stash обратно, изменения так и будут лежать в хранилище сколько потребуется. Хорошая привычка — сразу после возвращения на ветку выполнять git stash pop.
История: log, diff, blame
Git хранит всю историю изменений. Вопрос в том, как в ней ориентироваться.
Просмотр истории коммитов
git log
Показывает полную историю: хеш коммита, автор, дата, сообщение. Для повседневного использования слишком много информации.
git log –oneline
Сокращённый формат: каждый коммит на одной строке. Хеш (сокращённый) и сообщение. Этого достаточно в 90% случаев.
git log –oneline –graph
Добавляет визуализацию ветвления. Полезно, когда нужно понять, как ветки расходились и сливались.
Сравнить изменения
git diff
Показывает разницу между рабочей директорией и индексом. Что изменилось, но ещё не добавлено в индекс.
git diff –staged
Показывает разницу между индексом и последним коммитом. Что уже добавлено в индекс и будет включено в следующий коммит.
git diff main..feature/login
Показывает разницу между двумя ветками.
Узнать, кто менял строку
git blame <файл>
Аннотирует каждую строку файла: в каком коммите она была изменена, кто автор, когда это было сделано.
Эта команда отвечает в том числе на классический вопрос: «кто написал этот кошмар?» Показывает автора и коммит для каждой строки. Но полезна она не для только поиска виноватых, но и для понимания, почему код написан именно так — можно посмотреть контекст изменений в соответствующем коммите.
Сводная шпаргалка: все команды одной таблицей
| Команда | Что делает |
|---|---|
| Старт и настройка | |
git init | Создать новый репозиторий в текущей папке |
git clone <url> | Скопировать удалённый репозиторий локально |
git config –global user.name “Имя” | Задать имя для коммитов |
git config –global user.email “email” | Задать email для коммитов |
git remote add origin <url> | Привязать удалённый репозиторий |
| Ежедневный цикл | |
git status | Показать состояние файлов |
git add <файл> | Добавить файл в индекс |
git add . | Добавить все изменения в текущей папке |
git commit -m “сообщение” | Создать коммит |
git commit -am “сообщение” | Добавить изменения в отслеживаемых файлах и создать коммит |
git commit –amend | Изменить последний коммит |
git push | Отправить коммиты на сервер |
git push -u origin main | Отправить и связать локальную ветку с удалённой |
| Получение изменений | |
git fetch | Скачать изменения без слияния |
git pull | Скачать и влить изменения |
| Ветки | |
git branch | Показать список веток |
git branch <имя> | Создать ветку |
git switch <ветка> | Переключиться на ветку |
git switch -c <ветка> | Создать и переключиться |
git merge <ветка> | Влить ветку в текущую |
| Отмена изменений | |
git restore <файл> | Отменить незакоммиченные правки |
git restore –staged <файл> | Убрать файл из индекса |
git reset –soft <коммит> | Отменить коммиты, оставить в индексе |
git reset –mixed <коммит> | Отменить коммиты, убрать из индекса |
git reset –hard <коммит> | Отменить коммиты, стереть все изменения |
git revert <коммит> | Безопасно отменить опубликованный коммит |
| Stash | |
git stash | Сохранить незакоммиченные изменения |
git stash list | Показать список сохранённых изменений |
git stash pop | Применить и удалить из списка |
git stash apply | Применить, оставить в списке |
| История | |
git log –oneline | Показать историю коммитов сокращённо |
git diff | Показать изменения в рабочей директории |
git diff –staged | Показать изменения в индексе |
git blame <файл> | Показать автора для каждой строки |
Git — это набор команд для конкретных ситуаций. Большинство разработчиков используют один и тот же небольшой набор команд каждый день. Остальные нужны реже, но знать о них полезно — когда случается нештатная ситуация, вы уже будете понимать, что искать.
Если команда делает не то, что вы ожидали, всегда можно заглянуть в документацию: git help <команда> или git-scm.com/docs. Там описаны все флаги и варианты использования. Шпаргалка помогает вспомнить, документация — разобраться глубже.
Советуем дополнительно почитать
- Open source: определение, суть, принципы и примеры — как устроена разработка открытого ПО, кто может менять чужой код и зачем проекты публикуют в общедоступных репозиториях.
- Как защитить API-ключи от утечки: чек-лист разработчика — где секреты попадают в историю Git, как настроить
.gitignore, secret scanning и безопасную ротацию ключей. - Microsoft добавила полноценную работу с пул-реквестами в VS Code — как просматривать ветки, историю коммитов и изменения PR непосредственно в редакторе.
- Claude Code — полный гайд: установка, команды и реальные сценарии — как терминальный AI-агент читает репозиторий, меняет файлы, запускает проверки и работает с Git.
- Как разработчику рассказать о себе, чтобы его хотели нанять — как использовать проекты, публичные репозитории, GitHub-активность и участие в код-ревью в портфолио.
Бонус для читателей
Если вам интересно погрузиться в мир ИТ и при этом немного сэкономить, держите наш промокод на курсы Практикума. Он даст вам скидку при оплате, безлимит на маркетплейсах и поможет с льготной ипотекой. Ладно, окей, это просто скидка, без остального, но хорошая.
