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

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

Система контроля версий (Version Control System, VCS) — это инструмент, который отслеживает изменения в коде, позволяет сотрудничать и вернуться к предыдущим версиям. Это основа современной разработки.

Самая популярная VCS: Git

Git — распределённая система контроля версий, созданная Линусом Торвальдсом для разработки ядра Linux. Сегодня это стандарт индустрии.

Основные проблемы без VCS

1. Потеря истории изменений

File.txt версия 1.0 (1 января)
File.txt версия 2.0 (3 января)
File.txt версия FINAL (5 января)
File.txt версия FINAL-2 (7 января)
File.txt версия FINAL-FINAL (10 января)

Какая актуальная? Где баг был введён? Неясно.

2. Конфликты при совместной работе

Разработчик A изменил button.tsx
Разработчик B изменил button.tsx
Кто перезаписал чей код? Потеря работы!

3. Сложность отката ошибок

Что в коде вчера было рабочим?
Не помню, удалённого кода нет.
=> Переписываю с нуля

Основные возможности VCS

1. Отслеживание истории

# Просмотр истории всех изменений
git log

# вывод:
commit abc123 - Fix button hover state (5 минут назад)
commit def456 - Add dark mode support (2 часа назад)
commit ghi789 - Refactor component structure (1 день назад)

Запомнить, что давно писал — легко.

2. Откат к предыдущей версии

# Если вчера была рабочая версия
git revert abc123
# Отменяет изменения из коммита abc123

# Если вообще нужно вернуться на день назад
git checkout HEAD~1
# HEAD~1 = коммит перед последним

Сценарий: случайно удалил важную функцию -> откатываю за 30 секунд.

3. Параллельная разработка (ветки)

# Main ветка (стабильный код)
git branch main

# Разработчик A создаёт свою ветку
git checkout -b feature/dark-mode
# Работает независимо

# Разработчик B создаёт свою ветку
git checkout -b feature/new-button
# Работает независимо

# Когда оба готовы, мергируют в main

Граф:

main:  C1 --- C2 --- C3 (merge)
       |       |      |
A:     |---D1-D2      |
B:     ------E1-E2----|

4. Откат при конфликте слияния

# Разработчик A смергировал свой код
git merge feature/dark-mode
# Всё сломалось!

# Откатываем
git reset --hard HEAD~1
# Вернулись на шаг назад, как будто ничего не было

5. Просмотр кто что изменил

# Кто изменил строку 42 в button.tsx?
git blame button.tsx

# вывод:
ef234567 (Ivan Petrov    2025-04-01 14:32:15 +0300) className={cn(
ab123456 (Maria Sidorova 2025-03-28 10:15:42 +0300)   'px-4 py-2',

Легко найти автора для вопросов.

Workflow с Git

Типичный рабочий день разработчика

# 1. Утро: обновляю последний код
git pull
# Скачиваю изменения, которые мергировали вчера

# 2. Создаю ветку для своей задачи
git checkout -b feature/api-integration

# 3. Работаю, делаю коммиты
echo "// API функция" >> api.ts
git add api.ts
git commit -m "Add API integration function"

echo "// UI компонент" >> button.tsx
git add button.tsx
git commit -m "Update button to call new API"

# 4. Отправляю на сервер (GitHub, GitLab)
git push origin feature/api-integration

# 5. Создаю Pull Request для review
# (Коллеги проверяют код)

# 6. После одобрения, мергирую в main
git merge feature/api-integration
git push origin main

Коллаборация: Pull Requests

Разработчик A пишет код
  |
  v
Отправляет Pull Request (PR)
  |
  v
Разработчик B review код
  |
  v
Если OK: approve
Если нет: request changes
  |
  v
Разработчик A отвечает на комментарии
  |
  v
Approve -> Merge в main
  |
  v
CI/CD тестирует -> Deploy

Пример PR:

Title: Add dark mode support

Description:
- Добавлены CSS переменные для тёмной темы
- Компонент Switch для выбора темы
- localStorage для сохранения выбора

Changes:
+ globals.css (45 строк)
+ DarkModeToggle.tsx (NEW)
~ Layout.tsx (10 строк)

Reviewers: @ivan @maria

Ветвление: Git Flow

Популярная стратегия разработки:

main (production-ready)
  ^
  |
  +-- develop (staging)
       ^
       |
       +-- feature/user-auth
       +-- feature/dark-mode
       +-- hotfix/login-bug

• main — только готовый, протестированный код
• develop — на стадии разработки, интеграция фич
• feature/* — отдельные фичи
• hotfix/* — срочные исправления в продакшене

Защита от потери данных

Без VCS:

component.tsx (версия 1)
component.tsx.bak (ручной backup, забыл обновить)
component.tsx.old (старая версия, может быть неактуальна)
=> Непонятно, какая версия верная

С VCS:

git log component.tsx  # вся история
git show abc123:component.tsx  # версия из коммита abc123
git diff abc123 def456  # что изменилось между версиями
=> Всё прозрачно и отслеживаемо

Интеграция с CI/CD

# Разработчик пушит код
git push origin feature/new-button

# Автоматически:
# - Запускаются тесты
# - Проверяется линтинг
# - Собирается проект
# - Создаются артефакты

# Если всё ОК -> показывается зелёная галочка на PR
# Если баги -> красный крест

Ключевые команды Git

# Инициализация
git init

# Клонирование проекта
git clone https://github.com/user/project

# Просмотр статуса
git status

# Добавление файлов
git add file.ts
git add .

# Создание коммита
git commit -m "Describe changes"

# Отправка на сервер
git push

# Скачивание изменений
git pull

# Создание ветки
git branch feature/new
git checkout -b feature/new  # или короче

# Слияние
git merge feature/new

# Просмотр истории
git log
git diff

Почему каждый разработчик ДОЛЖЕН знать Git

1. Это стандарт — без Git не устроиться на работу
2. Это спасение — откатить ошибку за секунду
3. Это коллаборация — работать в команде без потерь
4. Это аудит — отследить, кто что и когда изменил
5. Это deploy — большинство CI/CD работают через git push

Заключение

Система контроля версий нужна для:

• Сохранения истории всех изменений
• Возможности отката к предыдущим версиям
• Параллельной разработки нескольких функций
• Коллаборации без потери данных
• Аудита (кто, когда, что изменил)
• Интеграции с CI/CD
• Развёртывания (deployment через git push)

Bез VCS — хаос. С VCS — порядок.