Git для начинающих: первый репозиторий, коммиты и ветки

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. В повседневной работе обычно достаточно его короткой уникальной части.

Читайте также:  Как настроить CI/CD для статического сайта: сборка и публикация

Ветки без лишней сложности

Ветка — подвижный указатель на коммит. Когда вы создаёте новый коммит, указатель текущей ветки перемещается вперёд. Отдельная ветка позволяет развивать функцию или исправление, не смешивая незавершённую работу с основной линией.

git switch -c feature/contact-form
# изменить файлы
git add src/form.js
git commit -m "Добавить проверку формы"
git switch main
git merge feature/contact-form

Название ветки должно быть коротким и понятным команде. Перед слиянием убедитесь, что рабочая папка чистая, тесты проходят, а основная ветка обновлена. Если изменения затронули разные строки, Git объединит их автоматически.

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

Что происходит при конфликте

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

  1. Выполните git status и откройте перечисленные файлы.
  2. Сравните варианты, оставьте правильный итог и удалите служебные маркеры.
  3. Проверьте код или документ.
  4. Добавьте исправленный файл через git add.
  5. Завершите слияние командой 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 дополнительно интегрирует изменения в текущую ветку, поэтому перед ним полезно проверить состояние и понимать принятую в проекте стратегию.

Читайте также:  Локальный сервер за 5 минут: сравнение Laragon, OpenServer и Docker для старта проекта

Как безопасно исправлять ошибки

Ситуация Действие Что важно помнить
Изменили файл, но ещё не добавили 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 быстро перестанет казаться набором опасных заклинаний.

Прокрутить вверх