но в основную ветку, конечно, коммиты должны идти работоспособными, чистыми, без console.log-ов, с тестами и т.д

Ну в своей ветке тоже удобней делать коммиты после какого-то более-менее рабочего куска

Git тебя не заставляет заморачиваться по поводу чистоты твоего кода - это твоя обязанность следить за этим.

Прочитай ці два стайлгайди, я думаю вони покривають 90% загальноприйнятих практик, які тобі треба знати.

https://github.com/agis/git-style-guide
https://github.com/pagarme/git-style-guide

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

2. Гигиена. Код коммита отформатирован, соответствует стилю, проходит проверки линтера и тесты, если это есть. В коде нет лишнего - каких-то временных логов, неудавшихся экспериментом, закомментированных кусков кода и тд

3. Описание коммита: одна строка что он делает. Если надо, то после пропущенной строки пишешь, почему решал задачу так, а не иначе. У меня бывают коммиты в 1 строку кода с длинным пассажем почему так надо.

4. Поскольку эти все моменты бывает сложно отслеживать руками, на практике применяют то, что называется git hooks. Перед коммитом git запускает хук, который делает за тебя автоформатирование, прогон тестов и тд

5. Git - система с изменяемой историей. Если сделал коммит, и он тебе по какой-то причине не нравится, его всегда можно исправить. Добавить-удалить изменения в коде, поменять описание, разбить коммит на несколько или наоборот соединить несколько коммитов в один.

6. В каждой компании / команде могут быть свои правила и процессы по ведению разработки в гите. Некоторые относятся к этому очень строго, некоторые нет. Есть куча инструментов, которые в этом деле помогают. Знать их не обязательо, но полезно.

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

+

спасибо за подробный ответ

и тут приходят адепты сингл комит пул реквестов )

все что я написал, справедливо и для них. Делаешь один классный коммит, сразу в PR.

завжди можна засквошити

со сквошем как раз теряется красота атомарных комитов, когда у тебя изменения прокомментированы комитами - можно глянуть блейм и посмотреть почему было сделано конкретное изменение, а не общий текст "addes some big feature"

Комментарии к коммиту не теряются, если их писать перед тем как мержить

будет один большой коммент, что не очень удобно

Ведёшь разработку, мусоришь, когда готов, делаешь у себя сквош и при сквоше уже комментарии со всем

Если ПР делает больше чем нужно, разбить на два/три/четыре

ну поэтому для таких вещей rebase and merge и несколько коммитов в мастере

у нас это режим по умолчанию

И каждый из них будет отдельным коммитом с историей

ще така штука, що я зазавичай перед комітом проходжусь по всіх файлах, які в мене змінені, переглядаю їх і обираю конкретні файли чи змінені фрагменти і додаю їх в коміт
тобто комі — це не обов'язково все що змінено, можна лиш частини
для прикладу, якшо в тебе є якийсь тестовий код, з яким ти будеш зараз продовжувати працювати, то його можна не додавати в "stage", тому що тобі він може бути потрібний й надалі, а вже хочеш запушити коміт, шоб
а) мати бекап своєї роботи у віддаленому репозиторію
б) щоб твої колеги вже могли дивитись на всі твої зміни
в) поставити таку невеличку "крапку" в якійсь конкретній проблемі, яку вирішує той чи інший коміт

твоя задача може мати багато складових, часто коміти можуть бути якраз цими точками між ними

А яку тривалість циклів ти радиш? Я знаю є люди які комітять кожні 5-10 хвилин і прямо в мастер.