git commit: как зафиксировать изменения и работать с индексом Git

git commit — это команда, которая фиксирует подготовленные изменения в истории репозитория как отдельную точку, к которой потом можно вернуться. Коммит записывает не все, что лежит в папке, а только то, что вы предварительно собрали в индексе командой git add.

Ниже разберем коммит по шагам реального цикла: как подготовить изменения, проверить, что именно уйдет в коммит, зафиксировать их, исправить последний коммит и убрать из индекса лишнее. Все команды — с фактическим выводом терминала на актуальном Git (ветка 2.5x на 2026 год).

Что такое Git и индекс: короткая вводная

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

Для работы с коммитами важно различать три состояния файлов — это ключ ко всему остальному:

• Рабочий каталог (working directory) — файлы проекта, которые вы редактируете прямо сейчас.
• Индекс (staging area, «подготовленная область») — промежуточная зона, куда командой git add вы складываете изменения, отобранные в следующий коммит.
• Коммит — зафиксированный снимок того, что было в индексе на момент фиксации, плюс автор, дата, сообщение и ссылка на родительский коммит.

Смысл индекса — собрать в один коммит именно нужные изменения, а не все подряд. Отредактировали пять файлов, а зафиксировать хотите пока два — добавляете в индекс только их.

Установка и первичная настройка

Установка зависит от системы: на Windows — установщик с git-scm.com (ставит Git и терминал Git Bash); на macOS — xcode-select --install или brew install git; на Linux — через пакетный менеджер, например sudo apt install git.

Сразу после установки нужно один раз представиться — имя и почта попадут в каждый коммит. Флаг --global задает настройку для всех репозиториев пользователя:

git config --global user.name "Ivan Petrov"
git config --global user.email "ivan@example.com"

Проверить, что записалось:

git config --global --list
# user.name=Ivan Petrov
# user.email=ivan@example.com

Частая ошибка новичка — опечатка в двойном дефисе. Покажем ее тройкой «неверно — результат — исправление»:

git config -global user.name "Ivan"

error: did you mean `--global` (with two dashes)?

git config --global user.name "Ivan"   # два дефиса перед global

Первый коммит: init, add, commit

Пройдем путь от пустой папки до первого коммита. Создаем репозиторий командой git init. Флагом -b сразу зададим имя основной ветки:

git init -b main
# Initialized empty Git repository in /home/ivan/myproject/.git/

Про имя ветки важно знать точно. Без -b Git возьмет имя из настройки init.defaultBranch, а если она не задана — использует встроенный резерв master (переход резерва на main заявлен к Git 3.0, но в ветке 2.5x он еще master). При этом GitHub, GitLab и некоторые установщики Git заранее настраивают main. Поэтому надежнее задавать имя явно через -b main или один раз прописать git config --global init.defaultBranch main — тогда вывод команд ниже будет предсказуемым независимо от окружения.

Добавим файл и посмотрим, что видит Git, командой git status:

echo "print('hello')" > app.py
git status

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    app.py

nothing added to commit but untracked files present (use "git add" to track)

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

Файл пока в статусе untracked — Git его видит, но не отслеживает. Команда git add переносит изменения в индекс:

git add app.py
git status

On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
    new file:   app.py

Изменение подготовлено. Фиксируем его командой git commit с сообщением через флаг -m:

git commit -m "Add app.py with hello output"

[main (root-commit) a1b2c3d] Add app.py with hello output
 1 file changed, 1 insertion(+)
 create mode 100644 app.py

Готово: изменение в истории. Идентификатор a1b2c3d — начало SHA-хеша коммита, по которому на него можно сослаться.

Проверка перед коммитом: git status, git diff, git diff —cached

Перед фиксацией полезно посмотреть не только список файлов (git status), но и сами строки, которые уйдут в коммит. Здесь новички часто путают две команды, и разница принципиальна.

• git diff (без параметров) показывает изменения рабочего каталога против индекса — то, что вы поменяли, но еще НЕ добавили через git add.
• git diff --cached (он же git diff --staged) показывает индекс против последнего коммита (HEAD) — то есть ровно содержимое будущего коммита.

Разберем на примере. Изменим уже отслеживаемый файл и сначала посмотрим незастейдженную правку:

echo "print('bye')" >> app.py
git diff

diff --git a/app.py b/app.py
index 180cf83..b9a4f01 100644
--- a/app.py
+++ b/app.py
@@ -1 +1,2 @@
 print('hello')
+print('bye')

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

git add app.py
git diff
# (пусто: незастейдженных изменений не осталось)
git diff --cached

diff --git a/app.py b/app.py
index 180cf83..b9a4f01 100644
--- a/app.py
+++ b/app.py
@@ -1 +1,2 @@
 print('hello')
+print('bye')

После git add пустой git diff — это норма: правка уже в индексе, и увидеть ее можно через git diff --cached. Привычка перед коммитом смотреть именно git diff --cached избавляет от коммитов «не того, что думал». Дальше — обычный git commit -m "...".

Как оформить сообщение коммита

Коммит — это логически завершенный шаг: добавили функцию, починили ошибку, обновили текст. Хорошее сообщение отвечает на вопрос «что изменилось», коротко и по делу: Fix login validation, а не изменения или фикс2. Это описание увидят коллеги в истории, поэтому одна внятная строка экономит всем время.

Флаг -m задает сообщение прямо в командной строке. Без -m Git откроет настроенный текстовый редактор и попросит ввести сообщение там. Какой именно редактор — определяется по порядку GIT_EDITOR -> core.editor -> VISUAL -> EDITOR; если ничего не задано, во многих сборках это Vim. Проверить, что откроется, можно так:

git var GIT_EDITOR

Если вы оказались в Vim и растерялись: сохранить сообщение и выйти — Esc, затем :wq и Enter (:q без сохранения при измененном буфере Vim выйти не даст). Чтобы вообще не попадать в редактор, используйте -m.

Про частоту коммитов: делать коммит после каждой строки не нужно, но и копить все в один огромный коммит тоже плохо. Ориентир — один коммит на одно завершенное изменение.

Правка после коммита: amend и отмена staging

Две операции нужны почти каждый день, поэтому держим их в основном тексте, а не в справке.

Исправить последний коммит — git commit --amend. Ошиблись в сообщении или забыли добавить файл — можно переписать последний коммит:

git commit --amend -m "Add app.py with greeting"

Важная граница: --amend создает коммит заново (с новым хешем), поэтому применять его безопасно, только пока коммит НЕ отправлен на сервер. Переписывать уже запушенную историю, которую видят коллеги, не стоит.

Убрать файл из индекса — git restore --staged. Добавили в индекс лишнее — вернем файл из подготовленного состояния обратно в рабочий каталог, не теряя правок:

git restore --staged app.py

Файл и его изменения остаются на месте, просто перестают быть подготовленными к коммиту. В старых версиях Git (до 2.23) ту же роль играл git reset app.py — он и сейчас работает.

Как читать историю: git log

Историю коммитов показывает git log. Флаг --oneline сжимает каждый коммит в одну строку:

git log --oneline

7f3a9c1 Add greeting to app.py
a1b2c3d Add app.py with hello output

Без --oneline Git покажет по каждому коммиту автора, дату и полное сообщение. Указатель HEAD при этом отмечает, на каком коммите вы сейчас находитесь.

Работа с сервером: push и pull

Пока все происходило локально. Чтобы делиться кодом, нужен удаленный репозиторий (GitHub, GitLab и т.п.): git clone <url> копирует его на диск целиком, git push отправляет ваши коммиты на сервер, git pull забирает чужие.

Типичная ситуация: git push отклонен, потому что на сервере уже есть коммиты коллег, которых нет у вас:

git push

 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'origin'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally.

Безопасный порядок действий — не вслепую «pull и снова push», а сначала посмотреть расхождение. Сначала загрузим чужие коммиты без слияния и оценим разницу:

git fetch
git log --oneline HEAD..origin/main   # что есть на сервере, но нет у вас

Дальше выбираем способ интеграции. git pull — это по сути git fetch плюс объединение, а каким именно способобом (fast-forward, rebase или merge) зависит от настроек команды:

• git pull --ff-only — подтянуть, только если ваши коммиты можно «доложить» поверх без слияния (безопасный вариант по умолчанию).
• git pull --rebase — перенести ваши локальные коммиты поверх серверных.
• обычный merge — если в команде принято сливать через merge-коммит.

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

Основные команды git: шпаргалка

Команда	Что делает
git init -b main	Создать репозиторий с основной веткой main
git clone <url>	Скопировать удаленный репозиторий на диск
git status	Показать состояние файлов (что изменено, что в индексе)
git add <файл>	Добавить изменения в индекс перед коммитом
git diff	Незастейдженные изменения (рабочий каталог против индекса)
git diff --cached	Подготовленные изменения (индекс против HEAD)
git commit -m "..."	Зафиксировать содержимое индекса в историю
git commit --amend	Переписать последний (еще не запушенный) коммит
git restore --staged <файл>	Убрать файл из индекса, не теряя правок
git log --oneline	Показать историю коммитов кратко
git pull --ff-only	Безопасно подтянуть изменения с сервера
git push	Отправить свои коммиты на сервер
git help <команда>	Открыть встроенную справку по команде

Выводы

• git commit фиксирует содержимое индекса, а не всю папку целиком — изменения, не добавленные через git add, в коммит не попадают.
• Рабочий цикл — три состояния: рабочий каталог -> индекс (git add) -> коммит (git commit); индекс существует, чтобы собрать в коммит именно нужное.
• Перед коммитом смотрите git diff --cached — именно он показывает, что уйдет в коммит; обычный git diff показывает только незастейдженное.
• Последний коммит правится через --amend, лишнее из индекса убирается через restore --staged — но --amend безопасен лишь до push.
• Имя ветки по умолчанию задается явно (-b main или init.defaultBranch); встроенный резерв в текущем Git все еще master.
• Отклоненный push лечится не вслепую: сначала git fetch и просмотр расхождения, затем pull --ff-only / --rebase / merge по правилам команды, без force в общей ветке.

Где применяется / связь с практикой

Смежные темы: Где писать программный код: программы для программирования в 2026 году, Что нужно знать о Git: введение в контроль версий.

FAQ

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

Что будет с изменениями, которые я не добавил в индекс, когда я делаю коммит?
Они останутся в рабочем каталоге как незафиксированные — коммит их не тронет и не удалит. В следующий коммит они попадут, только если вы добавите их через git add.

Можно ли сделать коммит сразу всех измененных отслеживаемых файлов, минуя git add?
Да, флаг git commit -a -m "..." автоматически стейджит изменения в уже отслеживаемых файлах. Но новые (untracked) файлы он не подхватит — их по-прежнему нужно добавить через git add.