Git хранит историю проекта и позволяет понять, кто, когда и зачем изменил файлы. Для начала не нужно запоминать десятки команд или сразу разбираться в сложных стратегиях ветвления. Достаточно освоить короткий рабочий цикл: проверить состояние, подготовить нужные изменения, создать осмысленный коммит и синхронизировать его с удалённым репозиторием.
В этой инструкции мы создадим локальный репозиторий, разберём область подготовки файлов, сделаем отдельную ветку и безопасно объединим работу. Команды подходят для терминала Git Bash, PowerShell и большинства оболочек, если Git уже установлен.
Что Git сохраняет на самом деле
Репозиторий — это папка проекта вместе со скрытым каталогом .git. В нём находятся служебные данные: объекты, ссылки на ветки, настройки и история. Каждый коммит фиксирует согласованное состояние отслеживаемых файлов, сведения об авторе, время и сообщение. Новый коммит связан с предыдущим, поэтому история образует цепочку.
Git работает локально. Интернет не нужен, чтобы создать ветку, посмотреть различия или сделать коммит. GitHub, GitLab и другие платформы предоставляют удалённое хранилище и инструменты совместной работы, но не заменяют сам Git.
| Область | Что в ней находится | Полезная команда |
|---|---|---|
| Рабочая папка | Текущие версии файлов, включая незаписанные изменения | git status |
| Область подготовки | Изменения, которые войдут в следующий коммит | git add |
| Локальная история | Созданные коммиты и ветки на компьютере | git log |
| Удалённый репозиторий | Опубликованные ветки для обмена с командой | git fetch, git push |
Первичная настройка
После установки один раз укажите имя и электронную почту автора коммитов. Эти данные попадут в историю, поэтому для рабочего проекта используйте адрес, согласованный с командой. Это не логин и не пароль от сервиса.
git config --global user.name "Имя Фамилия"
git config --global user.email "name@example.com"
git config --global init.defaultBranch main
Проверить итог можно командой git config --global --list. Учетные данные удалённой платформы лучше не хранить в открытом файле проекта. Для них используют системное хранилище или менеджер учётных данных. На сайте уже есть отдельный материал о том, как хранить доступы к сервисам безопасно.

Создаём первый репозиторий и коммит
Откройте терминал в папке проекта и выполните git init. Git создаст служебный каталог, но не добавит файлы в историю автоматически.
cd path/to/project
git init
git status
git status — главная диагностическая команда для новичка. Она показывает текущую ветку, изменённые и неотслеживаемые файлы, а также содержимое области подготовки. Выполняйте её перед add, перед коммитом и после него.
Сначала настройте .gitignore
Не все файлы должны попадать в репозиторий. Обычно исключают зависимости, временные каталоги, логи, результаты сборки, настройки редактора и локальные файлы с секретами. Правила записывают в .gitignore. Набор зависит от языка и проекта: нельзя бездумно копировать большой шаблон, иначе можно скрыть важный исходник.
node_modules/
.env
dist/
*.log
Если файл уже отслеживается, добавление его имени в .gitignore не удалит его из истории. Сначала нужно прекратить отслеживание отдельной командой, а утёкший секрет считать скомпрометированным и заменить.
Подготовьте только нужные изменения
Команда git add . удобна, но может захватить лишние файлы. Безопаснее подготовить конкретный путь или использовать интерактивный режим. Затем просмотрите различия, которые действительно войдут в коммит.
git add README.md src/app.js
git diff --staged
git commit -m "Добавить начальную структуру проекта"
Хороший коммит решает одну понятную задачу. Сообщение объясняет результат, а не повторяет слово «изменения». Небольшие осмысленные коммиты проще проверять, переносить и отменять.
Как читать состояние и различия
git diffпоказывает изменения рабочей папки, ещё не добавленные в область подготовки.git diff --stagedпоказывает будущий коммит.git log --oneline --decorate --graph --allвыводит компактную схему истории и веток.git show <идентификатор>раскрывает конкретный коммит.
Идентификатор можно копировать из вывода git log. В повседневной работе обычно достаточно его короткой уникальной части.
Ветки без лишней сложности
Ветка — подвижный указатель на коммит. Когда вы создаёте новый коммит, указатель текущей ветки перемещается вперёд. Отдельная ветка позволяет развивать функцию или исправление, не смешивая незавершённую работу с основной линией.
git switch -c feature/contact-form
# изменить файлы
git add src/form.js
git commit -m "Добавить проверку формы"
git switch main
git merge feature/contact-form
Название ветки должно быть коротким и понятным команде. Перед слиянием убедитесь, что рабочая папка чистая, тесты проходят, а основная ветка обновлена. Если изменения затронули разные строки, Git объединит их автоматически.

Что происходит при конфликте
Конфликт возникает, когда Git не может однозначно совместить изменения. В файле появляются маркеры с двумя вариантами. Это не поломка репозитория, а запрос решения от человека.
- Выполните
git statusи откройте перечисленные файлы. - Сравните варианты, оставьте правильный итог и удалите служебные маркеры.
- Проверьте код или документ.
- Добавьте исправленный файл через
git add. - Завершите слияние командой
git commit, если Git просит коммит.
Если вы поняли, что слияние начато преждевременно, git merge --abort обычно возвращает состояние до операции. Не применяйте команды принудительного сброса, пока не понимаете, какие локальные изменения они удалят.
Подключаем удалённый репозиторий
После создания пустого проекта на выбранной платформе скопируйте его адрес и добавьте как origin. Современные сервисы чаще используют HTTPS с менеджером учётных данных или SSH-ключи.
git remote add origin https://example.com/team/project.git
git remote -v
git push -u origin main
Ключ -u связывает локальную ветку с удалённой. После этого для следующих отправок достаточно git push. Команда git fetch получает сведения о новых удалённых коммитах, не меняя рабочие файлы. git pull дополнительно интегрирует изменения в текущую ветку, поэтому перед ним полезно проверить состояние и понимать принятую в проекте стратегию.
Как безопасно исправлять ошибки
| Ситуация | Действие | Что важно помнить |
|---|---|---|
| Изменили файл, но ещё не добавили | git restore file |
Незакоммиченные правки файла будут потеряны |
| Лишнее попало в staging | git restore --staged file |
Файл останется изменённым в рабочей папке |
| Нужна правка последнего локального коммита | git commit --amend |
Коммит получит новый идентификатор |
| Нужно отменить опубликованный коммит | git revert <id> |
Создаётся новый обратный коммит, история сохраняется |
Команды reset --hard и принудительная отправка меняют историю или удаляют локальные данные. Для общего репозитория их применяют только по согласованному сценарию. Новичку чаще достаточно restore, revert и новой корректирующей записи.
Рабочий минимум на каждый день
git status
git switch -c feature/short-name
# работа с файлами
git diff
git add path/to/file
git diff --staged
git commit -m "Кратко описать результат"
git push -u origin feature/short-name
Редактор кода может показывать изменения, ветки и конфликты графически. Это удобно, но полезно понимать команды под интерфейсом. Если выбираете инструмент, пригодится обзор о том, как выбрать первый редактор. Начинайте с небольшого учебного проекта и регулярно смотрите status: так Git быстро перестанет казаться набором опасных заклинаний.