Разработка большой фичи — это ад для истории коммитов. В идеале каждый коммит посвящён одной вещи: сперва типы, потом работа с БД, затем серверные CRUD-операции, клиентский API, интерфейс. Рецензенты проходят PR маленькими кусочками. На практике получается каша: типы, CRUD, какой-то тестовый код, UI, потом фикс типов, фикс UI, рефакторинг, снова фикс UI. Поздние коммиты переписывают ранние, и логика теряется.
Система контроля версий jujutsu облегчает прыганье между коммитами и быструю итерацию, но усилия всё равно требуются, и наступает «усталость от строгости» (git rigour fatigue). Команды jj absorb и jj squash -i помогают частично, но у каждой свои проблемы. absorb привязывает изменения к последнему изменившему эти файлы коммиту — это не всегда то, что нужно. squash может затянуть в ад слияний, если границы между изменениями неидеальны.
Автор предлагает другой подход. Представим коммиты цветами: красные — типы, синие — UI и так далее. Обычно всё перемешано. Выход — сначала создать идеальную структуру будущих коммитов пустыми (например, jj new -B messy-first -m 'red'), а потом, используя jj new -A red -m 'blue' и так далее, сформировать правильную цепочку контейнеров. Затем все реальные коммиты с изменениями смержить в один большой: jj squash --from messy-first..messy-last --into messy-first. После этого интерактивно (jj squash -i --from messy-first --into red) разложить изменения по соответствующим пустым коммитам. В конце «общий» коммит становится пустым, а каждый тематический содержит только свои правки.
Для больших фич это проще, чем блюсти дисциплину с самого начала. Проще делать черновики с отладочным кодом, а потом за один заход разложить всё по полочкам. Такой подход отличается от jj split: если при split забыли кусок, приходится делать ещё один split и squash, а здесь проще сортировать самые лёгкие куски в начале. Итоговый «общий» коммит не содержит конфликтов, в отличие от попыток подчищать по ходу дела, когда «фикс красного и зелёного» случайно ломает синий в том же файле. Минус — нет гарантии, что каждый коммит скомпилируется отдельно, что ломает git bisect и не нравится любителям отладки. В мире LLM-агентов, которые за 30 секунд чинят баги, размазанные по нескольким коммитам, это звучит менее критично.