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

Введение

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

Установка и начальная настройка

Перед началом работы нужно установить Git и представиться системе — указать имя и email. Эти данные будут привязаны к каждому вашему коммиту.

# Проверить, установлен ли Git
git --version

# Указать имя и email (один раз для всей системы)
git config --global user.name "Иван Иванов"
git config --global user.email "ivan@example.com"

# Посмотреть текущие настройки
git config --list

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

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

# Инициализировать новый репозиторий в текущей папке
git init

# Клонировать существующий репозиторий с GitHub
git clone https://github.com/user/project.git

# Клонировать в папку с другим именем
git clone https://github.com/user/project.git my-project

После git init в папке появится скрытая директория .git — в ней Git хранит всю историю.

Основной рабочий цикл: add, commit, status

Большую часть времени вы будете работать с тремя командами: смотреть статус, добавлять файлы в индекс и сохранять изменения в коммит.

# Посмотреть, какие файлы изменились
git status

# Добавить конкретный файл в индекс (staging area)
git add index.js

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

# Сохранить изменения из индекса в коммит
git commit -m "Добавить функцию авторизации"

# Добавить в индекс и сразу создать коммит (только для отслеживаемых файлов)
git commit -am "Исправить опечатку в комментарии"

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

Просмотр истории

# Показать историю коммитов
git log

# Компактный вид: один коммит — одна строка
git log --oneline

# История с графом веток
git log --oneline --graph --all

# Показать изменения в конкретном коммите
git show a3f5c2d

# Посмотреть, что изменилось с момента последнего коммита
git diff

# Посмотреть изменения, уже добавленные в индекс
git diff --staged

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

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

# Список всех веток (текущая отмечена звёздочкой)
git branch

# Создать новую ветку
git branch feature/login

# Переключиться на ветку
git checkout feature/login

# Создать ветку и сразу переключиться (современный способ)
git switch -c feature/login

# Слить ветку feature/login в текущую ветку
git merge feature/login

# Удалить ветку после успешного слияния
git branch -d feature/login

Принято держать ветку main (или master) стабильной и создавать отдельные ветки для каждой задачи или функции.

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

Удалённый репозиторий (remote) — это копия проекта на сервере, например на GitHub или GitLab. Он нужен для совместной работы и резервного хранения кода.

# Посмотреть список удалённых репозиториев
git remote -v

# Добавить удалённый репозиторий с именем origin
git remote add origin https://github.com/user/project.git

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

# Забрать изменения с сервера и слить с текущей веткой
git pull origin main

# Забрать изменения без слияния (только загрузить)
git fetch origin

При первом push рекомендуется использовать флаг -u, чтобы связать локальную ветку с удалённой:

# Связать ветку и отправить изменения
git push -u origin main

# После этого достаточно просто
git push

Отмена изменений

Одна из главных ценностей Git — возможность откатить ошибки.

# Отменить изменения в файле (до добавления в индекс)
git checkout -- index.js

# Современный способ отмены изменений в рабочей директории
git restore index.js

# Убрать файл из индекса, не трогая сами изменения
git restore --staged index.js

# Создать новый коммит, отменяющий указанный (безопасный способ)
git revert a3f5c2d

# Сбросить ветку к конкретному коммиту (опасно: история перепишется)
git reset --hard a3f5c2d

Отдавайте предпочтение git revert при работе в команде — он не переписывает историю, а создаёт новый коммит.

Частые ошибки

Коммит без сообщения или с бессмысленным сообщением. Сообщение «fix» или «asdf» не даёт понять, что было изменено. Пишите кратко и конкретно: «Добавить валидацию формы регистрации».

Работа напрямую в ветке main. Даже в личных проектах полезно создавать отдельные ветки для задач — это формирует правильную привычку и упрощает код-ревью.

Игнорирование файла .gitignore. Файлы node_modules, .env с секретами, артефакты сборки не должны попадать в репозиторий. Создайте .gitignore с самого начала.

# Пример содержимого .gitignore
node_modules/
.env
dist/
.DS_Store

Использование git reset --hard в общей ветке. Такая команда переписывает историю, что сломает работу коллег, уже скачавших эту ветку.

Огромные коммиты. Один коммит должен отражать одно логическое изменение. Не накапливайте изменения за несколько дней в один огромный коммит.

Заключение

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