↓Перейти к содержанию
  1. Git: руководства и команды/

git add, commit, push: основной рабочий цикл Git для новичков

·10 минут·

Каждый день разработки вы будете повторять одну и ту же последовательность:

  1. Редактируете файлы в своём проекте
  2. Сохраняете изменения локально в Git с помощью git add и git commit
  3. Отправляете на сервер (GitHub, GitLab) с помощью git push

Эти три команды — git add, git commit и git push — являются основой рабочего процесса с Git. Понимание того, как они работают и почему они необходимы в таком порядке, критично для любого разработчика.

В этой статье разберём:

  • Зачем нужны три отдельные команды вместо одной
  • Как использовать каждую команду с примерами
  • Полный пример рабочей сессии
  • Как сократить повторяющийся ввод
  • Как отменить ошибки на каждом этапе

Три шага рабочего цикла #

Представьте Git как трёхслойную систему:

┌─────────────────────────────────────────────────┐
│        GitHub / GitLab (удалённый сервер)       │
│                  ваш код видят все              │
└────────────────────────────────────────────────┬┘
                                                  ↑ git push
┌───────────────────────────────────────────────┬┘
│     Локальный репозиторий (.git/objects)       │
│  ваш код сохранён в истории локально на ПК   │
└─────────────────────────────────────────────┬──┘
                                               ↑ git commit
┌──────────────────────────────────────────┬──┘
│         Staging Area (индекс / stage)    │
│ файлы готовы к сохранению в историю     │
└───────────────────────────────────────┬──┘
                                         ↑ git add
┌───────────────────────────────────┬───┘
│    Working Directory (рабочая папка)│
│  файлы, которые вы редактируете     │
└─────────────────────────────────────┘

Вот почему нужны все три команды:

Шаг 1: git add — выбирают файлы для сохранения #

Зачем это нужно? Вы можете отредактировать 10 файлов, но захотеть сохранить только 3 из них в этом коммите. git add позволяет выбрать, какие файлы войдут в коммит.

# Добавить конкретный файл
$ git add main.py

# Добавить несколько файлов
$ git add main.py utils.py config.json

# Добавить все изменённые файлы в текущей папке
$ git add .

# Интерактивный выбор (только для опытных)
$ git add -p  # patch mode

После git add файлы находятся в Staging Area — они отмечены как готовые к сохранению, но ещё не сохранены.

Шаг 2: git commit — сохраняют в историю локально #

Зачем это нужно? git commit создаёт точку сохранения в истории вашего проекта. Это как сохранение в видеоигре — вы можете вернуться к этому моменту в любой момент.

# Создать коммит с кратким сообщением
$ git commit -m "Исправлена ошибка в парсере"

# Создать коммит, но открыть редактор для подробного сообщения
$ git commit

# Коммитить напрямую все отслеживаемые файлы (без git add)
$ git commit -am "Сообщение коммита"

После git commit ваши изменения сохранены локально на вашем компьютере. Никто другой их ещё не видит.

Шаг 3: git push — отправляют на сервер #

Зачем это нужно? git push загружает ваши локальные коммиты на GitHub, GitLab или другой хостинг. Теперь другие разработчики могут видеть вашу работу.

# Отправить текущую ветку на origin (обычный способ)
$ git push

# Отправить на конкретный удалённый сервер и ветку
$ git push origin main

# Первый push новой ветки (нужен флаг -u)
$ git push -u origin feature-branch

# Отправить конкретную ветку
$ git push origin feature-branch

После git push ваши коммиты видны на сервере и доступны коллегам.

Шаг 1: git add #

Синтаксис и базовое использование #

$ git add [файл или папка]

Примеры #

# Добавить один файл
$ git add src/main.py

# Добавить файл из другой папки
$ git add config/settings.json

# Добавить все файлы в текущей папке и подпапках
$ git add .

# Добавить несколько файлов
$ git add src/main.py src/utils.py README.md

# Добавить все файлы с определённым расширением
$ git add *.py

# Удалить файл из staging area (отменить git add)
$ git reset HEAD filename.py

Просмотр того, что добавлено #

# Показать файлы в staging area
$ git status

# Показать точные различия в staging area
$ git diff --staged

Пример вывода:

On branch main
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
        modified:   main.py
        modified:   config.json

Частая ошибка новичков #

# Новичок редактирует файлы
$ vim main.py

# Пропускает git add и идёт сразу на git commit
$ git commit -m "Исправлена ошибка"

# Коммит выполняется, но ТОЛЬКО для ранее отслеживаемых файлов
# Новые или измененные файлы могут быть пропущены!

Шаг 2: git commit #

Синтаксис #

# Коммит с сообщением в одну строку
$ git commit -m "Ваше сообщение"

# Коммит с открытием редактора для подробного сообщения
$ git commit

# Коммит всех отслеживаемых файлов без git add
$ git commit -am "Сообщение"

# Изменить сообщение последнего коммита
$ git commit --amend -m "Новое сообщение"

Примеры хороших сообщений коммитов #

# ✓ Хорошо: ясное, конкретное описание
$ git commit -m "Исправлена ошибка обработки null в парсере JSON"

# ✓ Хорошо: использование префиксов (Conventional Commits)
$ git commit -m "fix: исправлена ошибка при обработке пустых значений"
$ git commit -m "feat: добавлена новая функция для экспорта CSV"
$ git commit -m "docs: обновлена документация API"

# ✗ Плохо: слишком общее и неинформативное
$ git commit -m "Исправлено"
$ git commit -m "Обновлены файлы"
$ git commit -m "WIP"

Коммит с подробным описанием #

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

$ git commit

Откроется редактор (обычно vi или nano):

Исправлена ошибка в парсере JSON

Детали изменений:
- Добавлена проверка на null перед парсингом
- Обновлены unit тесты для покрытия граничных случаев
- Улучшена обработка ошибок с информативными сообщениями
- Совместимо с Python 3.8+

Fixes: #123

Сохраните и закройте редактор — коммит создан.

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

# Показать последний коммит
$ git log -1

# Показать последний коммит с деталями файлов
$ git show HEAD

# Показать все коммиты кратко
$ git log --oneline

Пример:

commit abc1234567890def (HEAD -> main)
Author: Ivan Petrov <[email protected]>
Date:   Fri Feb 20 10:30:00 2026 +0300

    fix: исправлена ошибка в парсере JSON

    Добавлена проверка на null перед парсингом

Шаг 3: git push #

Синтаксис #

# Обычный push (для ветки, которая уже синхронизирована)
$ git push

# Push на конкретный удалённый сервер и ветку
$ git push origin main

# Первый push новой ветки (требуется -u флаг)
$ git push -u origin feature-branch

# Push конкретной ветки
$ git push origin feature-branch

# Push всех веток сразу (осторожно!)
$ git push --all

Первый push #

Когда вы создали новую локальную ветку и хотите отправить её первый раз:

# Создали новую ветку
$ git checkout -b feature/new-feature

# Добавили и закоммитили изменения
$ git add .
$ git commit -m "Новая фишка"

# ПЕРВЫЙ раз: нужно указать флаг -u (upstream)
$ git push -u origin feature/new-feature

# Создано как бы две вещи:
# 1. Локальная ветка feature/new-feature (была уже)
# 2. Удалённая ветка origin/feature/new-feature (создана)
# Флаг -u связывает их между собой

После первого push с флагом -u, последующие push’и можно делать просто git push.

Проверка статуса перед push #

# Показать статус (есть ли неотправленные коммиты)
$ git status

# Вывод может быть такой:
# Your branch is ahead of 'origin/main' by 3 commits.

Это означает, что у вас есть 3 локальных коммита, которые ещё не отправлены.

Полный пример рабочей сессии #

Давайте рассмотрим реальный день разработки:

Утро: получение новых изменений #

# Приходите на работу и хотите получить последние обновления
$ git pull
# Загружены новые коммиты от коллег

День: работа над фичей #

# Вам дали задачу: добавить функцию аутентификации
# Создаёте новую ветку
$ git checkout -b feature/authentication

# Редактируете файл
$ vim src/auth.py

# Проверяете, что изменилось
$ git status
# На экране:
# Changes not staged for commit:
#   modified:   src/auth.py

# Добавляете файл в staging area
$ git add src/auth.py

# Проверяете статус ещё раз
$ git status
# На экране:
# Changes to be committed:
#   modified:   src/auth.py

# Создаёте коммит
$ git commit -m "feat: добавлена базовая аутентификация"

# Дальше редактируете ещё файлы
$ vim src/utils.py
$ vim tests/test_auth.py

# Добавляете их
$ git add src/utils.py tests/test_auth.py

# Второй коммит
$ git commit -m "test: добавлены unit тесты для аутентификации"

# Проверяете историю своей работы
$ git log --oneline
# abc1234 test: добавлены unit тесты для аутентификации
# def5678 feat: добавлена базовая аутентификация
# ghi9012 main: исходное состояние

Вечер: отправка на сервер #

# Хотите отправить свою работу на GitHub
# Это ПЕРВЫЙ раз для этой ветки, поэтому нужен флаг -u
$ git push -u origin feature/authentication
# Ветка опубликована на GitHub

# Если потом вы добавляете ещё коммиты
$ git add .
$ git commit -m "refactor: улучшена обработка ошибок в auth"

# Второй push уже не требует -u
$ git push
# Отправляется новый коммит

Сокращённая версия с логическими операторами #

Если вы знаете ровно, что хотите сделать, можете скомбинировать команды:

# Отредактировали файлы, хотим их закоммитить и отправить
$ git add . && git commit -m "Исправлена ошибка" && git push

# && означает: выполнить следующую команду, только если предыдущая успешна

git add + commit + push одной командой #

Использование bash функции #

Если вы часто делаете одну и ту же последовательность, создайте bash функцию. Добавьте в ~/.bashrc или ~/.zshrc:

# Создайте функцию для быстрого commit и push
gacp() {
    git add .
    git commit -m "$1"
    git push
}

# Используйте:
# $ gacp "Исправлена ошибка в парсере"

Теперь вместо трёх команд можно написать:

$ gacp "Исправлена ошибка"

Использование git alias #

В файле ~/.gitconfig добавьте алиас:

[alias]
    acp = "!git add . && git commit -m"

Использование:

$ git acp "Исправлена ошибка"

Откат если что-то пошло не так #

Отменить git add (до commit) #

# Отменить добавление файла в staging area
$ git reset HEAD filename.py

# Отменить добавление всех файлов
$ git reset HEAD

Это вернёт файл из Staging Area в Working Directory. Изменения не потеряются, только они больше не будут в следующем коммите.

Отменить git commit (до push) #

# Отменить последний коммит, но сохранить изменения в файлах
$ git reset HEAD~1

# Теперь изменения в Working Directory, можете их переделать
$ git add .
$ git commit -m "Исправленное сообщение"

Отменить git push (очень осторожно!) #

Если вы уже отправили коммит на сервер, ситуация сложнее. Никогда не используйте git push --force на общих ветках! Вместо этого создайте новый коммит, который отменяет изменения:

# Создать коммит, который отменяет последний коммит
$ git revert HEAD

# Отправить отмену на сервер
$ git push

Это создаст новый коммит, который отменяет изменения, вместо удаления старого коммита.

Типичные ошибки новичков #

Ошибка 1: Забыли git add #

$ vim main.py
$ git commit -m "Исправлена ошибка"
# Коммит создан, но файл main.py НЕ был включён!

Решение: Всегда проверяйте git status перед коммитом.

Ошибка 2: Слишком много файлов в одном коммите #

$ git add .
$ git commit -m "Обновления"
# Включены изменения из 10 разных фич!

Решение: Используйте git add [файл] для добавления конкретных файлов. Один логический блок функциональности = один коммит.

Ошибка 3: Push в неправильную ветку #

$ git push origin main  # а должны были в feature!

Решение: Всегда проверяйте текущую ветку git branch перед push.

Ошибка 4: Забыли использовать -u для новой ветки #

$ git push origin my-new-branch
# fatal: The current branch my-new-branch has no upstream branch.

$ git push -u origin my-new-branch  # правильно

FAQ #

Вопрос 1: Зачем нужна staging area? Почему бы просто не коммитить всё?

Staging area позволяет вам выбирать, какие файлы идут в коммит. Представьте, что вы отредактировали 5 файлов, но 2 из них относятся к одной фиче, а 3 — к другой. Вы можете создать два отдельных коммита, каждый с логически связанными изменениями. Это делает историю чище и проще для review.

Вопрос 2: В чём разница между git commit -am и git add + git commit -m?

-am коммитит все отслеживаемые файлы (те, которые уже были в репозитории ранее) в один шаг. Но это не включает новые файлы! Если вы создали новый файл, его нужно сначала добавить с git add. Поэтому новичкам рекомендуется всегда явно использовать git add, чтобы не забыть новые файлы.

Вопрос 3: Может ли push быть отклонён?

Да, если:

  • Вы не авторизованы на сервере
  • Удалённая ветка защищена от push
  • У вас нет прав на запись в этот репозиторий
  • Удалённая ветка имеет коммиты, которые вы не получили (нужен git pull)

Вопрос 4: Как часто нужно делать push?

Рекомендуется делать push хотя бы один раз в день, чтобы не потерять работу в случае сбоя компьютера. Обычно: работаете → коммит → push перед обеденным перерывом → работаете → коммит → push перед уходом с работы.

Вопрос 5: Что значит “Your branch is ahead of ‘origin/main’ by 3 commits”?

Это значит, что у вас есть 3 коммита локально, которые ещё не отправлены на сервер. Используйте git push, чтобы отправить их.

Заключение #

Основной рабочий цикл Git состоит из трёх команд:

# 1. Выбрать файлы для сохранения
$ git add [файлы]

# 2. Сохранить локально с сообщением
$ git commit -m "Описание"

# 3. Отправить на сервер
$ git push

Почему три команды?

  • git add дает контроль над тем, что идёт в коммит
  • git commit сохраняет локально и создаёт точку восстановления
  • git push делает видимой вашу работу другим разработчикам

Начните с этих трёх команд, и вы справитесь с 90% повседневных задач в Git. Остальные 10% — это merge, rebase, и другие продвинутые операции, которые вы изучите позже.

Дополнительная информация доступна в статьях /ru/git/git-add/, /ru/git/git-commit/ и /ru/git/git-push/.