Git + GitHub — как это работает
Эта страница — простое объяснение Git и GitHub для не-программиста. Без заумных терминов, с аналогиями из реальной жизни.
Зачем тебе это знать
Ты не будешь сам писать git push — для этого есть агенты и автоматизация. Но понимать, что происходит, важно. Вот три причины:
Ничего не пропадёт. Git хранит ВСЮ историю изменений. Случайно удалил картинки? Опубликовал неудачную статью? Одна команда вернёт всё на место.
Несколько устройств — один проект. Работаешь с мака, вечером продолжаешь с сервера — git синхронизирует. Ничего не теряется между переключениями.
Ты понимаешь, что происходит. Когда агент говорит «запушил коммит a016f46» или «нужен pull» — ты не растерян. Знаешь что ответить и что проверить.
Аналогия: Google Docs для кода
Представь Google Docs, где:
— Каждое сохранение — это коммит (снимок всех файлов в этот момент)
— История версий — это git log (можно откатиться на любой момент)
— Google Drive — это GitHub (облачное хранилище + синхронизация)
— Твой компьютер — это локальный репозиторий (копия проекта на диске)
5 ключевых понятий
1. Репозиторий (repo)
Папка с проектом + вся его история изменений. Живёт в двух местах одновременно:
— На GitHub (облако) — github.com/ИМЯ_ПОЛЬЗОВАТЕЛЯ/НАЗВАНИЕ_РЕПО
— На VPS/маке (локальная копия) — клон, в котором агенты работают
Попробуй сам: открой терминал, зайди в папку проекта (cd ~/projects/мой-проект), напиши ls — увидишь файлы. Это и есть содержимое твоего локального репозитория.
2. Коммит (commit)
Снимок состояния всех файлов. Как «сохранить игру». У каждого коммита есть:
— Уникальный ID (хеш) — например a016f46
— Сообщение — что изменилось: "article: claude-code-skills-guide"
— Автор + дата — кто и когда сделал изменение
Когда ты видишь в терминале «коммит a016f46» — это значит: изменения сохранены под этим ID, их можно посмотреть, проверить или откатить.
Попробуй сам: после git log --oneline нажми стрелку вниз чтобы листать историю. Нажми Q для выхода. Попробуй git show <хеш> — увидишь что конкретно менялось в том коммите.
3. Push и Pull
— Push = отправить изменения из локальной копии → на GitHub (бэкап в облако)
— Pull = скачать изменения из GitHub → к себе (синхронизация)
Команда git push отправляет изменения с твоего компьютера на GitHub. Это бэкап в облако + синхронизация между устройствами, если ты работаешь и с мака, и с сервера.
Попробуй сам: после git push зайди на github.com/твой-репо и обнови страницу. Увидишь что счётчик коммитов вырос на 1, и твой коммит в списке "Commits" сверху.
4. Ветка (branch)
Параллельная версия проекта. Основная ветка — main. Можно создать ответвление, поэкспериментировать, и если всё ок — слить (merge) обратно в main. Для большинства задач хватает одной ветки main.
Попробуй сам: в своём проекте набери git branch — покажет ветки локально. Звёздочка * — это твоя текущая ветка. Увидишь main (или master на старых репо).
5. Clone (клон)
Скопировать весь репо с GitHub к себе. Делается один раз. После этого у тебя полная копия со всей историей.
Попробуй сам: попробуй склонировать открытый репозиторий. Например: git clone [https://github.com/maximgalson/galson-pro.git](https://github.com/maximgalson/galson-pro.git%60). Получишь папку galson-pro с полной историей сайта.
Как выглядит рабочий цикл
На примере публикации статьи на galson.pro:
1. Написал статью (markdown файл)
2. Добавил её в проект: git add src/content/articles/new-article.md
3. Создал коммит (снимок): git commit -m "article: новая статья про skills"
4. Отправил на GitHub: git push origin main
5. Собрал сайт: npm run build
6. Задеплоил на VPS: rsync dist/ → сервер
GitHub — это облачный бэкап и синхронизация. Сайт работает не с GitHub напрямую, а с билда на VPS.
Что видно на GitHub
Зайди на github.com/ИМЯ_ПОЛЬЗОВАТЕЛЯ/НАЗВАНИЕ_РЕПО — там видно:
— Все файлы проекта (текущая версия)
— Commits — история всех изменений (кто, когда, что поменял)
— Branches — ветки (обычно main)
Типичные страхи и ошибки
Новички часто боятся git, потому что думают: "сломаю — не починю". Разберём 4 самых частых случая.
Я случайно удалил файл
Удалил или перезаписал — не беда, пока изменения не закоммичены. Одна команда вернёт прошлый коммит.
Я случайно сделал плохой коммит
Закоммитил что-то не то? Откатить последний коммит — одна команда. Файлы остаются, отмечается только сам коммит.
Your branch is behind — что это
Это значит: на GitHub есть новые изменения (например, агент сделал коммит), а у тебя на компьютере старая версия. Решение — pull.
Merge conflict — когда два человека поменяли одно место
Ты правил файл, и агент правил тот же файл — git не знает чью версию оставить. Появляется "конфликт". Звучит страшно, но решается просто: открываешь файл, видишь оба варианта с пометками, выбираешь нужный, удаляешь остальное, коммитишь.
Если не уверен что выбрать — попроси агента разобраться с конфликтом. Просто скажи "Разреши merge conflict в файле X".
Словарь — что говорят агенты
«закоммитил» — Сохранил снимок изменений
«запушил» — Отправил на GitHub
«склонировал репо» — Скачал полную копию проекта
«мёрж в main» — Слил изменения в основную ветку
«откатил коммит» — Вернулся к предыдущей версии
«diff» — Разница между двумя версиями файла
«PR / pull request» — Запрос на добавление изменений (мы пока не используем)
«git status» — Показать что изменилось с последнего коммита
Проверь себя
1Зачем git хранит всю историю изменений?
2Что такое коммит?
3Чем push отличается от pull?
4Зачем нужны ветки?
5В чём разница между clone и pull?
6Ты случайно удалил важный файл. Что делать?