Сергей Кузнецов

#!/bin/bash

# === Настройки ===
COUNT=10
NEW_DATE="2025-03-27T17:00:00"

# === Автоматическая замена pick на edit ===
export GIT_SEQUENCE_EDITOR="sed -i 's/^pick /edit /'"

# === Старт интерактивного rebase ===
git rebase -i HEAD~$COUNT

# === Цикл по каждому коммиту с изменением даты ===
while ! git rebase --continue 2>/dev/null; do
  GIT_COMMITTER_DATE="$NEW_DATE" git commit --amend --no-edit --date "$NEW_DATE"
done

echo
echo "✅ Все $COUNT коммитов переписаны с новой датой: $NEW_DATE"
echo " Не забудь сделать принудительный push: git push --force"

1. Liquibase diff
   
   Liquibase умеет сравнивать текущее состояние базы с эталонным snapshot или changelog (команды liquibase diff, generateChangeLog). Это может автоматически сгенерировать changesets. Не всегда идеально, особенно для данных, но может служить хорошей стартовой точкой.
   
   
2. Скрипт дампа и автоформатирования
   
   Написать утилиту, которая:
   
   • выгружает актуальные записи (по дате или через служебную метку),
     
   • форматирует результат построчно (для удобных диффов в Git),
     
   • сохраняет в SQL или CSV с нужным форматированием,
     
   • проверяет ошибки: зависимости, ключи, синтаксис и т. п.
     
   
   
3. Служебное поле change_id
   
   Добавление такого поля в ключевые таблицы упростит группировку и экспорт связанных изменений. Это также упростит отладку и проверку связей.
   
   
4. Проверки перед мержем
   
   Автоматический pre-merge скрипт может:
   
   • проверять, что ветка актуальна относительно master,
     
   • валидировать синтаксис SQL и CSV,
     
   • выявлять ошибки в зависимостях (foreign keys, отсутствие spec при наличии body и т. п.),
     
   • проверять потенциальные конфликты по ключам в changesets.
     
   
   
5. Dolt и Bytebase
   
   Как уже писали выше, эти проекты позволяют рассматривать базу как репозиторий Git. Подход интересный, но требует серьёзной перестройки процессов. Внедрение возможно, если проект активно развивается и готов к архитектурным изменениям.