Этап 4 - Ветки и слияние

В предыдущем этапе мы научились контролировать, что именно коммитится. Теперь добавим реальную командную ситуацию: нужно внедрить цветовое выделение приоритета в task-service, но не рисковать основной веткой.

Ветки и слияние в Git

Ветка как отдельный поток работы

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

Простая модель: main — это аккуратная общая версия, а ваша ветка — рабочий стол для конкретной задачи. В ветке можно делать commits, проверять результат и только потом переносить изменение обратно в main.

Создайте ветку функции:

git switch main
git switch -c feature/task-priority-labels

В этой ветке меняйте только нужную логику. Откройте task-service.js в редакторе, замените содержимое на этот вариант и сохраните файл:

const tasks = [];

export function addTask(task) {
  const exists = tasks.some((item) => item.title === task.title);
  if (exists) return false;
  tasks.push(task);
  return true;
}

Сделайте отдельный commit:

git add task-service.js
git commit -m "feat: prevent duplicate task titles"

Вернуться и слить обратно

git switch main
git merge feature/task-priority-labels

Если в main не было конфликтующих изменений на этом же файле, слияние пройдет быстро (часто fast-forward). Если были параллельные правки, появится merge commit — это нормально.

Команда	Когда использовать	Что важно
`git branch`	Просмотр списка	Имена веток показывают поток задач
`git switch -c`	Создать и сразу перейти	Хорошее имя = понятное намерение
`git merge`	Слить текущую ветку с другой	Приток изменений идет в текущую ветку

Командный ритм ветвления

Обычно для разных задач используются разные ветки:

fix/duplicate-check
feature/task-priority-labels
docs/task-readme-refresh

Это уменьшает риск конфликтов и делает ревью прозрачным.

Практика на `task-service`

На main сделайте небольшой commit с уточнением документации.
Создайте feature/task-analytics, добавьте notes.txt или новый файл отчета.
Закоммитьте эту ветку.
Вернитесь в main и выполните merge.
Запустите git log --oneline --graph и посмотрите, как выросла история.

Теперь у вас есть рабочая модель экспериментов: branch как безопасная линия, а не как «копия всего проекта».

Расширение: почему ветки спасают main

Если PR отклонен на ревью, код не пропадает: ветка остается рабочей, вы делаете новый commit и пробуете merge снова. main меняется только после согласования.

Для устойчивой команды удобно держать:

feature-ветку с незавершенным набором изменений;
локальную main, синхронизированную с remote.

Перед слиянием полезно посмотреть git log --oneline --graph и убедиться, что ветка не унеслась в неожиданный путь. Такой контроль даёт меньше конфликтов и меньше спонтанных отклонений по смыслу изменений.

На этом этапе у вас уже должна быть защита: можно вести эксперименты, но в production-линии остаётся порядок.

Branching And Merging