🔍

📌 Шпаргалка #36

Git + GitHub: Шпаргалка для работы с проектом

✍️ pentestudy 📅 24.04.2026

Практическое руководство для ежедневной работы. Всё что реально нужно знать, без теории ради теории.

🎯 Зачем это всё

Git — это система контроля версий. Если коротко:

Сохраняет историю всех изменений с точками отката
Защищает от случайной публикации сырого кода
Позволяет группировать изменения в осмысленные порции
Делает возможной командную работу
Синхронизирует код между твоим компом и GitHub (откуда Vercel деплоит на сайт) Твой обычный workflow: пишешь код в VS Code → отправляешь в GitHub → Vercel автоматически деплоит на сайт.

📦 Как Git устроен: 4 зоны

[1] Рабочая папка  →  [2] Staging  →  [3] Локальный репо  →  [4] GitHub
    (твои файлы)      (git add)        (git commit)         (git push)

Проще говоря — аналогия с почтой:

Зона	Что это	Команда
1. Рабочая папка	Файлы на компе, ты их редактируешь	—
2. Staging	"Положил в коробку" — готовишь к отправке	`git add`
3. Локальный репо	"Сдал в почтовое отделение" — зафиксировал снимок	`git commit`
4. GitHub	"Посылка уехала адресату" — изменения на сервере	`git push`

До push всё локально — GitHub ничего не знает. Сайт не меняется. После push — GitHub получает изменения, Vercel деплоит на прод.

🚀 Базовый ежедневный цикл

99% твоей работы сводится к этому:

git add .                      # добавить все изменения в staging
git commit -m "что сделал"     # зафиксировать коммит с описанием
git push                       # отправить на GitHub → Vercel деплоит

Пример:

git add .
git commit -m "Add featured images to blog news"
git push

Три команды. Всегда в этом порядке.

📝 Если работаешь через VS Code UI

Можно вообще не трогать терминал:

Открой Source Control (иконка с веточкой слева, или Cmd+Shift+G)
Нажми + рядом с файлом (Stage) — или + рядом с "Changes" чтобы застейджить всё
Введи сообщение коммита в поле сверху
Нажми галочку Commit
Нажми Sync Changes (или три точки → Push) Эквивалентно git add + commit + push.

🎨 Цвета файлов в VS Code

В Source Control и в дереве файлов ты увидишь цветные метки:

Цвет	Буква	Что значит
🟢 Зелёный	U	Untracked — новый файл, Git его не отслеживает
🟡 Жёлтый	M	Modified — файл изменён с последнего коммита
🟠 Оранжевый	A	Added — в staging (после `git add`)
🔴 Красный	D	Deleted — файл удалён
🔵 Синий	R/C	Renamed или Conflict
⚫ Серый	!	Ignored — в `.gitignore`
Без цвета	—	Всё закоммичено, изменений нет

На практике встречаешь в основном:

🟢 Зелёный — когда создал новый файл
🟡 Жёлтый — когда изменил существующий
Пропало — значит закоммитил ✓

🔍 Полезные команды проверки

git status           # что сейчас изменено, в каком состоянии
git status --short   # то же самое, но компактно
git log              # история коммитов
git log --oneline    # история в одну строку
git diff             # что именно изменилось в файлах

Пример вывода git status:

On branch main
Your branch is up to date with 'origin/main'.
 
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   src/components/BlogNewsSection.tsx
 
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        src/components/NewFeature.tsx

Читается так:

Ветка main, синхронизирована с GitHub
Один файл в staging, готов к коммиту (modified)
Один файл не отслеживается (Untracked) — нужен git add

↩️ Отмена изменений на любом этапе

На этапе "рабочая папка" (до `git add`)

Передумал — хочешь вернуть файл к последней закоммиченной версии:

git restore имя_файла          # один файл
git restore .                  # все файлы

В VS Code: правый клик по файлу в Source Control → Discard Changes.

⚠️ Изменения удалятся навсегда. Восстановить нельзя.

На этапе "staging" (после `git add`, до `git commit`)

Добавил в staging, но передумал включать в коммит:

git restore --staged имя_файла    # убрать из staging

Файл вернётся в "рабочую папку" с изменениями. Можешь доработать и заново git add.

После `git commit`, но до `git push`

Коммит уже сделан локально, но ещё не отправлен. Варианты:

Откатить последний коммит, сохранив изменения в staging:

git reset --soft HEAD~1

Откатить и убрать все изменения совсем:

git reset --hard HEAD~1

⚠️ Опасно — все изменения из последнего коммита удалятся.

Изменить сообщение последнего коммита:

git commit --amend -m "новое сообщение"

После `git push` (изменения уже на GitHub)

Тут сложнее, но возможно. Два варианта:

Безопасный — revert (создаёт обратный коммит):

git revert HEAD
git push

Не удаляет историю, а создаёт новый коммит, который отменяет предыдущий. Правильный способ для публичных репо.

Агрессивный — force push (перезаписывает историю):

git reset --hard HEAD~1
git push --force

⚠️ Используй только если:

Работаешь один
Только что запушил и сразу понял что не то
Точно знаешь что делаешь

🔄 Типичные сценарии

Сценарий 1: Начал новый день работы

Сначала проверь что у тебя актуальная версия с GitHub:

git pull

Особенно важно если ты редактировал файлы через веб-интерфейс GitHub напрямую, или работаешь с другого компа.

Сценарий 2: Сделал изменения, хочу отправить

git status          # проверить что изменилось
git add .           # добавить всё в staging
git commit -m "краткое описание"
git push            # отправить на GitHub

Сценарий 3: Ой, сломал что-то, хочу вернуть как было

Если ещё не закоммитил:

git restore .

Если закоммитил локально, но не запушил:

git reset --hard HEAD~1

Если уже запушил:

git revert HEAD
git push

Сценарий 4: Хочу посмотреть что было раньше

git log --oneline           # список коммитов
git show <хэш_коммита>      # что в конкретном коммите

Чтобы вернуться к состоянию прошлого коммита временно:

git checkout <хэш_коммита>   # посмотреть
git checkout main            # вернуться к текущему

Сценарий 5: Добавил что-то в staging случайно

git restore --staged имя_файла

Сценарий 6: Файл не должен быть в Git (пароли, ключи, node_modules)

Создай файл .gitignore в корне проекта с содержимым:

node_modules/
.env
.env.local
.DS_Store
*.log

Файлы, которые подходят под эти шаблоны, Git будет игнорировать.

⚠️ Если файл уже в Git, .gitignore его не уберёт. Надо:

git rm --cached имя_файла
git commit -m "Remove sensitive file"
git push

📋 Хорошие сообщения коммитов

Плохо:

update
fix
changes
work
asdasd

Хорошо:

fix: ошибка в форме обратной связи
feat: добавлен блок новостей на главную
style: обновлены цвета кнопок
docs: добавлен README
refactor: оптимизирован компонент BlogNewsSection

Правило большого пальца: сообщение должно отвечать на вопрос "что делает этот коммит?".

Через полгода ты посмотришь git log и скажешь себе спасибо.

⚠️ Типичные ошибки и как их избежать

"git push ничего не делает"

Причина: нет закоммиченных изменений для отправки.

Решение:

git status              # проверить что в staging
git add .
git commit -m "..."
git push

"Your branch is behind origin/main"

Причина: на GitHub есть коммиты, которых у тебя локально нет (например, ты правил через веб-интерфейс).

Решение:

git pull

"Merge conflict"

Причина: ты и кто-то ещё (или ты с другого устройства) правили один и тот же файл.

Решение:

Открой файл с конфликтом в VS Code
Увидишь маркеры <<<<<<<, =======, >>>>>>>
Вручную выбери что оставить, удали маркеры
git add имя_файла
git commit -m "Resolve merge conflict"
git push

"Случайно закоммитил секретный ключ"

Решение (срочно):

Смени ключ в сервисе — он уже скомпрометирован, коммит в истории GitHub
Удали из файла, добавь в .gitignore
Закоммить изменения
Если ключ критичный — используй git filter-branch или BFG Repo-Cleaner чтобы очистить из всей истории ⚠️ Любой секрет, попавший в GitHub, считается утёкшим. Меняй, не полагайся на удаление истории.

Начал делать push, а там запрашивает логин

С 2021 года GitHub не принимает пароль для push. Нужно использовать:

Personal Access Token (PAT) вместо пароля
Или SSH-ключи
Или GitHub CLI (gh auth login) Самый простой способ: установи GitHub CLI и выполни:

gh auth login

🔐 Безопасность

Что НИКОГДА не коммитить:

API-ключи и токены (OpenAI, AWS, и т.п.)
Пароли
.env файлы с секретами
Приватные ключи (SSH, SSL)
Базы данных с реальными данными
node_modules/ (тяжёлая папка с зависимостями)

Что делать:

Добавь в .gitignore сразу на старте проекта
Используй переменные окружения (.env)
На Vercel задавай секреты через Settings → Environment Variables

Пример `.gitignore` для типичного веб-проекта:

# Dependencies
node_modules/
.pnp
.pnp.js
 
# Environment
.env
.env.local
.env.*.local
 
# Build output
dist/
build/
.next/
.vercel/
 
# System
.DS_Store
Thumbs.db
 
# Editor
.vscode/
.idea/
 
# Logs
*.log
npm-debug.log*
yarn-debug.log*

🌿 Ветки (branches) — для продвинутой работы

Пока тебе это не нужно, но на будущее:

Ветка — это параллельная версия кода. Например, хочешь попробовать новую фичу без риска сломать прод.

git branch                       # список веток
git branch новая-фича            # создать ветку
git checkout новая-фича          # переключиться на неё
git checkout -b новая-фича       # создать и переключиться сразу
 
# ... работаешь, коммитишь ...
 
git checkout main                # вернуться на main
git merge новая-фича             # влить изменения в main
git branch -d новая-фича         # удалить ветку после слияния

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

🎯 Minimum viable Git — что запомнить в первую очередь

Если ничего не запоминать из этой шпаргалки, запомни это:

# Каждый раз когда сделал изменения:
git add .
git commit -m "что сделал"
git push
 
# Перед началом работы с другого компа или после правок на GitHub:
git pull
 
# Посмотреть что происходит:
git status
 
# Отменить все локальные изменения (до add):
git restore .

Этого хватит на 95% задач.

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

Основные

Команда	Что делает
`git status`	Статус репозитория
`git add <файл>`	Добавить файл в staging
`git add .`	Добавить все изменения
`git commit -m "..."`	Сделать коммит
`git push`	Отправить на GitHub
`git pull`	Забрать с GitHub
`git log`	История коммитов

Отмена

Команда	Что делает
`git restore <файл>`	Откатить файл до последнего коммита
`git restore --staged <файл>`	Убрать из staging
`git reset --soft HEAD~1`	Откатить коммит, сохранить изменения
`git reset --hard HEAD~1`	⚠️ Откатить коммит и удалить всё
`git revert HEAD`	Создать обратный коммит (безопасно)

Просмотр

Команда	Что делает
`git diff`	Что изменилось в файлах
`git diff --staged`	Что в staging
`git log --oneline`	Компактная история
`git show <хэш>`	Детали конкретного коммита

Ветки (advanced)

Команда	Что делает
`git branch`	Список веток
`git checkout -b <имя>`	Создать и переключиться
`git merge <ветка>`	Слить ветку в текущую
`git branch -d <имя>`	Удалить ветку

📚 Если хочешь копнуть глубже

Pro Git — бесплатная книга на русском, официальная
Learn Git Branching — интерактивный тренажёр
Oh Shit, Git!?! — что делать когда всё сломалось

Последнее обновление: 2026-04-24

Содержание

🎯 Зачем это всё 📦 Как Git устроен: 4 зоны 🚀 Базовый ежедневный цикл 📝 Если работаешь через VS Code UI 🎨 Цвета файлов в VS Code 🔍 Полезные команды проверки ↩️ Отмена изменений на любом этапе На этапе "рабочая папка" (до git add) На этапе "staging" (после git add, до git commit) После git commit, но до git push После git push (изменения уже на GitHub) 🔄 Типичные сценарии Сценарий 1: Начал новый день работы Сценарий 2: Сделал изменения, хочу отправить Сценарий 3: Ой, сломал что-то, хочу вернуть как было Сценарий 4: Хочу посмотреть что было раньше Сценарий 5: Добавил что-то в staging случайно Сценарий 6: Файл не должен быть в Git (пароли, ключи, node_modules) 📋 Хорошие сообщения коммитов ⚠️ Типичные ошибки и как их избежать "git push ничего не делает" "Your branch is behind origin/main" "Merge conflict" "Случайно закоммитил секретный ключ" Начал делать push, а там запрашивает логин 🔐 Безопасность Что НИКОГДА не коммитить: Что делать: Пример .gitignore для типичного веб-проекта: 🌿 Ветки (branches) — для продвинутой работы 🎯 Minimum viable Git — что запомнить в первую очередь 🆘 Шпаргалка команд Основные Отмена Просмотр Ветки (advanced) 📚 Если хочешь копнуть глубже