Зачем нужен Git

История, которую все жили

Представь: ты пишешь диплом. Открыл Word, написал главу, сохранил диплом.docx. На следующий день дописал ещё, испугался сломать, сделал копию диплом_v2.docx. Через неделю отправил научнику, он прислал правки в файле диплом_с_правками_Иванова.docx. Ты что-то принял, что-то отверг, сохранил как диплом_FINAL.docx. Через месяц перепутал две версии, накатил поверх старое, и две недели работы потерялись.

С кодом эта картинка выглядит так же, только архивы:

project_final.zip
project_final_v2.zip
project_final_v2_NEW.zip
project_final_v2_NEW_правки_Олега.zip
project_final_v2_NEW_правки_Олега_РАБОЧИЙ.zip

Что тут плохо:

• Не видно, что изменилось между версиями. Чтобы понять, надо открыть обе и глазами искать отличия.
• Двое не могут одновременно работать и аккуратно слить правки. Если Олег и ты редактировали один файл, кто-то перетрёт чьи-то изменения.
• История теряется, когда архивы переименовали или удалили. Через полгода ты не вспомнишь, что было в v2_NEW.
• Откатиться на «как было позавчера» — вручную, перекладывая файлы туда-сюда.

На все четыре проблемы есть один ответ: Version Control System (VCS) — программа, которая хранит все версии твоих файлов и умеет показывать, что и когда изменилось.

Что делает Git вместо архивов

Когда ты пишешь диплом в Word и нажимаешь Ctrl+S, сохранилась текущая версия, предыдущая исчезла. Git ведёт себя иначе: каждое нажатие «сохранить» — это коммит, и все коммиты остаются в истории навсегда.

Коммит — снимок всего проекта в момент времени плюс метаданные:

• кто сделал (author)
• когда (timestamp)
• сообщение для людей (message — например «добавил главу 2»)
• ссылка на родительский коммит

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

Дипломная аналогия: представь, что Word сам в фоне хранит ВСЕ твои сохранения с подписью «когда» и «что поменялось», и в любой момент ты можешь сказать «верни как было три недели назад», и оно вернёт.

Что меняется в работе вдвоём

Допустим, ты пишешь курсовую с напарником. Олег редактирует главу 1, а ты главу 3. Без Git это:

[понедельник] олег → курсовая_олег.docx
[понедельник] ты   → курсовая_ты.docx
[вторник]     ?    → как теперь слить два файла обратно?

С Git каждый работает в своей ветке — это лёгкий указатель, под который ты складываешь свои коммиты. Когда оба готовы, Git сам накладывает изменения друг на друга. Если правки в разных местах - склеит автоматически. Если оба правили одну строку, покажет конфликт и скажет «решите ребята кто прав».

Это работает, потому что у каждого в Git полная копия истории, не только текущий файл. Старые VCS (SVN, CVS) держали историю только на сервере: закоммитить без сети было нельзя. Git distributed: можно работать офлайн, в самолёте, в подвале без вайфая.

Сервер (его принято называть origin) — это просто ещё один такой же клон, к которому все договорились пушить. Не «главный», а «общий».

Базовые понятия одним блоком

Чтобы не путаться дальше, запомни четыре термина. Все ниже встречаются постоянно.

• Репозиторий — проект с историей. Локально это папка .git/ внутри проекта, где Git хранит всё своё.
• Коммит — снимок состояния + метаданные. Один коммит = одна точка в истории.
• Ветка — именованный указатель на конкретный коммит. Первая ветка создаётся вместе с репозиторием: у голого git init она называется master, а привычное main приходит с GitHub и GitLab. Под каждую задачу делают отдельную: дешевая, одноразовая.
• Remote — удалённый репозиторий. У большинства проектов один и зовут origin.

Зачем это DevOps-инженеру

Git — не инструмент только для программистов. В нём живёт почти всё, что мы рулим:

• Infrastructure-as-Code: Terraform-манифесты, Ansible-плейбуки, Helm-чарты.
• Конфиги в проде: nginx, prometheus, alertmanager, dashboards Grafana.
• CI/CD-пайплайны: .gitlab-ci.yml, .github/workflows/*.
• Документация и runbooks на случай инцидентов.

На каждое изменение есть ревью, история видна, откатиться можно через git revert. Отсюда и вырос GitOps — подход, где единственный источник правды лежит в репозитории, а инфра-агент в кластере сам подтягивает состояние.

Что важно запомнить

• Коммит — это снимок проекта целиком, а не «файл с правками». Думай не как Word-сохранение, а как фотография всего проекта.
• Ветка — это указатель, не копия. Создавать и кидать — не страшно.
• У каждого участника полная история локально, сервер origin - просто общий клон, на котором все встречаются.
• На проде в git лежит не только код приложения. Ещё инфра, конфиги, пайплайны, runbooks. Понимание git — база.

В следующем уроке поднимем репозиторий с нуля и сделаем первый коммит руками.