Git простыми словами: контроль версий для вайбкодинга

Зачем нужен Git: сохранение прогресса и откаты

Ты вайбкодишь: пробуешь идеи, просишь ИИ «сделай красиво», меняешь куски кода, иногда ломается всё, а иногда получается внезапный шедевр. В этот момент Git — это не про “сложные команды для программистов”, а про спокойствие.

Git нужен для двух главных вещей:

Сохранять прогресс так, чтобы было понятно что, когда и зачем поменялось

Откатываться назад (частично или полностью), когда «что-то пошло не так»

Проблема без Git

Когда Git нет, обычно происходит одно из этих:

Ты меняешь файл, сохраняешь, и старое состояние исчезло

Ты не помнишь, что именно сломало проект: «вроде работало час назад»

Ты делаешь копии папок: project_final, project_final2, project_final_REAL — и всё равно путаешься

Ты боишься экспериментировать, потому что можно всё сломать

> Практическое правило: если ты боишься трогать код, значит тебе не хватает хорошего способа вернуться назад.

Что такое Git (очень простыми словами)

Git — это инструмент, который хранит историю изменений твоего проекта.

Проект под Git обычно называют репозиторием. Репозиторий — это просто папка с твоими файлами, у которой есть память (история версий).

Эта память состоит из коммитов.

Коммит — это “сейв”

Коммит — это сохранённая точка в истории проекта.

В коммите Git запоминает:

какие файлы изменились

что именно изменилось

когда это было

комментарий (сообщение), который ты пишешь сам: зачем ты это сделал

Если говорить по-вэйбкодерски, Git превращает разработку в игру с сейвами:

сделал маленький шаг — сохранился

попробовал странную идею — сохранился

сломал всё — откатился

Сохранение прогресса: как Git помогает “не потерять хорошее”

Коммиты полезны не только когда что-то ломается. Они помогают понимать себя вчерашнего.

Например:

Ты добавил авторизацию

Потом попросил ИИ “рефакторни красиво”

Потом поменял структуру папок

Без Git это превращается в кашу: где что поменялось и почему.

С Git ты можешь открыть историю и увидеть: “Ага, вот здесь был коммит ‘Add login form’, а вот здесь ‘Refactor auth flow’”.

Что именно даёт коммит (в быту)

| Ситуация | Что даёт Git | |---|---| | Хочешь попробовать новую идею | Можно сделать коммит и экспериментировать дальше без страха | | “Всё сломалось” | Можно вернуться в рабочее состояние | | Забыл, что менял | Можно посмотреть историю изменений | | Нужно показать, что именно изменилось | Git покажет разницу между версиями |

Откаты: вернуться назад, когда стало хуже

Самая магия Git — откаты.

Важно: Git помогает откатываться не через “переписать руками как было”, а через историю сохранённых состояний.

Какие бывают откаты (по смыслу)

Откатить один файл к прошлой версии

Откатить несколько файлов

Откатить весь проект к состоянию на конкретный коммит

Отменить изменения так, чтобы это тоже осталось в истории (аккуратная отмена)

Если объяснять совсем простыми словами:

Git позволяет вернуться в точку, где всё работало

Git позволяет понять, что именно между “работало” и “сломалось” изменилось

!Визуально показывает коммиты как точки сохранения и возможность отката и эксперимента в стороне

Эксперименты без риска: “параллельная реальность”

Когда ты хочешь попробовать новую идею (например, заменить библиотеку, переделать UI или “пусть ИИ перепишет весь модуль”), часто страшно.

Для этого в Git есть ветки.

Ветка — это отдельная линия изменений, которая не ломает основную.

Представь так:

основная линия — “у меня работает”

отдельная линия — “я пробую”

Если эксперимент классный — его можно аккуратно забрать в основную линию. Если ужас — просто забыть про него.

В этой статье важно запомнить только идею:

коммиты — это сейвы

ветки — это возможность вайбкодить смело, не ломая главное

Минимальный набор команд (только чтобы почувствовать идею)

Команды сейчас не цель, а просто “посмотреть, как это выглядит”.

Если команды пока выглядят страшно — нормально. Смысл статьи в другом: Git даёт тебе управляемую историю и возможность отката.

Частые ошибки новичков

Пытаться “всё понять сразу” вместо того, чтобы привыкнуть к идее сейвов

Делать один гигантский коммит “всё за день” вместо нескольких маленьких

Писать сообщения коммитов вроде “fix” или “update” — потом невозможно понять, что там

Надеяться на “отмену” в редакторе вместо нормальной истории проекта

Что дальше в курсе

Дальше мы сделаем первые шаги руками: создадим репозиторий, научимся делать коммиты как привычку и потренируем безопасные откаты на простом примере.

Если захочешь почитать официальный справочник позже, он здесь: Pro Git (русская версия)

Базовые команды: init, status, add, commit, log

В прошлой статье мы договорились о главном: Git — это “сейвы” (коммиты) и возможность отката. Теперь — как руками делать эти сейвы и смотреть историю.

Мы разберём 5 команд, которых хватит, чтобы начать вайбкодить без страха сломать проект:

git init

git status

git add

git commit

git log

Модель в голове: три “места”, где живут изменения

Чтобы команды не казались магией, держи простую картинку:

Рабочая папка (working directory) — твои реальные файлы на диске.

Индекс / сцена (staging area) — “корзина на коммит”: сюда ты складываешь то, что точно хочешь сохранить.

История Git (repository) — уже сохранённые сейвы (коммиты).

!Три зоны Git и какие команды перемещают изменения между ними

Главная идея: git add выбирает, что попадёт в сейв, а git commit делает сейв.

git init: включить Git в папке

git init превращает обычную папку в репозиторий Git.

Создай или открой папку проекта.

Выполни команду:

После этого Git начнёт отслеживать историю в этой папке.

Что важно:

git init обычно делается один раз на проект.

Git создаёт служебную папку .git — это “память” репозитория. Её обычно не трогают руками.

git status: что сейчас происходит

Команда git status отвечает на вопрос: “Что изменилось и готово ли это к коммиту?”

Обычно ты увидишь один из типов сообщений:

“nothing to commit” — нечего сохранять, всё чисто.

“untracked files” — есть новые файлы, Git их ещё не отслеживает.

“changes not staged for commit” — файлы изменены, но ещё не добавлены в staging.

“changes to be committed” — изменения уже в staging и готовы к коммиту.

Практика для вайбкодинга: после любой “пачки правок” делай git status, чтобы понимать, что ты вообще собираешься сохранять.

git add: выбрать изменения для сейва

git add кладёт изменения в staging area (в “корзину на коммит”). Это не коммит, а выбор.

Самый частый вариант: добавить всё

Точка . означает “всё в текущей папке и подпапках”. Это удобно на старте.

Добавить конкретный файл

Это полезно, когда ты менял много всего, но хочешь сохранить только часть.

Что запомнить:

git add можно делать много раз перед коммитом.

Если после git add ты снова изменил файл, то нужно снова сделать git add для этих новых изменений.

git commit: сделать сейв с сообщением

git commit создаёт коммит — точку в истории.

Коммит состоит из:

набора изменений, которые лежали в staging

даты и автора

сообщения, которое ты написал

Как писать сообщения коммитов (чтобы потом было не больно)

Хорошие сообщения:

“Добавил кнопку Logout”

“Починил редирект после логина”

“Упростил валидацию формы”

Плохие сообщения:

“fix”

“update”

“лол”

Правило: сообщение отвечает на вопрос “что я изменил и зачем?”

git log: посмотреть историю сейвов

git log показывает список коммитов.

Удобный компактный формат:

Ты увидишь строки вида:

короткий идентификатор коммита (хэш)

сообщение коммита

Это нужно для двух вещей:

быстро найти “точку, где всё работало”

понимать, как проект пришёл к текущему состоянию

Мини-сценарий: “вайбкодинг без страха”

Представь, ты хочешь попробовать идею от ИИ и не потерять рабочее состояние.

Проверяешь текущую ситуацию:

Добавляешь изменения, которые хочешь зафиксировать:

Делаешь сейв:

В любой момент смотришь историю:

Шпаргалка: что делает каждая команда

| Команда | Зачем нужна | Когда использовать | |---|---|---| | git init | Включить Git в папке проекта | Один раз в начале | | git status | Понять, что изменилось и что готово к коммиту | Постоянно | | git add | Выбрать изменения для следующего коммита | Перед git commit | | git commit -m "..." | Сделать сейв (коммит) из выбранных изменений | После логичного шага | | git log --oneline | Посмотреть историю сейвов | Когда нужно найти/вспомнить |

Частые ошибки новичков (и как не страдать)

Забыть git add и пытаться коммитить “всё”: Git сохранит только то, что в staging.

Делать один коммит на весь день: лучше маленькие, понятные сейвы.

Не смотреть git status: это как ехать без приборной панели.

Писать непонятные сообщения: через неделю ты не вспомнишь, что было в “update”.

Куда смотреть справку, если команда не работает

Официальная документация Git (git-scm.com/docs)

Справка по git commit

Справка по git log

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

Ветки без боли: branch, checkout/switch, merge

В прошлых статьях мы разобрали базу: Git — это сейвы (коммиты), а команды init, status, add, commit, log помогают эти сейвы делать и смотреть историю.

Теперь добавляем то, что делает вайбкодинг спокойным: ветки.

Если коммит — это сохранение, то ветка — это параллельная реальность, где можно пробовать идеи, не ломая «рабочую» версию.

Что такое ветка (очень просто)

Ветка — это именованная линия коммитов.

У тебя есть основная линия проекта (часто называется main или master).

Ты создаёшь новую ветку, чтобы сделать эксперимент.

Если эксперимент получился — ты сливаешь (merge) изменения обратно.

Если эксперимент не понравился — ветку можно просто не сливать.

Представь, что Git — это игра с сейвами:

коммиты — это сохранения

ветка — это отдельная дорожка сохранений

!Диаграмма показывает, как ветка ответвляется от main и потом сливается обратно

Два термина, без которых дальше больно

HEAD — указатель на то, где ты сейчас находишься (на какой ветке и на каком коммите).

Текущая ветка — ветка, в которой окажутся твои новые коммиты.

Практическое правило:

если ты коммитишь, коммит попадает в текущую ветку

git branch: посмотреть и создать ветку

Посмотреть ветки

Git покажет список веток, а текущую отметит *.

Создать новую ветку

Важно:

эта команда создаёт ветку, но не переключает тебя на неё

git switch и git checkout: переключение без мистики

Чтобы реально работать в ветке, нужно на неё переключиться.

Рекомендуемый вариант: git switch

Переключиться на существующую ветку:

Создать ветку и сразу переключиться:

Старый универсальный вариант: git checkout

git checkout умеет много всего и поэтому часто путает новичков. Но ты встретишь его в гайдах.

Переключиться:

Создать и переключиться:

Запомни так:

хочешь просто ветки — используй git switch

git checkout знать полезно, но на старте он не обязателен

Мини-сценарий “вайбкодинг без страха”

Допустим, у тебя есть рабочая версия, и ты хочешь попросить ИИ «перепиши всё красиво» (страшно).

Делаем безопасно:

Сохраняем текущую рабочую точку в main.

Создаём ветку для эксперимента и уходим в неё.

Вайбкодим как угодно, делаем коммиты.

Если всё сломалось — основная ветка main не пострадала.

git merge: как “принести” изменения из ветки в основную

Merge — это “влить изменения одной ветки в другую”.

Главное правило:

ты выполняешь merge в той ветке, куда хочешь получить изменения

То есть: чтобы влить refactor-idea в main, сначала переключись на main.

После этого изменения из refactor-idea окажутся в main.

Что именно происходит при merge (в двух словах)

Есть два частых исхода.

Fast-forward merge (самый простой)

Если main не менялся, пока ты работал в ветке, Git просто “передвинет указатель” main вперёд.

выглядит как будто ты всегда работал в main

история линейная и простая

Merge commit (когда ветки реально расходились)

Если main тоже менялся параллельно, Git создаст отдельный коммит слияния.

это нормальная ситуация

Git фиксирует, что две линии истории были объединены

Конфликты при merge: что это и что делать

Конфликт — это когда Git не может сам решить, как объединить изменения.

Типичный пример:

в ветке main ты поменял строку в app.js

в ветке refactor-idea ты поменял ту же строку иначе

Git не угадывает, какой вариант правильный

Как выглядит процесс (без паники):

Ты запускаешь merge и видишь сообщение о конфликте.

Открываешь файлы, где конфликт, и видишь специальные метки.

Выбираешь правильный итоговый вариант (или собираешь из двух).

Добавляешь исправленные файлы в staging и завершаешь merge.

Команды обычно такие:

Полезное правило для новичка:

если видишь конфликт — это не “Git сломался”, это “Git попросил тебя принять решение”

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

Делать эксперимент прямо в main, а потом бояться откатываться.

Забывать, в какой ветке ты находишься (лечится командой git status или git branch).

Пытаться сделать git merge, не переключившись в ветку-получатель.

Долго не коммитить в экспериментальной ветке: лучше мелкими шагами.

Мини-шпаргалка

| Задача | Команда | |---|---| | Посмотреть ветки | git branch | | Создать ветку | git branch name | | Переключиться | git switch name | | Создать и переключиться | git switch -c name | | Влить ветку в текущую | git merge other-branch |

Полезные ссылки

Pro Git (книга), главы про ветки

Документация git branch

Документация git switch

Документация git merge

Документация git checkout

GitHub и удалённые репозитории: clone, remote, push, pull

До этого мы работали с Git локально: делали коммиты (сейвы), смотрели историю и экспериментировали с ветками. Теперь добавляем следующую «суперсилу»: удалённый репозиторий.

Если очень просто:

Git хранит историю изменений.

GitHub (и аналоги) дают место в интернете, где лежит твой репозиторий, чтобы:

- не потерять проект, - работать с разных компьютеров, - делиться кодом, - работать в команде.

Что такое удалённый репозиторий

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

Твой компьютер: коммиты, ветки, файлы.

GitHub: те же коммиты и ветки, но «в облаке».

!Как локальный репозиторий связан с GitHub и что делают clone/push/pull

Термины, без которых дальше будет путаница

Remote — «удалёнка», ссылка на репозиторий на сервере.

origin — стандартное имя для главного remote (Git сам так называет при clone).

main — часто основная ветка (может называться иначе).

Push — отправить свои коммиты на GitHub.

Pull — забрать чужие (или свои с другого компа) коммиты к себе.

git clone: забрать проект себе целиком

git clone нужен, когда репозиторий уже существует на GitHub, а ты хочешь получить локальную копию.

Что произойдёт:

создастся папка REPO

внутри будет код

внутри будет Git-история

автоматически добавится remote с именем origin

После этого можно работать как обычно: редактировать файлы, git add, git commit.

Полезная документация: GitHub Docs: клонирование репозитория

git remote: посмотреть и настроить удалёнку

Посмотреть список remote

Чаще всего увидишь:

origin

Посмотреть адреса remote

Покажет, куда Git будет пушить и откуда будет тянуть.

Добавить remote вручную (если ты начал проект локально)

Ситуация: ты сделал git init, коммитил локально, а теперь хочешь привязать GitHub.

Создай пустой репозиторий на GitHub.

Добавь remote:

Проверь:

Документация: Git: работа с удалёнными репозиториями

git push: отправить свои коммиты на GitHub

Push — это «загрузить мои новые коммиты на удалёнку».

Типичный сценарий вайбкодинга:

Ты навайбкодил.

Сделал сейв:

Отправил на GitHub:

Первый push иногда нужно сделать явно

Если ветка ещё не связана с удалённой веткой, Git может попросить команду вида:

Что означает эта команда:

origin — имя remote

main — имя ветки

-u — «запомнить связь», чтобы дальше можно было просто git push

Документация: GitHub Docs: push

git pull: забрать обновления с GitHub

Pull — это «обновить мой локальный проект изменениями с удалёнки».

Когда это нужно:

ты работаешь на двух компьютерах

ты работаешь с другом/командой

ты создал коммит на GitHub (например, через веб-интерфейс) и хочешь получить его локально

Важная мысль: git pull приносит изменения и пытается объединить их с твоими.

Документация: GitHub Docs: pull

Самый безопасный рабочий ритуал: pull перед тем как push

Если удалёнка могла измениться не только тобой прямо сейчас, привычка такая:

Перед началом работы:

В процессе делай коммиты маленькими порциями.

В конце отправляй:

Это снижает шанс конфликтов и ситуаций «почему Git ругается».

Что будет, если push не проходит

Самая частая причина: на GitHub уже есть коммиты, которых нет у тебя локально.

Обычно Git говорит что-то вроде «нужно сначала подтянуть изменения».

Тогда делай:

Если во время pull случился конфликт, это ровно те же конфликты, что и при merge веток:

git status покажет конфликтные файлы.

Открываешь файлы и выбираешь итоговый вариант.

Затем:

И после этого:

Мини-сценарии: как это выглядит в жизни

Сценарий A: ты скачал проект с GitHub и продолжил

Сценарий B: ты начал локально, а потом подключил GitHub

Сценарий C: ты сделал ветку для эксперимента и хочешь закинуть её на GitHub

Создаёшь ветку и коммитишь:

Отправляешь ветку на GitHub:

После этого ветка появится на GitHub, и её можно будет обсуждать, показывать друзьям или потом сливать в main.

Шпаргалка команд

| Задача | Команда | |---|---| | Скачать репозиторий с GitHub | git clone URL | | Посмотреть remote | git remote -v | | Добавить remote | git remote add origin URL | | Отправить коммиты на GitHub | git push | | Забрать обновления с GitHub | git pull |

Главное, что стоит запомнить

Коммиты живут локально, пока ты не сделал git push.

origin — это просто имя ссылки на GitHub.

git pull помогает не отстать от удалёнки, а git push — поделиться своими изменениями.

Ветки можно пушить так же, как и main.

Типичные ошибки и спасение: конфликт, reset, revert, stash

Ты уже умеешь делать коммиты, работать с ветками и пушить на GitHub. Теперь нужна «аптечка», которая спасает, когда:

Git ругается на конфликт

ты закоммитил не то

ты сделал правки, но ещё не готов коммитить

ты хочешь «отменить», но не сломать историю

В этой статье разберём 4 инструмента спасения:

конфликты (и как их решать)

git reset (переписать локальную историю)

git revert (отменить коммит безопасно)

git stash (убрать незакоммиченные правки в карман)

!Быстрый визуальный ориентир, чем отличаются конфликт, reset, revert и stash

Конфликт: Git не понимает, как склеить изменения

Что такое конфликт простыми словами

Конфликт появляется, когда Git пытается объединить изменения (обычно при git merge или git pull), но видит, что:

один и тот же кусок файла был изменён по-разному

и Git не может решить, какой вариант правильный

Важно: конфликт означает не «всё сломалось», а «нужно твоё решение».

Самый частый сценарий

ты правил файл в ветке feature

кто-то (или ты на другом компе) правил тот же файл в main

ты делаешь git merge feature в main или git pull

Git останавливается и просит руками выбрать итог

Как решать конфликт пошагово

Посмотри, что именно в конфликте

Открой конфликтный файл и найди метки

Прими решение

оставь верхний вариант

оставь нижний вариант

собери итог из двух

удали служебные строки <<<<<<<, =======, >>>>>>>

Отметь, что конфликт решён, и заверши

Если конфликт случился во время git pull, это всё равно обычное слияние, просто запущенное «внутри» pull.

Полезные команды при конфликте

git status показывает список конфликтных файлов

git diff помогает увидеть, что именно отличается

Документация: Git: Основы слияния

git reset: «передвинуться назад» и переписать локальную историю

Главная идея

git reset двигает указатель ветки назад на другой коммит. Часто это используют, чтобы:

отменить последний коммит локально

«разобрать» коммит обратно на изменения

Это мощно, но опаснее, чем revert, потому что reset переписывает историю.

Самое важное правило безопасности

если ты уже сделал git push, будь осторожен с git reset

переписывание истории на ветке, которой пользуются другие, может создать хаос

Три режима reset (как думать без перегруза)

--soft

коммит «исчезает» из истории

изменения остаются подготовленными к коммиту (в staging)

--mixed (это режим по умолчанию)

коммит «исчезает» из истории

изменения остаются в файлах, но не в staging

--hard

коммит «исчезает» из истории

изменения в файлах тоже выбрасываются

Практическое предупреждение: --hard реально удаляет незакоммиченные изменения. Используй только когда точно уверен.

Документация: git reset

Типичный вайбкодинг-сценарий для reset

Ты сделал коммит, но понял, что сообщение плохое или попали лишние файлы.

хочешь переделать коммит, но сохранить изменения

git revert: «отменить коммит», не ломая историю

Главная идея

git revert не стирает прошлое. Он создаёт новый коммит, который делает обратные изменения.

Это лучший вариант, когда:

коммит уже в удалённом репозитории

история должна оставаться честной

в проекте работают другие

Пример:

Где <hash> можно взять из:

Когда выбрать revert вместо reset

если коммит уже был отправлен на GitHub (git push)

если ты не хочешь переписывать историю ветки

Документация: git revert

git stash: спрятать незакоммиченные изменения

Зачем нужен stash

git stash полезен, когда:

ты навайбкодил правки

но внезапно нужно переключиться на другую ветку

и ты не хочешь делать «грязный коммит» ради переключения

stash кладёт изменения в «карман», очищает рабочую папку, а потом ты можешь вернуть всё обратно.

Базовый набор команд

Спрятать изменения:

Вернуть спрятанное и удалить из stash:

Вернуть спрятанное, но оставить копию в stash:

Посмотреть список stash-наборов:

Хорошая привычка: добавляй сообщение к stash

Документация: git stash

Быстрый выбор: что делать в какой ситуации

| Ситуация | Лучший инструмент | Почему | |---|---|---| | git pull или git merge остановился и просит решить | конфликт + ручное исправление | Git не может выбрать вариант за тебя | | Ты закоммитил лишнее, но ещё не пушил | git reset (--soft или --mixed) | Можно переписать локальную историю | | Ты уже запушил плохой коммит и хочешь аккуратно отменить | git revert | История не переписывается, безопасно для команды | | Нужно срочно переключиться на ветку, но правки не готовы | git stash | Временно убирает незакоммиченные изменения |

Типичные ошибки новичков и как не страдать

Паниковать при конфликте и пытаться «отменить всё»

- сначала git status, потом спокойно правь конфликтные файлы, потом git add и git commit

Делать git reset --hard, когда ты не уверен

- если сомневаешься, лучше начни с git reset --mixed или вообще с git revert

Переписывать историю после git push, а потом пытаться «починить пушем»

- если коммит уже на GitHub, чаще всего выбирай git revert

Делать stash и забывать про него

- используй git stash list и сообщения -m, чтобы понимать, что ты спрятал

Мини-ритуал «антипаника»

Когда что-то пошло не так, почти всегда помогает этот порядок:

git status понять, где ты и что изменено

git log --oneline найти последнюю «точку, где было нормально»

Выбрать действие

конфликт: правим и завершаем

нужно отменить локально: reset

нужно отменить безопасно: revert

нужно временно убрать: stash

Полезные ссылки

Документация git reset

Документация git revert

Документация git stash

Pro Git (книга): основы ветвления и слияния