Менял ли коммиты в Git

Менял ли коммиты в Git?

Да, я часто использую различные техники переписывания коммитов в Git для поддержания чистоты истории. Это важный навык в профессиональной разработке.

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

Ammend коммита: Самый простой случай — исправление последнего коммита без создания нового:

git add .
git commit --amend --no-edit

Это используется, когда я забыл добавить файл или сделал небольшую опечатку в коде. Вместо создания отдельного коммита "fix typo", правлю существующий.

Interactive rebase: Более сложная операция для переделки нескольких коммитов:

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

Это позволяет:

• Объединять коммиты (squash)
• Переупорядочивать их
• Переписывать сообщения
• Удалять ненужные коммиты

Практические применения

Squash перед merge: Когда работаю над feature branch, часто делаю множество "WIP" (work in progress) коммитов. Перед merge в main делаю squash для чистой истории.

Переделка сообщений: Когда коммит уже в remote, но сообщение неправильное, использую reword флаг при interactive rebase.

Разделение большого коммита: Если в одном коммите слишком много разнородных изменений, откатываю коммит и разделяю на несколько:

git reset HEAD~1       # Откатываю коммит, но файлы остаются в staging
git add part1.cpp      # Добавляю отдельно
git commit -m "Feature A"
git add part2.cpp
git commit -m "Feature B"

Правила и ограничения

Never rebase public commits: Главное правило — никогда не переписывай коммиты, которые уже в shared ветке. Если я уже push'нул в main, переписывание сломает историю для всей команды. Поэтому force push на main/master строго запрещён.

Preserve merge commits: При rebase нужно быть осторожным с merge коммитами. Флаг --preserve-merges сохраняет структуру слияний.

Atomic коммиты: Я стараюсь делать коммиты логически завершёнными — один коммит = одна фича/баг фикс. Это помогает при code review, бисекту и откату.

Advanced техники

Autosquash: Git может автоматически применять squash на основе сообщений коммитов с префиксом "fixup!".

Cherry-pick: Если нужно взять отдельный коммит из одной ветки в другую:

git checkout main
git cherry-pick <commit-hash>

Часто использую для переноса фиксов между ветками.

Reflog: Git сохраняет историю всех операций. Если случайно повредил rebase, могу откатиться:

git reflog                    # Показывает все действия
git reset --hard HEAD@{2}     # Откатываюсь на 2 действия назад

Мой подход в production

В production коде я придерживаюсь:

1. Чистая история: Коммиты логичны и можно легко найти, когда появилась ошибка через git blame
2. Атомарность: Каждый коммит — это завершённая работа, которую можно откатить независимо
3. Readable messages: Сообщения коммитов включают контекст, не просто "fix" или "update"
4. No force push: На shared ветках никогда не переписываю историю
5. Code review first: Перед переработкой истории жду approval от team leads

Переписывание коммитов — это инструмент для поддержания качества кода и истории, но нужно использовать его ответственно.