Что такое Git ветки?

Git ветки (Git Branches): Полное руководство

Git ветка — это независимая линия развития в Git репозитории. Это один из ключевых инструментов для командной разработки и управления версиями кода. Ветка — это просто указатель на конкретный коммит.

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

Представь себе дерево:

• Trunk (main) — основная ветка, куда идёт код в production
• Branches (ветви) — отдельные направления разработки
• Каждая ветка может развиваться независимо, а потом слиться обратно в main

main:     A --- B --- C --- D --- E
                 \
 feature: B --- F --- G --- H
                             \
 bugfix:  B --- I --- J

Зачем нужны ветки?

1. Параллельная разработка

Несколько разработчиков могут работать на разных фичах одновременно без конфликтов:

# Alice работает над новой фичей
git checkout -b feature/auth-system
# git commit, git commit, git commit...

# Bob работает над bug-фиксом
git checkout -b bugfix/memory-leak
# git commit...

# Оба работают параллельно, не мешая друг другу

2. Изоляция экспериментов

Ты можешь экспериментировать без влияния на основной код:

git checkout -b experiment/new-algorithm
# Пробуешь новый подход
# Если не нравится: git checkout main && git branch -d experiment/new-algorithm
# Если нравится: merge в main

3. Code Review и контроль качества

Feature branch позволяет:

• Не сливать код в main напрямую
• Требовать Pull Request
• Все коммиты проверяются перед merge

# Создаешь ветку
git checkout -b feature/payment-system

# Пушишь на GitHub
git push origin feature/payment-system

# Создаешь Pull Request
# Другие разработчики делают code review
# После одобрения: merge

Создание и управление ветками

Создание ветки:

# Способ 1: создать ветку от текущей (обычно main)
git branch feature/user-profile

# Способ 2: создать и сразу переключиться
git checkout -b feature/user-profile

# Способ 3: современный синтаксис (Git 2.23+)
git switch -c feature/user-profile

Просмотр веток:

# Локальные ветки
git branch
  main
* feature/auth  # * = текущая ветка
  bugfix/cache

# Все ветки (локальные + remote)
git branch -a
  main
  feature/auth
  bugfix/cache
  remotes/origin/main
  remotes/origin/feature/auth
  remotes/origin/develop

Переключение между ветками:

# Старый синтаксис
git checkout feature/auth

# Новый синтаксис (рекомендуется)
git switch feature/auth

# Переключиться на предыдущую ветку
git switch -

Удаление ветки:

# Удалить локальную ветку (только если она merged)
git branch -d feature/old-feature

# Удалить с force (даже если не merged)
git branch -D feature/incomplete

# Удалить remote ветку
git push origin --delete feature/auth

Типичный workflow: Feature Branch Workflow

# Шаг 1: Создаешь ветку от main
git checkout main
git pull origin main  # Убедиться, что main актуален
git checkout -b feature/dark-mode

# Шаг 2: Работаешь на ветке
# Меняешь файлы
git status
git add .
git commit -m "feat: add dark mode toggle"
git commit -m "feat: implement dark mode colors"

# Шаг 3: Пушишь на remote
git push origin feature/dark-mode

# Шаг 4: На GitHub создаешь Pull Request (PR)
# - Описываешь что изменилось
# - Code review от teammates
# - Обсуждение и доработки (если нужны)

# Шаг 5: После одобрения — merge в main
# (Обычно на GitHub через UI)

# Шаг 6: Удаляешь ветку
git branch -d feature/dark-mode  # локально
git push origin --delete feature/dark-mode  # remote

Слияние веток (Merge)

Fast-forward merge (ветка прямой потомок main):

main:     A --- B --- C
               \
 feature: C --- D --- E

# После merge
main:     A --- B --- C --- D --- E
feature:                      ^

git checkout main
git merge feature/user-auth
# Fast-forward merge, просто переместит указатель main

Three-way merge (ветка и main развивались параллельно):

main:     A --- B --- C --- F
               \
 feature: C --- D --- E

# После merge (создаётся merge commit)
main:     A --- B --- C --- F --- M (merge commit)
               \             /
 feature:       D --- E ---+

git checkout main
git merge feature/payments
# Создаётся merge commit (может быть конфликт)

Rebase (альтернатива merge):

# Rebase переписывает историю
git checkout feature/new-ui
git rebase main

# Результат: ветка feature как будто создана от новой версии main
main:     A --- B --- C --- F
feature:                   D' --- E'

Разрешение конфликтов

Когда две ветки меняют один и тот же файл, возникает конфликт:

git merge feature/auth
# CONFLICT (content merge): Merge conflict in lib/main.dart

В файле появляется:

<<<<<<< HEAD
// Код из main
void main() {
  runApp(const MyApp());
}
=======
// Код из feature/auth
void main() {
  initAuth();
  runApp(const MyApp());
}
>>>>>>> feature/auth

Решение:

# Вручную выбираешь, какой код оставить
void main() {
  initAuth();
  runApp(const MyApp());
}

# Потом
git add lib/main.dart
git commit -m "Merge feature/auth into main"

Стратегии ветвления

1. Git Flow (для больших проектов)

release/
  ↓
main ← 
  ↑       ← hotfix/
  |   
 develop ← feature/
  ↑     ← bugfix/

2. GitHub Flow (самый простой)

main (production)
 ↑
 | ← feature/
 | ← bugfix/

Имеет 2 правила:

• Все ветки от main
• Для deploy: merge и tag release

3. Trunk-based Development (для CI/CD)

main ← feature/ (very short-lived)
 ↑
 ↓
Прямо в production после merge

Best Practices

Информативные имена веток:

git checkout -b feature/user-authentication
git checkout -b bugfix/null-pointer-exception
git checkout -b docs/update-readme

Регулярно обновляй:

git pull origin main

Работай в feature ветке, не в main:

git checkout -b my-feature
git push origin my-feature

Типичные команды для Flutter разработчика

# Получить новую feature ветку коллеги
git fetch origin
git checkout feature/state-management

# Собрать latest changes перед деплоем
git checkout main
git pull origin main
flutter clean
flutter pub get
flutter run

# Посмотреть что изменилось в ветке
git log main..feature/dark-mode
git diff main..feature/dark-mode

# Стереть локальные изменения (если запутался)
git reset --hard origin/main

Итог

Git ветки — это:

• Основа параллельной разработки
• Инструмент для изоляции фич и экспериментов
• Механизм для code review и контроля качества
• Essential для teamwork

Похожа на то, как иметь несколько черновиков документа и потом соединять лучшие части в финальную версию.