С чем работал в Git

Git-практики и workflows в моей практике

Гит — это инструмент, с которым я работаю ежедневно последние 10 лет, и пережил эволюцию от простого версионирования к сложным многофилиальным workflows с десятками разработчиков.

Основные Git-операции, которые я применяю

Ветвление и feature branching:

# Создаю feature ветку с понятным именем
git checkout -b feature/payment-gateway-integration

# Работаю изолировано
git add src/services/payment.js
git commit -m "feat: add Stripe integration"

# Обновляю ветку перед merge request
git fetch origin
git rebase origin/main

# Решаю конфликты при необходимости
git status
# ... исправляю конфликты вручную ...
git add .
git rebase --continue

###策略и workflows

Git Flow для крупных проектов:

В компаниях среднего размера я использовал Git Flow с ветками:

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

# Создание feature ветки
git flow feature start user-authentication

# Завершение feature
git flow feature finish user-authentication
# (автоматически мерджит в develop и удаляет ветку)

# Подготовка релиза
git flow release start 1.0.0
# ... меняю версию в package.json ...
git flow release finish 1.0.0
# (мерджит в main и develop, добавляет тег)

GitHub Flow для стартапов:

В быстро развивающихся проектах использую упрощенный GitHub Flow:

• Одна main ветка
• Feature ветки напрямую из main
• Pull Request для code review
• Автоматический deployment после merge

git checkout -b feature/caching-optimization
# ... разработка ...
git push origin feature/caching-optimization
# Открываю PR в GitHub
# После approve -> merge -> auto-deploy

Rebase vs Merge: мой выбор

Использую rebase для чистой истории:

# Перед merge request - перебазирую на main
git rebase origin/main

# Это создает линейную историю без merge commits
# История читается как линия развития, а не как паутина

Merge для сохранения информации о feature ветках:

# При мерже в main (особенно через PR)
git merge --no-ff feature/important-feature
# Это создает merge commit, который показывает
# когда и какая feature была интегрирована

Interactive Rebase для чистоты истории

Часто использую интерактивный rebase для очистки истории перед push:

# Последние 5 коммитов
git rebase -i HEAD~5

# Интерактивный редактор:
# pick abc1234 feat: init payment service
# squash def5678 fix: typo in payment.js
# reword ghi9101 Add validation  => меняю на "feat: add validation"
# drop jkl1213 debug: console.log  => удаляю отладочный коммит

Это особенно полезно перед merge request, когда хочу скрыть промежуточные коммиты вроде "fix linting" или "wip".

Стеширование и восстановление

Когда переключаюсь между задачами:

# Сохраняю текущую работу без коммита
git stash save "WIP: payment feature"

# Переключаюсь на критичный hotfix
git checkout main
git pull origin main
git checkout -b hotfix/critical-bug

# Исправил и запушил hotfix
# Возвращаюсь к feature
git checkout feature/payment-gateway
git stash pop

Cherry-pick для выборочного переноса коммитов

Перенес fix из develop в production hotfix:

# В ветке hotfix
git cherry-pick abc1234
# (abc1234 — коммит из develop, который нужен в hotfix)

Tags для управления версиями

# Аннотированный тег для релиза
git tag -a v1.2.0 -m "Release version 1.2.0"
git push origin v1.2.0

# Получаю список версий
git tag -l
# v1.0.0
# v1.1.0
# v1.2.0

Работа с remote репозиториями

# Несколько remote для разных целей
git remote add origin https://github.com/company/repo.git
git remote add backup https://github.com/backup/repo.git

# Синхронизация
git fetch --all  # получаю обновления со всех remote
git push origin main
git push backup main  # backup на случай чрезвычайных ситуаций

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

# При merge конфликте
git status
# (показывает файлы с конфликтами)

# Редактирую файл - видищь маркеры:
# <<<<<<< HEAD
# мой код
# =======
# их код
# >>>>>>> feature-branch

# Выбираю нужный вариант (или комбинирую)
git add .
git merge --continue

Pre-commit hooks для качества

Отрабатывал автоматизацию checks перед коммитом:

# .git/hooks/pre-commit
#!/bin/bash
npm run lint
npm run test

# Если lint или тесты упали - коммит не выполнится

Работа в большой команде

Code review через Pull Requests:

• Require approval от минимум 2 разработчиков
• Автоматические checks (lint, test, coverage)
• No merge conflicts allowed
• Обязательный comment if changes requested

Практический опыт

В своей практике:

• Управлял репозиториями с 50+ разработчиками
• Работал с микросервисной архитектурой (15+ репозиториев)
• Внедрял CI/CD pipelines с автоматическим деплоем
• Восстанавливал случайно удаленные коммиты через git reflog
• Проводил code review и мерджил 100+ PR в месяц

Главный принцип: Git — это не просто инструмент версионирования, это язык коммуникации с командой. Чистая история, понятные commit messages и дисциплинированный workflow — это залог успешного сотрудничества в большой команде.