exam

Понятие репозитория, коммита, ветки и слияния.

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

Репозиторий (repository)

Репозиторий — это хранилище файлов проекта вместе с полной историей их изменений. В нём Git хранит не просто файлы, а всю эволюцию проекта: кто, когда и какие правки вносил.

Виды репозиториев:

  • Локальный репозиторий — находится на компьютере разработчика. Здесь ведётся основная работа.
  • Удалённый репозиторий — размещён на сервере (GitHub, GitLab, Bitbucket). Служит общей точкой синхронизации для команды.

Пример: когда вы делаете git clone https://github.com/user/project.git, вы создаёте локальную копию удалённого репозитория со всей историей. Внутри папки проекта появляется скрытая директория .git — именно в ней Git хранит метаданные и историю.

Коммит (commit)

Коммит — это «снимок» состояния проекта в конкретный момент времени. Каждый коммит фиксирует изменения файлов и содержит:

  • Хеш (уникальный идентификатор) — например, a1b2c3d4e5f. По нему можно однозначно обратиться к этому коммиту.
  • Сообщение (commit message) — краткое описание того, что было сделано (например, «Add user login form»).
  • Метаданные — имя автора, дату и время создания, ссылку на родительский коммит (предыдущее состояние).

Как создают коммит:

git add .           # добавить изменения в индекс (подготовку к коммиту)
git commit -m "Описание изменений"  # создать коммит с сообщением

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

Ветка (branch)

Ветка — это независимая линия разработки. Представьте её как отдельную «версию» проекта, которая развивается параллельно с другими.

Ветки позволяют:

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

Типичный пример: в проекте есть ветка main (или master) — это основная, стабильная версия. Для новой функции создают ветку feature/login-page:

git checkout -b feature/login-page  # создать и переключиться на новую ветку

Теперь все коммиты, которые вы делаете, будут относиться только к этой ветке, а main останется неизменной.

Слияние (merge)

Слияние — это процесс объединения изменений из одной ветки в другую. Чаще всего изменения из рабочей ветки (например, feature/login-page) сливают в основную (main).

Как это делают:

  1. Переключаются на целевую ветку:git checkout main
  2. Обновляют её до актуального состояния (если работаете в команде):git pull origin main
  3. Выполняют слияние:git merge feature/login-page

После этого Git попытается автоматически объединить изменения. Если в одних и тех же файлах в разных ветках меняли одни и те же строки, возникнет конфликт слияния. Его нужно разрешить вручную: открыть файлы, выбрать нужные версии кода, убрать маркеры конфликта (<<<<<<<, =======, >>>>>>>), затем добавить исправленные файлы (git add) и завершить слияние коммитом.

Типы слияния:

  • Автоматическое слияние — Git сам объединяет изменения.
  • Слияние с созданием коммита слияния (merge commit) — Git создаёт специальный коммит, у которого два родителя (последний коммит в main и последний в feature-ветке). Он явно показывает момент объединения веток.
  • Fast-forward (ускоренное слияние) — если в целевой ветке не было новых коммитов, Git просто «передвинет» указатель ветки на последний коммит из сливаемой ветки, не создавая отдельный коммит слияния.

Как эти понятия работают вместе: простой пример рабочего процесса

  1. Есть репозиторий с веткой main, где лежит стабильный код.
  2. Разработчик хочет добавить новую функцию и создаёт ветку feature/cart:git checkout -b feature/cart
  3. Он пишет код, делает несколько коммитов, фиксируя промежуточные результаты.
  4. Когда функция готова, он переключается на main и сливает свою ветку:git checkout main git merge feature/cart
  5. Если всё прошло гладко, изменения попадают в main. Теперь эту версию можно выгрузить на сервер (git push) и развернуть на продакшене.

Если скажете, для какой цели вам нужны эти понятия (например, чтобы разобраться в Pull Request, настроить CI/CD или просто начать работать с Git), могу разобрать более узкий сценарий.