Привет!

Сегодня решил поделиться полезняшкой - git worktree.

Эта команда позволяет добавить рабочую директорию для существующего гит репоза (ещё одну директорию с исходниками без собственной директории .git).

Это позволяет даже для больших проектов иметь пачку "репозов" и быстро переключаться между задачами. У меня как правило для каждого проекта есть пачка рабочих директорий:
1) main - для текущей задачи
2) hot-fix - для хот фиксов
3) по директории на каждого разработчика - для ревью
4) плюс частенько завожу ещё отдельные директории для различных экспериментов с кодовой базой.

#tools@ergonomic_code #git@ergonomic_code

Привет!

Полезняшка. А для кого-то может и целых три за раз:)

Если вы не знали - с одним гит-репозом можно использовать несколько рабочих деревьев. Которые будут разделять между собой директорию .git.
Это экономит место на диске (и время синхронизации в облако, если пользуетесь) и позволяет фетчить origin только один раз.

Я этим активно пользуюсь - у меня всегда есть ворктри для основной текущей задачи, для быстрых фиксов, и для ревью каждого члена команды. Соответственно между всеми этим активностями можно переключаться по щелку. И не чертыхаться каждый раз, что надо зафетчиться.

А ещё если не знали - для Gradle есть плагин, который позволяет закинуть в проект git.properties-файл с инфой о сборке (дата, ветка, тэг, автор и т.д.), который можно добыть в рантайме через Actuator.

Но есть была проблема - плагин не умеет в worktrees и по дефолту взрывает всю сборку при запуске из директории со вторичной копией.
Я года 4 хачил это комментированием плагина во вторчных директориях. И раза три это случайно коммитал и откатывал.

И вот наконец написал 8 строк, которые костыляют эту проблему аккуратнее

// build.gradle.kts

gitProperties {
    val dotGit = File(".git")
    if (dotGit.isFile) {
        val actualGitDir = dotGit.readText().substringAfter("gitdir: ").substringBefore("/worktrees")
        this.dotGitDirectory.set(File(actualGitDir))
    }
}

Важное уточнение - это именно костыль и в git.properties при этом попадут данные из основной рабочей директории, а не той, где была запущена сборка

#tools@ergonomic_code #tips@ergonomic_code #git@ergonomic_code

Привет!

Полезняшка.

Вы наверняка слышали, что коммиты в гите должны быть маленькими и сфокусированными.

Я про эту идею узнал лет 10 назад минимум. Но всё равно коммиты получались... сильно разные.
Думаю вы и сами прекрасно знаете как так получается - берёшься делать маленькую задачку в один сфокусированный коммит, но походу дела тут что-то подчистил, там что-то подравил, споткнулся о непредвиденное ограничение базового метода, который пришлось подрихтовать и от которого ещё 5 мест зависят и оп - к вечеру уже гора изменений в 30 файлах.

Я как-то пробовал всё равно такие пачки разбивать на коммиты, но тогда идея не умела сплитить чанки, а проваливаться ради этого в консоль не хотелось и если пытаться из горы изменений коммитать только какие-то части - всё равно в некоторых коммитах что-то забывал или добавлял что-то лишние и они получались нерабочие.

В общем я по этому поводу не парился и коммитался как получится.

А в прошлом году я узнал про The Mikado Method больших рефакторингов.
Суть идеи в том, что вы первым делом делаете целевое изменение, смотрите что ломается, откатываете исходное изменение, делаете следующее изменение, которое чинит поломку, смотрите что опять сломалось, откатываете второе изменение, делаете третье изменение и т.д.
Я попробовал эту штуку, но для меня это вышло как-то гемморойно.

Однако этот метод подтолкнул меня к версии создания сфокусированных коммитов, с приемлимым для меня кол-вом оверхеда и геммороя.
Выглядит он так:
1. пилите фичу до победного ваще не парясь про размер
2. шелвите всё что есть.
3. глазами просматриваете изменения в шелве выглядывая там сфокусированные коммиты и их примерный порядок
4. аншелвите изменения первого вспомогательного коммита, прогоняете тесты, коммитаете
5. повторяете п. 4 пока не закоммитаете все предварительные изменения
6. аншелвите изменения целиком (решая конфликты идеевской волшебной палочкой), ещё раз просматриваете, что там нет ничего лишнего и коммитаете финальный коммит
6.1 если нашли что-то лишнее - повторить с п. 2

Эта процедура в зависимости от тяжести случая занимает от 15 минут до пары часов, но даёт таки сфокусированные коммиты.

Это не то чтобы прям гениальное изобретение, но я 10 лет не мог додуматься - может кому-то сэкономлю пару лет:)

#tips@ergonomic_code #git@ergonomic_code