Problém vidím hlavne v tom, že čím viac vetiev, tým viacej mergovania. Mergovanie robí často niekto iný než samotný vývojár, a v prípade konfliktov by potom musel obiehať jednotlivých ľudí a riešiť ich s nimi. A čím viacej vetiev je medzi samotným commitom a výsledným mergnutým kódom, tým je to horšie. To je réžia navyše, ktorú sa snažíme minimalizovať.

Commity typu "idem si spraviť kávu" do feature repozitára vôbec nepatria, pretože také commity absolútne nikoho nezaujímajú. Taký spôsob práce môže fungovať leda tak vtedy, keď na jednej feature robí maximálne jeden vývojár. Ak má niekto potrebu také commity robiť, tak u seba lokálne si môže robiť čo chce, ale do feature repozitára musí komitovať ucelené zmeny. A toto je aj dôvod, prečo nie som zástanca squashovania (mimo lokálneho repozitára), kedy sa strácajú cenné informácie o tom, prečo sa nejaká zmena v kóde vlastne udiala a kto ju spravil.

S rýchlosťou hľadania problémov pomocou bisectu nie je problém, keďže naozaj nerobíme commity pri každom vstaní od klávesnice. A výsledok je aj u nás vždy jednoznačný, keďže robíme rebase a vďaka tomu máme lineárnu históriu. Nepotrebujeme "geniálne" commity, ich účel plní práve ten jeden merge commit. Čo potrebujeme, je história zmien, aby sme rozumeli tomu, prečo nejaký kód vyzerá práve tak, ako vyzerá.