Что такое синтетические события?

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

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

Основная идея

Вместо того чтобы просто сохранять файлы, система контроля версий:

• Сохраняет все изменения кода
• Ведёт историю "кто и когда что изменил"
• Позволяет вернуться на старую версию
• Облегчает совместную работу нескольких разработчиков
• Позволяет работать на разных веточках параллельно

Основные функции VCS

1. Отслеживание изменений

Версия 1: файл code.js
  "const x = 5;"
  
Версия 2: файл code.js  <- Сохранено: добавили console.log
  "const x = 5;"
  "console.log(x);"
  
Версия 3: файл code.js  <- Сохранено: изменили значение на 10
  "const x = 10;"
  "console.log(x);"

2. История коммитов Каждое изменение сохраняется с:

• Описанием что изменилось
• Кто это изменил
• Когда это случилось
• Хешем (уникальный идентификатор)

3. Ветки (Branches) Позволяют параллельно разрабатывать функции:

main (основная версия) ----[коммиты]---
  |
  +-- feature/auth (новая функция) --[разработка]--
  |
  +-- bugfix/ui (исправление ошибки) --[работа]--

4. Слияние (Merge) Объединение изменений из одной ветки в другую:

// Ветка feature/auth создала новую функцию
function login(user, password) {
  // код
}

// Слияние в main - теперь функция в основной версии

Типы систем контроля версий

1. Централизованные системы (CVCS) Один центральный сервер, разработчики скачивают/загружают оттуда:

• Примеры: SVN, Perforce
• Плюсы: простые, полный контроль
• Минусы: нужен доступ к серверу для каждого коммита

2. Распределённые системы (DVCS) Каждый разработчик имеет полную копию истории:

• Примеры: Git, Mercurial, Bazaar
• Плюсы: работает без сервера, быстро, надёжно
• Минусы: нужно разобраться в концепции

Git - самая популярная система

Это распределённая система контроля версий. Основные концепции:

Repository (Репозиторий)

my-project/
  .git/          <- папка с историей
  src/
  README.md
  package.json

Staging Area (Область подготовки) Перед коммитом файлы готовятся:

Рабочая папка -> Staging Area -> Repository (история)
  (изменения)   (готово к        (сохранено
               сохранению)       в историю)

Коммит Сохранение снимка проекта с описанием:

git add .                    # добавить в Staging
git commit -m "Fix login bug" # сохранить в историю

Основные операции Git

Создание репозитория

git init                    # инициализировать новый репозиторий
git clone <url>             # клонировать чужой репозиторий

Сохранение изменений

git status                  # посмотреть статус файлов
git add <файл>              # добавить файл в Staging
git commit -m "описание"    # сохранить в историю

Работа с ветками

git branch feature/auth     # создать новую ветку
git checkout feature/auth   # переключиться на ветку
git merge feature/auth      # слить ветку в текущую

Отправка и получение

git push origin main        # отправить на сервер
git pull origin main        # получить обновления

Практический пример рабочего дня

# Утром - получаешь свежие изменения
git pull origin main

# Создаёшь новую ветку для новой функции
git checkout -b feature/dark-mode

# Пишешь код
# ... работаешь несколько часов ...

# Добавляешь изменения
git add .

# Делаешь коммит (сохраняешь в историю локально)
git commit -m "Add dark mode toggle"

# Отправляешь на сервер
git push origin feature/dark-mode

# Создаёшь Pull Request - просишь код-ревью
# Другие разработчики проверяют твой код

# После одобрения - слияние в main
git checkout main
git merge feature/dark-mode
git push origin main

Зачем это нужно в команде

1. Параллельная разработка Несколько разработчиков одновременно пишут разные функции на разных ветках.

2. История и отслеживание Можно посмотреть кто и когда что изменил:

git log --oneline
# a3f5d2 Add dark mode toggle (Иван)
# c2e8f1 Fix login bug (Мария)
# b1d4c0 Update styles (Петр)

3. Откат к старым версиям Если что-то сломалось, легко вернуться:

git revert <коммит>  # отменить изменения коммита
git reset <коммит>   # вернуться к старой версии

4. Code Review Перед слиянием ветки другие проверяют твой код:

Ты пишешь -> Push -> Code Review -> Merge
                  (другие смотрят
                   комментарии,
                   предложения)

5. Резервные копии Код хранится на сервере, не потеряется:

Твой компьютер (сломался)
         |
GitHub/GitLab сервер <- всё в безопасности
         |
Колледжа компьютер

Практический пример конфликта

Два разработчика изменяют один файл:

// Исходная версия (main)
function greet(name) {
  return "Hello, " + name;
}

// Ветка 1: Иван изменил
function greet(name) {
  return `Hello, ${name}!`; // Шаблонная строка
}

// Ветка 2: Мария изменила
function greet(name) {
  return "Hello, " + name.toUpperCase(); // Заглавные буквы
}

При слиянии - конфликт! Git не знает какой вариант выбрать. Разработчик должен решить вручную:

// Результат после решения конфликта
function greet(name) {
  return `Hello, ${name.toUpperCase()}!`; // Оба изменения
}

Best Practices

1. Коммитируй часто

# Хорошо - много маленьких коммитов
git commit -m "Add button component"
git commit -m "Add button styles"
git commit -m "Add button tests"

# Плохо - один большой коммит
git commit -m "Add button feature"

2. Пиши понятные описания

# Хорошо
git commit -m "Fix mobile menu alignment on tablets"

# Плохо
git commit -m "fix"
git commit -m "stuff"

3. Разделяй ветки по функциям

git checkout -b feature/auth          # новая функция
git checkout -b bugfix/logo-size      # исправление ошибки
git checkout -b docs/readme-update    # документация

Итог

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

1. Отслеживания истории - кто и когда что изменил
2. Совместной работы - несколько разработчиков работают одновременно
3. Параллельной разработки - разные ветки для разных функций
4. Отката на старые версии - если что-то сломалось
5. Code Review - проверка кода перед слиянием
6. Резервных копий - код в безопасности на сервере

Вы не можете делать серьёзные проекты без контроля версий. Git является стандартом в индустрии.