Атомарность коммитов что предполагает? Оно говорит о том, что программист должен

не просто цель свою знать, но и разбить настолько свою работу, что получится набор небольших изменений. Но вот в этом то вся и загвоздка. Это не просто, это вынуждает очень тщательно продумать, как разбить на эти маленькие части.

Мне это не подходит. Мне куда проще: вижу цель, перед тем как продолжить программирование спрашиваю себя "А эта цель по прежнему важна?" или вдруг появились другие изменения ,которые делают цель не актуальной и ее желательно обдумать и актуализировать.

А уж далее не заморачиваясь о том, как эта цель будет достигнута просто пишу код. Пишу сразу, с первого раза и не парясь ни о чем хорошо, плохо, может через жопу. Я пишу первый код и отлично понимаю , что этот первый раз будет "в стол", другими словами, скорее всего то что я написал сейчас я сотру.

Таким образом я достигаю следующего:
* Не прокрастинирую!!! Когда слишком много ограничений, А "атомарность коммитов" это одно из ограничений. Мозг просто пишет! Пишет код
* Когда пишу код не заморачиваясь спотыкаюсь о проблемы, которые не были видны сразу - выписываю их
* Попутно вижу какие куски кода желательно обложить тестами - выписываю их

И только, когда задача решена. То смотрю, а насколько хорошо код написан? Если его можно зарефакторить и достаточно дешево, то делаю это. Тогда мне повезло и комичу код. Если же получился говнокод, то не парюсь и пишу второй раз и у меня уже получается хорошо, т.к. я знаю какие могут быть проблемы, где нужно пишу модульные тесты.

"Анархия – мать порядка! " :)

Да ;) Все так. Надо дать мозгу "творить", а творит он тогда, когда его не ограничивают, когда он фантазирует. Зачем его сдерживать? Пусть творит! ;) Программистам платят денег не за скорость разработки, а за : 0. За решение, которое просил бизнес, а не "а мне подумалось, что так будет лучше" 1. Решение готовое 2. Качественное решение 3. Решение в отведенные сроки

2 пункт не оплачивается, 3 – подразумевает организацию процесса. Так что, прежде чем резать, сначала отмерь. Выйдет и быстрее, и дешевле.

Оплачивается! ;) Если ты написал с багой, то скорее всего именно к тебе еще раз придут. Только тебе уже надо будет вспомнить что ты там делал, а это время

> 2 пункт не оплачивается Это не оплачивается деньгами в моменте, зато развивает навык, что позволяет в будущем находить более оплачиваемую работу. Считайте это инвестицией в себя и свое будущее.

Я именно поэтому и делаю кучу мелких коммитов, и группииую их по теме/модулям/етц, а потом уже логически разделяю если нужно

Если делать супер-атомарные коммиты, то в случае багов можно бисектом очень точно находить место регрессии. Некоторые участники чата делают компиляторы или что-то такое, и там дополнительные усилия на коммиты в прошлом с лихвой окупаются легкостью поиска регрессий. А вот в веб-разработке часто баги искать и править проще прям в кодовой базе, поэтому можно и не заморачиваться над коммитами.

Когда писал слова, что нужно время на поиск баги, то имел ввиду не само место, где сидит этот жук, а другое время. Время на загрузку контекста в голову. Исправляя код, мы ведь не беремся мгновенно фигачить. Мы вспоминаем как работает код, думаем как он работает. Думаем как он должен работать. Сопоставлем с задачей. Ищем расхождения. Все это занимает время. Поиск места в истории кода, когда возникла бага это не всегда самое сложное. Куда сложнее именно загрузить сам контекст работы кода в месте где обнаружена ошибка. Но, соглашусь, что есть польза в более мелких комитах