Как заливали фичи в Git?

Как заливал фичи в Git

Процесс заливки фич в Git — это не просто коммиты и пуши. Это организованный workflow, который обеспечивает качество кода и безопасность мастера. Расскажу свой систематический подход.

1. Создание feature ветки

# Синхронизируюсь с мастером
git checkout main
git pull origin main

# Создаю feature ветку от мастера
git checkout -b feature/user-authentication

# Или если фича от задачи
git checkout -b tasks/123-user-authentication

# Или с JIRA ID
git checkout -b PROJ-1234-auth-improvements

Соглашение об именовании:

• feature/название — новая фича
• fix/название — исправление бага
• refactor/название — рефакторинг
• docs/название — документация
• perf/название — оптимизация

2. Разработка локально

# Я работаю в feature ветке
# Делаю изменения, тестирую локально

# Проверяю, что ничего не сломал
npm run lint      # Линтинг
npm test          # Юнит тесты
npm run build     # Сборка

# Если всё работает, коммичу
git add .
git commit -m "feat: add user authentication module"

# Продолжаю разработку
# Делаю несколько коммитов
git commit -m "feat: add login form"
git commit -m "feat: add JWT handling"
git commit -m "test: add authentication tests"

3. Синхронизация с мастером (если разработка долгая)

# Если в main произошли изменения, нужно синхронизировать
git fetch origin

# Способ 1: rebase (переписываем историю, для чистой истории)
git rebase origin/main

# Если есть конфликты, разрешаем их
git status  # Видим конфликты
# Открываем файлы и разрешаем конфликты
git add .
git rebase --continue

# Способ 2: merge (сохраняем историю)
git merge origin/main

# Выбираю rebase для чистой истории

4. Подготовка к пулл-реквесту

Проверяю, что всё работает:

# Финальная проверка перед PR
git fetch origin
git rebase origin/main  # Или git merge origin/main

npm run lint      # Все ошибки линтера фиксим
npm test          # Все тесты должны проходить
npm run build     # Сборка должна быть успешна

# Если есть e2e тесты
npm run test:e2e

Проверяю коммиты:

# Смотрю историю своих коммитов
git log --oneline origin/main..HEAD
# Вывод:
# abc1234 test: add authentication tests
# def5678 feat: add JWT handling
# ghi9012 feat: add login form
# jkl3456 feat: add user authentication module

# Если коммиты ещё не отправлены, могу переупорядочить
# Это опционально, но хороший стиль

5. Пушу в remote

# Если это первый раз, нужно пушить с upstream
git push -u origin feature/user-authentication

# После первого раза
git push

# Если был rebase и я перезаписал историю (осторожно!)
git push --force-with-lease
# --force-with-lease безопаснее, чем --force
# Он не перезапишет, если кто-то уже запушил в эту ветку

6. Создание Pull Request

Через GitHub/GitLab UI или CLI:

# Через CLI (если установлен gh)
gh pr create \
  --title "Add user authentication" \
  --body "This PR adds JWT-based authentication for users
  
## Changes
- Add login form component
- Add JWT token handling
- Add authentication service
- Add tests for authentication

## How to test
1. Fill in login form with test credentials
2. Check that JWT is stored in httpOnly cookie
3. Verify auth persists after page reload

Fixes #123"

В описании PR указываю:

• Что сделано
• Как это тестировать
• Ссылка на issue
• Скриншоты (если UI изменения)
• Ссылки на документацию

7. Code Review процесс

Когда я создаю PR, жду feedback:

# Если нужны исправления, я их делаю в той же ветке
git add .
git commit -m "review: address feedback from code review"
git push

# Или если хочу переписать последний коммит
git add .
git commit --amend --no-edit
git push --force-with-lease

# GitHub/GitLab автоматически обновит PR

Типичный feedback:

• "Добавь тест для этого случая"
• "Переименуй переменную, имя не ясно"
• "Используй компонент из ui/, не создавай новый"
• "Это нарушает архитектуру, отрефакторь"

Я отвечаю на комментарии и исправляю.

8. Merge в мастер

Когда PR одобрен и все checks прошли:

Способ 1: Squash and merge (один коммит)

# GitHub автоматически создаст один коммит из всех моих коммитов
# Хорошо для мастера — чистая история

Способ 2: Rebase and merge (переписать историю)

# Каждый коммит будет применён отдельно к мастеру
# Хорошо для детальной истории

Способ 3: Merge commit (сохранить ветку)

# Создаст merge commit, сохранит историю ветки
# Хорошо, когда хочешь видеть, как была разработана ветка

Я обычно выбираю squash and merge для мастера, чтобы история была чистой.

9. Локальная очистка

# После мерджа удаляю локальную ветку
git branch -d feature/user-authentication

# Удаляю remote ветку
git push origin --delete feature/user-authentication

# Или если ветка уже удалена на remote
git branch -D feature/user-authentication

10. Полный workflow пример

# 1. Создание ветки
git checkout main
git pull origin main
git checkout -b feature/user-authentication

# 2. Разработка
echo 'код фичи' > src/auth/Auth.tsx
npm test          # Тесты проходят
npm run lint      # Линтинг чистый

# 3. Коммиты
git add src/auth/Auth.tsx
git commit -m "feat: add authentication component"

git add src/services/authService.ts
git commit -m "feat: add auth service"

git add src/__tests__/auth.test.tsx
git commit -m "test: add auth tests"

# 4. Синхронизация
git fetch origin
git rebase origin/main

# 5. Финальная проверка
npm run lint
npm test
npm run build

# 6. Пуш
git push -u origin feature/user-authentication

# 7. PR через UI (GitHub/GitLab)
# Заполняю описание, указываю issue

# 8. Жду code review
# Может быть feedback

# 9. Исправления (если нужны)
git add .
git commit -m "review: address feedback"
git push

# 10. Merge
# После одобрения, mergю через UI (squash and merge)

# 11. Очистка
git fetch origin
git branch -d feature/user-authentication

11. Лучшие практики

Коммиты:

• Небольшие, логичные коммиты (не все в один)
• Понятные сообщения (imperative mood: "add", не "added")
• Формат: type: description (feat, fix, test, refactor, docs)

Ветки:

• Короткоживущие ветки (несколько дней, не недель)
• Регулярная синхронизация с main
• Одна ветка = одна фича или одна задача

Pull Requests:

• Небольшие PR (200-400 строк), легче ревьюить
• Понятное описание с контекстом
• Линки на тикеты
• Скриншоты для UI изменений

Code Review:

• Жду минимум одного одобрения
• Обращаю внимание на комментарии
• Обсуждаю, если не согласен (вежливо)

12. Конфликты при слиянии

# Если возникли конфликты при rebase
git rebase origin/main
# CONFLICT (content): Merge conflict in src/auth/Auth.tsx

# Разрешаю конфликт
# Открываю файл, вижу <<<<<<, ======, >>>>>>
# Выбираю нужный вариант или комбинирую

git add src/auth/Auth.tsx
git rebase --continue

13. Что НЕ нужно делать

# НЕ пушу напрямую в main
# git push origin feature:main  # НЕЛЬЗЯ!

# НЕ делаю git push -f (force push)
# Можно случайно перезаписать чужие коммиты
# Если нужно, использую --force-with-lease

# НЕ оставляю дебаг код или console.log
git diff main | grep 'console.log' # Должно быть пусто

# НЕ коммичу зависимости через node_modules
# Они в .gitignore

# НЕ забываю обновить тесты
# Все тесты должны проходить

Ключевой вывод

Процесс заливки фичи в Git:

1. Создать feature ветку от main
2. Разработать и тестировать локально
3. Синхронизироваться с main (rebase/merge)
4. Проверить lint, тесты, сборку
5. Пушить и создать PR
6. Ждать code review и исправлять feedback
7. Мержить (squash or rebase for clean history)
8. Удалить локальную и remote ветки

Этот процесс обеспечивает качество, безопасность и чистоту истории проекта.