Команды Git для начинающих: от первого коммита до отправки на сервер

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

Главная ошибка новичка — запоминать команды без этой модели. Тогда add, commit и push кажутся тремя способами «сохранить». На деле каждая команда переносит изменения на следующий этап.

Четыре состояния одного изменения

Представьте, что вы исправили README.md:

1. Файл изменился в рабочем каталоге — обычной папке проекта.
2. git add помещает выбранную версию в индекс. Индекс — набор, подготовленный для следующего коммита.
3. git commit записывает индекс в локальную историю.
4. git push отправляет новые коммиты в удалённый репозиторий, например на GitHub или собственный Git-сервер.

Файл может снова измениться после git add. Тогда в индексе останется предыдущая подготовленная версия, а в рабочем каталоге появятся дополнительные правки. Поэтому перед коммитом нужны status и две разновидности diff.

Настройте автора коммитов один раз

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

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

Замените значения своими. Это не логин и не пароль от GitHub. Адрес становится частью истории репозитория, поэтому выберите публичный или скрытый адрес, соответствующий настройкам вашего сервиса.

Проверьте только эти параметры:

git config --global --get user.name
git config --global --get user.email

Если вывод неверен, повторите команды настройки с нужными значениями. Не публикуйте полный git config --list, не просмотрев его: в конфигурации могут находиться адреса и служебные параметры.

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

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

cd path/to/project
git init

Замените path/to/project настоящим путём. git init создаёт служебный каталог .git; рабочие файлы не меняются. Успех можно проверить командой git status.

Если репозиторий уже существует на сервере, обычно используют clone:

git clone https://github.com/OWNER/PROJECT.git
cd PROJECT

Замените OWNER и PROJECT. Клонирование создаёт новую папку, загружает историю и настраивает удалённый репозиторий под именем origin. Не выполняйте git init внутри уже клонированного проекта.

Смотрите состояние до любого изменения истории

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

git status --short --branch

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

Короткий формат удобен каждый день, но в сомнительной ситуации запустите обычный git status: Git объяснит состояние словами и предложит подходящие команды.

Просмотрите правки до git add

Команда ниже показывает изменения отслеживаемых файлов, которые ещё не подготовлены:

git diff

Строки с - удалены, с + добавлены. Это не означает, что Git уже что-то удалил: diff лишь сравнивает рабочий файл с подготовленной версией.

Новые неотслеживаемые файлы в обычном git diff не видны. Их имена показывает git status. Откройте такие файлы отдельно и убедитесь, что в них нет паролей, ключей, .env или собранных архивов.

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

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

git add src/app.js README.md

Команда не отправляет данные в интернет и не создаёт коммит. Она сохраняет в индексе текущую версию двух файлов. Такой явный список безопаснее бездумного git add ., особенно если в папке появились секреты или временные данные.

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

git diff --staged

Именно этот diff попадёт в следующий коммит. Если подготовили файл ошибочно, уберите его из индекса, не стирая правки:

git restore --staged README.md

После команды изменения README.md останутся на диске, но не войдут в ближайший коммит, пока вы снова не выполните git add.

Создайте один осмысленный коммит

Когда staged diff содержит одну законченную правку и прошли проверки проекта, создайте локальный коммит с коротким сообщением о результате изменения:

git commit -m "Add installation instructions"

Сообщение отвечает на вопрос, что меняет коммит. «Update» или «fix» без предмета мало помогают при поиске причины спустя месяц.

Проверьте результат:

git status
git log --oneline -5

Чистый рабочий каталог означает, что все текущие изменения зафиксированы. Если status всё ещё показывает файлы, это не ошибка: возможно, вы намеренно не включили их в коммит.

Используйте отдельную ветку для новой задачи

Ветка — подвижное имя, указывающее на последовательность коммитов. Создайте ветку и сразу перейдите в неё:

git switch -c feature/search

Название feature/search — пример. Команда не копирует весь проект: она создаёт новый указатель от текущего коммита. После работы проверьте статус, создайте коммиты и вернитесь в основную ветку только с чистым рабочим каталогом:

git switch main

Если Git отказывается переключаться, прочитайте список конфликтующих файлов. Сначала закоммитьте законченную работу, временно сохраните её осознанным способом или отмените только те изменения, которые точно не нужны. Не используйте reset --hard как универсальный выход: он может безвозвратно удалить незакоммиченные правки.

Узнайте, куда настроена отправка

Список удалённых репозиториев и их адресов запросите из корня проекта. Команда только читает настройку и помогает не отправить работу не на тот сервер:

git remote -v

Обычно origin указывает на сервер, откуда проект клонировали. Адрес не доказывает наличие доступа: при первой сетевой операции сервис может запросить авторизацию.

Перед отправкой получите изменения коллег. Для основной ветки безопасный предсказуемый вариант — разрешить только fast-forward:

git switch main
git pull --ff-only

Fast-forward возможен, когда локальная история не расходится с удалённой. Если Git сообщает о расхождении, не применяйте случайный merge или rebase. Посмотрите git status, git log --oneline --graph --all -10 и согласуйте способ объединения с правилами проекта.

Отправьте коммиты на сервер

Для новой ветки настройте связь с одноимённой удалённой веткой. Перед этим убедитесь через git status, что находитесь в нужной ветке и коммиты уже созданы:

git push -u origin feature/search

-u запоминает upstream — ветку, с которой последующие pull и push будут синхронизироваться по умолчанию. Команда отправляет коммиты, но не любые незакоммиченные файлы из рабочей папки.

После успешной отправки git status --branch покажет, что локальная ветка синхронизирована с удалённой. В командном проекте следующий шаг обычно — открыть pull request и пройти проверку, а не сразу менять основную ветку.

Как читать ежедневный цикл целиком

Последовательность не нужно копировать механически; она описывает контрольные точки:

git status --short --branch
git diff
git add src/app.js
git diff --staged
git commit -m "Handle empty search query"
git push

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

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

Источники

• Git: справочник основных команд
• Git: документация git status
• Git: документация git add
• Pro Git: основы Git