Есть проект десктопного приложения, который я сейчас активно рефакторю. Там и в коде бардак и в структуре каталогов. Положил я всё это в git, коммичу:
loader/ui: center OK button
loader/model: refactor SomeClass code
...
При этом:
- файлики, меняемые коммитом «loader/ui», в каталоге проекта лежат тоже в loader/ui;
- от коммита к коммиту проект должен собираться и работать;
- коммит не должен изменять более одной области проекта.
Всё шло неплохо, а теперь мне надо убрать лишние поля из одной из таблиц. Ступил я в ранее нетронутый подкаталог sql и увидел там, что вся база loader лежит в одном большом файле.
Первое, что хочу сделать – распилить один файл на мелкие, по одному на каждую таблицу/вьюху/процедуру.
А дальше вопрос – куда их класть? Например, есть класс FooStorage с методом GetFoos, который дёргает хранимую функцию fnGetFoos. Получается, что код fnGetFoos – это как бы часть класса FooStorage, и лежать бы ей рядом с исходником FooStorage. Но я нигде не видел, чтобы SQL исходники хранили вместе с другими, видел только раздельное хранение.
Если я большой SQL распилю, а его части переносить не буду, тогда я буду вынужден нарушать свои же правила по ведению истории git:
- изменю скрипт таблицы и закоммичу – поломаю код;
- изменю и скрипт и код класса одновременно – коммит изменит больше одной области;
- изменю и скрипт и код класса одновременно, и напишу в коммите loader/model – вроде бы всё верно, но один из изменённых файлов не лежит в подкаталоге, указанном в коммите.
Мозги плавятся, перфекционист внутри грызёт углы и воет: хочется сделать правильно и красиво. Возможно, я наркоман.
А как у вас хранятся SQL в проектах? Или может болт забить на аккуратную историю в git и просто фигачить? Проект веду я один, в принципе git могу вести как угодно, но хочется потомкам оставить хорошо структурированную историю.
