Me se naopak osvedcilo vic vetvi = min noveho kodu ve vetvi = meni problemy s mergovanim.
Hlavni vetve minimalne Master (v podstate ciste releasy), Devel (kde se schazi hotovy vyvoj a delaji kompletni testy a QA) pak feature vetve a (vetsinou z nich) bug vetve (resici nahlasene ci objevene chyby).
S tim, ze se vyssi vetev nejdriv mergne do aktualni, otestuje se (a pripadne opravi a znovu mergne ta vyssi) a pak se cela aktualni mergne do vyssi se --squash a dukladnym popisem (a nasledne se vetsinou zahodi a vytvori se nova)

Vysledek je, ze commity ve vyssich vetvich jsou ridke a "genialni" - proste kompletne resi dany problem a vypada to, ze se to povedlo napoprve dokonale - nejsou tam commity typu "jdu na obed", "X zacina chodit, ale Y se rozbilo", "Y uz zas chodi, ale X bude potreba strukturovat jinak s ohledem na Z" a podobne (protoze commit delam nejpozdeji kdyz odchazim od pocitace, ale casto i po kazdem uspesnem kroku (17 z 94) treba po 10 minutach) - po tydnu uz nikoho nezajima, jake preklepy jsem udelal rano a vecer opravil, kolikrat jsem prejmenoval promennou ci zmenil poradi deklaraci a podobne, ale ze "chyba #456 opravena" nebo "pridan export pro system XYZ"

Pak taky hledani problemu bisekci probehne rychleji, ale hlavne celkem jednoznacne (je to rozbite od "pridan export pro system XYZ" , nikoli ze chyba se vyskytuje v tomto useku asi tak v kazdem tretim commitu a ve zbyvajicich dvou ne, schvalne kam se trefite pulenim ...)