Собрали гайд по работе с Git для новичков. 

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

Сохраняйте и пользуйтесь.

Что такое Git и как он хранит изменения

Git — распределённая система контроля версий (distributed version control system, DVCS). С её помощью разработчики фиксируют изменения в коде, просматривают историю проекта и синхронизируют репозитории.

Репозиторий (repository) — это папка проекта вместе с историей изменений.

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

Когда локальная работа завершена, коммиты можно передать дальше. Git умеет обмениваться изменениями напрямую — например, через SSH. Но на практике чаще используют платформы вроде GitHub, GitLab или Bitbucket: там удобнее работать вместе, управлять доступом и проводить код-ревью.

Важно не путать их с самим Git:

• Git — это инструмент, который управляет историей изменений,

• а GitHub, GitLab и подобные — платформы, где хранятся Git-репозитории и где команды работают с кодом совместно.

Как Git хранит историю проекта

История проекта в Git состоит из коммитов (commit). Коммит фиксирует состояние файлов проекта в определённый момент времени и сохраняет его в истории репозитория.

При этом Git хранит историю не как список отдельных правок в файлах, а как снимки состояния проекта (snapshots). Каждый коммит — это снимок того, как выглядели файлы в момент сохранения. Когда нужно посмотреть разницу между версиями, Git сравнивает такие снимки и показывает изменения.

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

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

Как Git отслеживает изменения и готовит их к коммиту

В работе с Git файлы могут находиться в трёх состояниях:

1. Modified — файл изменён в рабочей директории (working directory), но эти изменения ещё не подготовлены к коммиту.

2. Staged — изменения добавлены в промежуточную область, staging area (её также называют index), и попадут в следующий коммит.

3. Committed — изменения уже сохранены в репозитории в виде коммита.

В итоге процесс выглядит так: вы меняете файлы в рабочей директории, добавляете нужные изменения в staging area, а затем создаёте коммит.

Staging area нужна, чтобы контролировать содержимое коммита. Например, можно изменить несколько файлов, но добавить в staging только часть изменений — и в коммит попадут только они.

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

Старт работы с Git

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

Для начала проверим, установлен ли Git на компьютере. Откройте терминал и введите:

git --version

Если система не распознаёт команду, Git нужно установить:

• для macOS — поставить Xcode Command Line Tools или скачать Git с сайта git-scm.com;

• для Windows — скачать и установить Git for Windows с сайта git-scm.com;

• для Linux — установить через пакетный менеджер (apt, dnf, pacman и другие).

После установки Git будет доступен в терминале. Через него и выполняют все команды.

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

Создание нового репозитория

Откройте терминал и перейдите в папку, где находятся файлы проекта. Для этого используйте команду cd — она переместит в нужную директорию:

cd путь/к/папке

После этого выполните команду:

git init

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

Клонирование репозитория

Если проект уже существует, например, на GitHub или GitLab, получите его локальную копию. 

Откройте терминал и перейдите в папку, куда хотите скачать проект:

cd путь/к/папке

Затем выполните команду git clone <адрес_репозитория>. Например:

git clone https://github.com/user/project.git

Git создаст новую папку с именем проекта и скачает туда содержимое репозитория вместе со всей историей коммитов.

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

Во время работы с проектом полезно регулярно проверять состояние репозитория и изменения в файлах. Для этого используют несколько базовых команд Git.

Посмотреть текущее состояние репозитория

Выполните команду:

git status

Git покажет, какие файлы изменены, какие уже добавлены в staging area и какие файлы ещё не отслеживаются. 

Например, вывод может выглядеть так:

On branch main
Changes not staged for commit:
  modified: index.html

Это означает, что файл index.html был изменён, но эти изменения ещё не подготовлены к коммиту.

Если файл создан впервые, он появится в разделе Untracked files:

Untracked files:
  style.css

То есть Git пока его не отслеживает.

Если изменений нет, git status покажет:

nothing to commit, working tree clean

Посмотреть изменения в файлах

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

git diff

Git сравнит текущие изменения в рабочей директории с тем, что находится в staging area (или последним коммитом, если staging пуст).

Например:

- <title>My site</title>
+ <title>My project</title>

Строки со знаком — показывают удалённый текст, а строки со знаком + — добавленный.

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

git diff --staged

Git покажет разницу между последним коммитом и содержимым staging area.

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

Для этого выполните команду:

git log

Git выведет список коммитов с их идентификаторами, авторами, датой и сообщением. 

Например:

commit a1b2c3d
Author: Ivan Ivanov
Date:   Mon Mar 10 12:30:00 2026

Add index page

Если история длинная, можно вывести каждый коммит одной строкой. Для этого используется команда:

git log --oneline

Подготовка изменений и создание коммитов

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

Добавить изменения в staging area

Чтобы подготовить файл к коммиту, выполните команду:

git add имя_файла

Например:

git add index.html

Git добавит в staging area текущее состояние файла — именно эти изменения попадут в следующий коммит.

Если нужно подготовить все изменения в текущей папке проекта, выполните:

git add .

Эта команда добавляет в staging area все изменённые и новые файлы в текущей директории и её вложенных папках.

Также можно использовать команду:

git add -A

Она добавляет в staging area все изменения в репозитории, включая удалённые файлы.

Проверить, какие изменения уже подготовлены к коммиту, можно командой:

git status

Git покажет их в разделе Changes to be committed.

Создать коммит

После того как нужные изменения добавлены в staging area, создайте коммит:

git commit -m "Сообщение коммита"

Например:

git commit -m "Add index page"

Git создаст новый коммит и сохранит текущее состояние подготовленных файлов.

Написать сообщение коммита

У каждого коммита должно быть короткое сообщение, которое объясняет, что вы поменяли.

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

Невнятные подписи к коммитам — к сожалению, довольно частая история. Когда в сообщении пишут что-нибудь вроде Update code или Changes, по нему невозможно понять, что именно было сделано.

Лучше писать сообщение одной строкой, в настоящем времени, и использовать простые глаголы, которые показывают действие: Add, Fix, Update, Remove. Писать можно и на русском — главное, чтобы по сообщению было понятно, что именно изменилось.

Примеры сообщений коммита:

Add index page
Fix login form
Update README

Работа с ветками

Ветки (branch) позволяют работать над разными задачами параллельно. Например, можно исправлять баг или разрабатывать новую функцию, не затрагивая основную версию проекта.

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

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

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

Чтобы увидеть ветки в репозитории, выполните команду:

git branch

Git покажет список веток, а ту, где вы находитесь, отметит символом *.

Например:

* main
  feature-login
  bugfix-auth

Создать новую ветку

Чтобы создать ветку, выполните:

git branch имя_ветки

Например:

git branch feature-login

Git создаст новую ветку, которая будет указывать на текущий коммит. При этом вы останетесь в той ветке, где были раньше.

Переключитесь на ветку

Чтобы начать работать в другой ветке, переключитесь на неё:

git switch имя_ветки

Новые коммиты будут добавляться уже в новую ветку.

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

Создание ветки и переключение можно сделать одной командой:

git switch -c имя_ветки

Слияние веток и разрешение конфликтов

Когда работа в отдельной ветке завершена, её изменения нужно объединить с основной веткой проекта. Этот процесс называется слиянием веток (merge).

Объединить ветки

Чтобы объединить изменения, сначала переключитесь в ветку, в которую хотите добавить коммиты. Например, в main.

git switch main

Затем выполните команду:

git merge имя_ветки

Например:

git merge feature-search

Git возьмёт коммиты из ветки feature-search и добавит их в текущую ветку.

Если изменения в ветках не пересекаются, Git выполнит слияние автоматически и создаст новый коммит с результатом объединения.

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

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

Представим, что в проекте есть файл README.md. В нём была строка:

My project

В основной ветке (main) её изменили так:

My project — task manager

А в ветке feature-docs — так:

My project for team management

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

Сообщение может выглядеть так:

CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.

Дальше Git ждёт, пока вы решите конфликт вручную. 

Как завершить слияние

После этого Git помечает конфликт прямо в файле. Например, README.md может выглядеть так:

<<<<<<< HEAD
My project — task manager
=======
My project for team management
>>>>>>> feature-docs

Эти строки — служебные метки Git. Они показывают два варианта изменений:

• часть между <<<<<<< HEAD и ======= — версия из текущей ветки;

• часть между ======= и >>>>>>> feature-docs — версия из ветки, которую вы объединяете.

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

Откройте файл и вручную исправьте конфликтный участок.

Можно оставить один из двух вариантов либо объединить их, например:

My project — task manager for teams

После этого удалите вот эти служебные строки Git:

<<<<<<< HEAD
=======
>>>>>>> feature-docs

Когда файл исправлен, сохраните его и добавьте в staging area:

git add README.md

После этого завершите слияние:

git commit

Git создаст коммит, который зафиксирует результат объединения веток.

Обновление ветки относительно main

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

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

Сделать это можно двумя способами: через слияние (merge) или через перемещение коммитов (rebase).

Обновление через merge

Самый простой способ — добавить изменения из main в текущую ветку.

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

git switch имя_ветки

Затем выполните:

git merge main

Представим, что в основной ветке main появились новые коммиты:

A — B — C  (main)

А вы в своей ветке сделали два коммита:

A — B — C  (main)
       
        D — E  (feature)

Git объединит ветки и создаст новый коммит слияния.

История будет выглядеть так:

A — B — C -------- (main)
                
        D — E ----M  (feature)

Коммит M —это коммит слияния, который объединяет изменения из main и feature.

Обновление через rebase

Другой способ — перенести коммиты вашей ветки поверх актуальной версии main.

Для этого выполните:

git rebase main

Git возьмёт ваши коммиты (D и E) и создаст их новые версии поверх последних коммитов из main.

В результате история становится линейной — как будто работа в ветке началась уже после последних изменений в main.

A — B — C — D' — E'  (feature)

Когда используют merge, а когда rebase

merge и rebase решают похожую задачу, но они не взаимозаменяемы. Поясняем. 

Ситуация 1:

1. разработчик создаёт ветку под задачу;

2. работает в ней и делает коммиты;

3. создаёт Pull Request / Merge Request;

4. после проверки ветку объединяют с main.

В этот момент чаще всего используют merge, потому что:

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

Над веткой могли работать несколько человек. Если переписать историю коммитов через rebase, можно нарушить работу других разработчиков.

Ситуация 2: 

1. вы создали ветку под задачу;

2. работаете в ней несколько дней;

3. за это время в main появились новые коммиты;

4. нужно подтянуть эти изменения в свою ветку.

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

Работа с удалённым репозиторием

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

Разберём базовые операции, которые для этого используют.

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

Чтобы отправить новые коммиты на сервер, выполните:

git push

Git отправит изменения из текущей ветки в связанную ветку удалённого репозитория.

Если ветка отправляется впервые, укажите имя удалённого репозитория и ветки:

git push -u origin имя_ветки

origin — это имя удалённого репозитория. Обычно Git создаёт его автоматически при клонировании проекта.

После этого локальная ветка будет связана с удалённой, и в дальнейшем достаточно использовать обычную команду git push.

Получение изменений из удалённого репозитория

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

Для этого используют две команды:

1. Команда git fetch скачивает новые коммиты из удалённого репозитория и обновляет информацию о состоянии удалённых веток. При этом текущая ветка не изменяется.

   Это удобно, если вы хотите сначала посмотреть, какие изменения появились в проекте.

2. Команда git pull скачивает изменения из удалённого репозитория и сразу применяет их к текущей ветке.

   Фактически pull выполняет две операции подряд: git fetch и git merge.

   После этого локальная ветка обновляется и содержит последние изменения из удалённого репозитория.

Закрепляем: fetch только скачивает изменения, а pull скачивает их и сразу объединяет с текущей веткой.

Итого: как выглядит обычный рабочий цикл

Сначала разработчик получает последние изменения из общего репозитория:

git pull

После этого он работает с кодом: изменяет файлы, добавляет изменения в staging area и создаёт коммиты.

Когда работа над задачей готова, изменения отправляют в удалённый репозиторий:

git push

После этого другие участники команды могут получить эти изменения через git pull или git fetch.

Типовые ошибки начинающих

В этом разделе разберём несколько частых проблем, с которыми сталкиваются новички при работе с Git, и посмотрим, как их исправить.

Изменения не попали в коммит

Что произошло: файл не был добавлен в staging area. Git фиксирует в коммите только те изменения, которые были подготовлены через git add.

Что сделать:

Проверьте состояние репозитория:

git status

Если файл находится в состоянии modified или untracked, добавьте его в staging area:

git add имя_файла

После этого создайте коммит:

git commit -m "Описание изменений"

В коммит попали лишние файлы

Что произошло:

Чаще всего это происходит, если используется команда:

git add .

Она добавляет в staging area все изменения в текущей папке.

Что сделать:

Если коммит ещё не создан, удалите файл из staging area:

git restore --staged имя_файла

После этого файл останется изменённым, но не попадёт в коммит.

Нужно изменить последний коммит

Коммит уже создан, но вы забыли добавить файл или ошиблись в сообщении.

Что сделать:

Если коммит ещё не отправлен в удалённый репозиторий, его можно изменить:

git commit --amend

Эта команда позволяет изменить сообщение коммита или добавить в него новые файлы.

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

Конфликт при объединении веток

При выполнении merge или rebase Git сообщает о конфликте.

Что произошло:

Один и тот же участок файла был изменён по-разному в разных ветках.

Подробно этот случай мы уже разбирали в разделе «Слияние веток и разрешение конфликтов», поэтому здесь не будем повторять объяснение. 

Работа вне ветки (detached HEAD)

Git сообщает, что вы находитесь в состоянии detached HEAD:

You are in 'detached HEAD' state

Это происходит, если переключиться не на ветку, а на конкретный коммит:

git checkout <commit>

В этом состоянии новые коммиты не принадлежат ни одной ветке.

Что сделать:

Создайте новую ветку от текущего коммита:

git switch -c имя_ветки

Теперь коммиты будут сохраняться в этой ветке.

Не удаётся отправить изменения (push rejected)

Вы выполняете git push, а Git отвечает сообщением вроде:

! [rejected] main -> main (non-fast-forward)

Что произошло:

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

Git не позволяет перезаписать историю ветки, поэтому отклоняет отправку.

Что сделать:

Сначала получите последние изменения из удалённого репозитория:

git pull

После этого попробуйте отправить изменения снова:

git push

Коммит сделан не в той ветке

Вы сделали коммит и поняли, что работали не в той ветке. Например, изменения случайно попали в main.

Что произошло:

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

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

git branch

Текущая ветка будет отмечена символом *.

Что сделать:

Если коммит только что создан, можно создать новую ветку от текущего состояния:

git switch -c имя_ветки

Коммит окажется в новой ветке, и дальше можно работать уже в ней.

Таблица с основными командами Git

Собрали все команды из статьи в таблицу, чтобы вам было проще их запомнить.

---

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

• курса «Специалист по информационной безопасности: старт карьеры»;

• программы «1С‑программист: первые шаги в профессию» с практикой в каждом занятии;

• занятия «Гибкое планирование: как достичь целей без саморазрушения»;

• вводного курса магистратуры НИУ ВШЭ «Бэкенд-разработка и архитектура программных систем»;

• видеолекций «Нейросети для работы: пошаговый план применения».

Или можно стать востребованным сотрудником и открыть открыть бóльшие перспективы в карьере с профессиональным обучением:

• на программе повышения квалификации «Вайб-кодинг»;

• на курсе для действующих IT-специалистов «DevOps-инженер» с изучением ИИ и программой трудоустройства;

• в магистратуре НИУ ВШЭ «Бэкенд-разработка и архитектура программных систем»;

• на интенсиве «Управление дронами с использованием компьютерного зрения»;

• на курсе «Нейросети для разработчиков».