Система контроля версий

Зачем вообще нужна система контроля версий?

Спасает от потерь. Любое изменение можно отменить. Файлы не «ломаются навсегда».
Позволяет работать параллельно. Несколько людей меняют один проект — и не мешают друг другу.
Оставляет следы решений. Каждое изменение сопровождают сообщение «что сделали и зачем».
Ускоряет проверку кода. Легко показать изменения, обсудить, принять или откатить.
Помогает искать баги. Можно быстро найти, в каком изменении всё сломалось.

Как устроена работа с Git (просто и честно)

Вам достаточно запомнить три «коробки»:

Рабочая папка — обычные файлы на диске.
Промежуточная корзина (её ещё называют «индекс») — список того, что войдёт в следующее сохранение.
История — цепочка сохранений (их называют «коммитами»).

Поток такой: изменили файлы → выбрали, что именно сохранить → сделали сохранение → при необходимости отправили на сервер.

Установка и первичная настройка (один раз)

Установите Git с официального сайта или пакетного менеджера.
Укажите имя и почту — они будут в подписях к изменениям.

git config --global user.name "Имя Фамилия"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main
git config --global color.ui auto
git config --list

Начало: создать или склонировать проект

Вариант А. Начать с нуля

mkdir my-project && cd my-project
git init

Появится скрытая папка .git — там вся история и служебные данные.

Вариант Б. Взять готовый проект с сервера

git clone https://gitexample.com/owner/repo.git
cd repo

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

Первое сохранение: «добавить → сохранить → отправить»

Посмотреть статус:

git status

Выбрать, что включить в сохранение:

git add .
# или точечно
git add src/index.ts

Сделать сохранение с понятным сообщением:

git commit -m "Добавить базовый сервер на Express"

Связать проект с сервером и отправить:

git remote add origin https://example.com/owner/repo.git
git branch -M main
git push -u origin main

Повседневные команды, которые реально нужны

Посмотреть историю «в одну строку»:
git log --oneline --graph --decorate
Посмотреть, что поменяли в файлах:
git diff # изменения в рабочих файлах git diff --staged # изменения, уже добавленные в «корзину»
Передумали добавлять файл в «корзину»:
git restore --staged path/to/file

Работа в ветках: безопасные «песочницы»

Ветка — это отдельная линия работы. Нужна новая фича → делаем ветку, не трогаем основную.

git switch -c feature/payments   # создать и перейти
# ...работаем, коммитим...
git push -u origin feature/payments

Слить изменения в основную:

git switch main
git pull                 # подтянуть свежую основную ветку
git merge feature/payments
git push

Удалить локальную ветку после слияния:

git branch -d feature/payments

Обновлять свою ветку от основной: «merge» против «rebase»

merge — просто соединяет истории, оставляя «ветвление» видимым; иногда появляется «коммит слияния».
rebase — как будто переносит ваши изменения поверх другой ветки, делая историю прямой.

Обновить фичу на основе свежего main с «прямой» историей:

git fetch origin
git switch feature/payments
git rebase origin/main

Если появились конфликты — решите их в файлах, затем:

git add измененные_файлы
git rebase --continue

Синхронизация с сервером: забрать, слить, отправить

git fetch origin         # забрать новые изменения, но не сливать
git pull                 # забрать и слить в текущую ветку
git push                 # отправить свои изменения

Конфликты: не страшно

Конфликт — Git не смог объединить изменения автоматически. В файле появятся маркеры:

<<<<<<< HEAD
ваша версия
=======
чужая версия
>>>>>>> feature/payments

Что делать:

Откройте файл, оставьте нужное (или вручную объедините), удалите маркеры.
Проверьте, что всё собирается и тесты зелёные.
Завершите операцию:

# если это было слияние
git add измененные_файлы
git merge --continue   # в новых версиях Git
# или просто коммит, если продолжения не требуется

# если это был rebase
git add измененные_файлы
git rebase --continue

.gitignore: не засоряйте историю мусором

Файл .gitignore в корне проекта говорит Git, какие файлы не отслеживать: логи, артефакты сборки, секреты и т.п.

Пример:

# логи
*.log

# сборка
/dist/
/build/

# зависимости менеджеров
/node_modules/
/.pnp.cjs
.pnp.loader.mjs

# окружение
.env
.env.*
!.env.example

Если файл уже попал в историю, просто добавления в .gitignore мало — надо «отцепить» его от отслеживания:

git rm --cached path/to/file
git commit -m "Не отслеживать сгенерированный файл"

.gitattributes: одинаковые переводы строк и типы файлов

Чтобы в репозитории всегда хранились «чистые» текстовые файлы с одинаковым переводом строк:

* text=auto eol=lf
*.sh text eol=lf
*.bat text eol=crlf

Это избавляет от «грязных диффов» между Windows/macOS/Linux и стабилизирует сборки.

Пишем внятные сообщения к изменениям

Хорошее сообщение отвечает на «что» и «почему». Структура: короткий заголовок (до ~50 символов), затем — детали при необходимости.

Пример:

feat(auth): добавить refresh-токены

Добавляет эндпоинт /auth/refresh, обновляет схему БД
и интеграционные тесты. Улучшается UX повторного входа.

Временная полка (stash): отложить черновик

Когда надо «срочно переключиться» и нет времени на полноценное сохранение:

git stash push -m "Черновик правок стилей"
git switch hotfix/urgent
# ...починили баг...
git switch feature/ui
git stash list
git stash pop

Типовые способы работы в команде

Фича-ветка → запрос на слияние → проверка → в основную ветку. Короткая ветка, небольшие сохранения, обсуждение, автоматические проверки.
Срочный горячий фикс. Ветка от основной, минимальные изменения, быстрые проверки, релиз.
Релизы с тегами. Отмечайте стабильные версии тегами вроде v1.2.3, автоматизируйте сборки.

Безопасность и большие файлы

Не храните в репозитории ключи, пароли, токены. Используйте переменные окружения и менеджеры секретов.
Для больших бинарников (дизайн, видео) — отдельный механизм хранения больших файлов:

git lfs install
git lfs track "*.psd"
git add .gitattributes
git add design/mock.psd
git commit -m "Хранить крупные файлы через LFS"

Диагностика: когда «всё пошло не так»

Посмотреть, что вообще происходит:
git status git log --oneline --graph git diff
Вернуть файл к последнему сохранению:
git restore path/to/file
Откатить подготовку к сохранению:
git restore --staged path/to/file
«Паническая кнопка» (стирает несохранённые правки в рабочей папке — аккуратно!):
git reset --hard

Частые ошибки новичков (и как их избежать)

Слишком большие сохранения. Делите изменения на логические куски.
Плохие сообщения. Пишите, что и зачем сделали; избегайте «fixed», «update».
Секреты в истории. Настройте .gitignore и .gitattributes с первого дня, держите .env вне репозитория и используйте шаблон .env.example.
Работа напрямую в основной ветке. Делайте фичи в ветках — так безопаснее и чище.
Слепой pull. Сначала fetch, посмотрите, что пришло, затем объединяйте.

Мини-тренажёр: сделайте «первый цикл» целиком

Создайте папку проекта и инициализируйте Git.
Добавьте файл README.md и сделайте первое сохранение.
Настройте .gitignore (исключите node_modules, dist, логи).
Создайте ветку feature/greeting, добавьте небольшой код и сохраните.
Слейте ветку в основную, отправьте всё на свой удалённый репозиторий.

Подсказки:

git init
echo "# Hello" > README.md
git add README.md
git commit -m "Первое описание проекта"
git switch -c feature/greeting
mkdir src && echo 'console.log("Hello!")' > src/index.js
git add src/index.js
git commit -m "Приветствие в консоль"
git switch main
git merge feature/greeting
git remote add origin https://example.com/owner/repo.git
git push -u origin main

Короткая шпаргалка

Создать репозиторий: git init
Склонировать: git clone URL
Статус: git status
Добавить изменения: git add ./git add файл
Сохранить: git commit -m "сообщение"
Ветки: git switch -c имя/git switch имя/git branch -d имя
Объединить: git merge другая_ветка/ «выпрямить» историю: git rebase ветка
Синхронизация: git fetch/git pull/git push
История: git log --oneline --graph
Временная полка: git stash push/git stash pop

Если хочешь, адаптирую это под конкретный стек (например, Node/NestJS с примерами .gitignore, .gitattributes, шаблоном сообщений коммитов и базовой интеграцией в GitHub Actions).