Git notes

Szerszám

Segédlet:

https://git-scm.com/docs/git-notes

https://tylercipriani.com/blog/2022/11/19/git-notes-gits-coolest-most-u…

( OnlyZaenae | 2025. 07. 28., h – 13:02 )

Arra szavaztam, hogy Sose használom. Bár, nagyüzemi szoftvergyártásnál, vagy csak simán webes felületben elrejtve előfordulhat, hogy mégis csak használtam, tudtomon kívül.

Még nincs aláírásom.

( dotnetlinux | 2025. 07. 28., h – 17:52 )

Elég gyakran csinálok értelmes commit message-et, ritkábban értelmes PR/MR leírást, notes-ot még az életben soha.

Nem így van; a `git-notes` briliáns eszköz levlista-alapú fejlesztéshez. (Az más kérdés, hogy levlistákkal egyre ritkábban találkozni, de ettől még a use case létezik.)

Tipikusan akkor használjuk, amikor egy patch set-ből v1, v2, v3, ... vn változatot küldünk be, a bírálatokra reagálva. A beküldő a git-range-diff paranccsal összehasonlítja a legutóbbi (v(n-1)) és a legfrisebb (v(n)) verzióját a patch set-nek (development branch-nek), amely kijelzi mind a patch set szerkezeti változásait (patch-ek sorrendjének megváltoztatása, új patch-ek beszúrása, régi patch-ek kiesése), mind az egyes patch-eken belüli változásokat (interdiff formátumban, amit meg kell tanulni olvasni). A fejlesztő pedig ennek megfelelően patch-enkénti changelog-ot tart naprakészen, git-notes-szal. A git-rebase támogatja a git-notes-t, tehát új patch set version összeállításakor az egyes patch changelog-ját csak ki kell terjeszteni a tetején. A git-format-patch szintén támogatja a git-notes-t; a levlistán megjelenő patch email-eknek van egy dedikált szekciója, amelyben ez a changelog megjelenik. Rendkívüli mértékben támogatja az inkrementális review-t, úgyhogy az egyik legjobb eszköz.

A fenti interakcióban mind a bírálók, mind a beküldők jellemzően a patch set összes változatát megőrzik, külön branch-eken; a bíráló is a git-range-diff-et futtatja inkrementális review-hoz, lokálisan, és ehhez használja támogatásnak a levlistán olvasható, patch-enkénti "notes" szekciót. A git-am parancs (amellyel lementett email-ekből tudjuk az új verziójú branch-et felépíteni) szintén ismeri a "notes" szekciót, és átugorja.

Ezeket a patch-enkénti changelog-okat kifejezetten nem a commit message részeként akarjuk megtartani; amikor a végső változatot beolvasztjuk, akkor ez a changelog nem kerül a commit history-ba. A levlista archívumában megmarad, ha valakit érdekel (gyakran releváns tud lenni, igen).

A git-range-diff másik óriási előnye, hogy nagyon jól ellenáll ("reziliens") annak a helyzetnek, amikor egy rebase olyan master branch-ra történik, amelynek időközben elmászott a HEAD-je. Ilyenkor egy kumulatív git-diff szinte teljesen haszontalan, egy git-range-diff viszont zseniális.

A github-on és gitlab-on nevelkedett (vagy más szóval: satnyult) generációk ezt sajnos nem értik, nem is érthetik (nem az ő hibájuk), mert ezek a WebUI-k eleve nem támogatnak inkrementális review-t (tömören: olyan patch-enkénti összehasonlítását egy patch set két szomszédos verziójának, amelyet a git-range-diff végez). Így számukra értelmezhetetlen mind a patch-enkénti changelog, mind az interdiff formátum, mind (ennek folyományaként) a "notes" szekció, vagy maga a git-notes parancs.

A github egyik legnagyobb emberiség elleni bűntette a squash-on-merge bevezetése (mert arra neveli a fejlesztőket, hogy ne strukturálják a patch set-jeiket, miközben a patch set sorrendisége kritikus kommunikációs eszköz). A másik az inkrementális bírálat hiánya. A harmadik pedig az, hogy egy PR frissítéséhez ugyanazt a branch-et muszáj frissíteni (push vagy force-push), anélkül, hogy lenne automatizmus a branch korábbi változatainak megőrzésére, minimum addig, amíg a PR-t be nem olvasztják. Ez ugyanis azt jelenti, hogy aki pl. a harmadik vagy negyedik változatnál kapcsolódik be a review-ba, nem tudja áttekinteni a korábbi patch series változatok közötti strukturált változtatásokat, még akkor sem, ha hajlandó lenne a régi branch változatokat fetch-elni, és lokálisan git-range-diff-et futtani. Ugyanis nincs mit letölteni. Én már megtanultam, hogy minden branch változatot azonnal lehúzok lokálisba (amikor még friss -- akkor még le lehet), és ráragasztok egy verziózott lokális branch nevet. Így a patch set evolúciója legalább nálam megvan, amíg a review be nem fejeződik.

Egy szó mint száz, a github és tsai iszonyatos pusztítást végeztek a contribution/review workflow terén. Természetesen én sem tudom elkerülni a github-ot; bizton állíthatom, hogy olyan érzés a használata, a patch beküldős levlistákhoz képest, mintha a csukóim és a bokáim a hátam mögött gúzsba lennének kötve.

(Szerk. néhány typo/thinko javítása.)

End of rant.

... Ha már belekezdtem a github kritizálásába, ne feledkezzünk meg arról sem, hogy teljesen rossz a bírálati / kommentálási adatmodellje is: a bírálói kommenteket nem adott patch set verzió adott patch-ének adott sorához fűzi, hanem a kumulatív diff adott sorához, és ezeket a kommenteket valamilyen nyomi heurisztika alapján a következő (vagyis git push (--force) utáni) patch set verziókra is igyekszik átvinni. Ez nyilván teljesen abszurd, a v1-re, v2-re adott kommentek többnyire teljesen értelmetlenek a v3, v4 stb tekintetében, ráadásul a kommentek megjelenítéséből nagyrészt lehetetlen kideríteni, hogy most akkor pontosan melyik patch-en is kellene javítani, a komment megoldásához (ez egyáltalán nem vicces, amikor tizen-huszon patch van egy sorozatban). Tökre látszik ebből is, hogy a github tervezői nem fogták fel (vagy ami rosszabb: elvetették) azt a koncepciót, hogy egy patch series-en belül a patch-ek tagolása, sorba rendezésbe kritikus fontosságú kommunikációs eszköz, és ha egy adott patch-ból legvégül fennmaradó (= a kumulatív diffben is látszó) sor problémás, akkor azt az érintett patch-en belül (tehát akár a series közepében is) javítjuk. Addig terjed a képzelőerejük, hogy "oké akkor itt a kumulatív diff, oszt ez a sora meg az a sora nem jó, taknyold át valahol".

És persze mi sem természetesebb, hogy ez a probléma a levlista-alapú munkafolyamatnál nem létezik, ugyanis az egyes patch email-ek szépen be vannak tagolva (mintegy válaszokként) a cover letter alá (amit minden értelmes MUA jól mutat threaded view-ban); a review kommentek pedig ezekre a patch email-ekre vannak válaszként elküldve, megfelelő idézéssel és beszúrkodással. Ezek a kommentek tökéletesen verzióhoz és helyhez vannak kötve, és a következő változat review-jánál referenciaként használhatók; le lehet ellenőrizni, hogy a beküldő minden feltárt problémát kijavított-e.

A git toolkit és az email alapú patch-csere egy közel hibátlan rendszert, "ökoszisztémát" alkotott, amelyet a web 2.0 fostengere és apokalipszisa sajnos minden fronton egyszerre tett tönkre (gmail és általában webes email felületek, top posting, helytelen idézés, levlisták üzemeltetésének megnehezítése, github, etc etc etc).

Hűha, belejöttem: a patch-ek sorba rendezésénél (mint említettem) az egyik elvárás (illetve haszon) az, hogy a reviewer számára logikusan, atomi lépésekben fel tudjuk építeni a bugfix-et vagy feature-t; a másik (vagy "egy másik") elvárás pedig az, hogy a projekt a branch-nak minden egyes patch-énél kicsekkolva lefordul, és kielégíti a teszteket. Ezt nyilván beküldés előtt a fejlesztőnek le kell ellenőriznie; többnyire valamilyen "git rebase --exec ..." paranccsal. Ennek a haszna pedig az, hogy amikor -- nem "ha", hanem "amikor" -- fél évvel később rájövünk, hogy valamit elcsesztünk, mert regresszió van, akkor a git-bisect parancs nem egy ötezer vagy hétezer soros commit-ot dob végül a fejünkre (amiben aztán kereshetjük a hibát vakulásig), hanem egy pár tíz, max. 1-2 száz soros commit-ot, amit célzottan átolvasva már jó eséllyel ki is ugrik a hiba. Ennek feltétele pedig az, hogy kicsi, atomi commit-okat írjunk, és minden commit forduljon. (A git-bisect nem tudja a fát olyan commit-nál tesztelni, amit nem tud lefordítani.) Na, ezért is gyalázat a squash-on-merge.

anélkül, hogy lenne automatizmus a branch korábbi változatainak megőrzésére

A branch csak egy "alias", pontosabban egy pointer egy commitra. Minden commit megőrződik, bármikor mondhatod azt, hogy az x1 commit az az y branch v1 változata, az x2 commit meg az y branch v2 változata. Szóval a branch korábbi állapota mindig megőrződik, maximum nincs rá automatikusan alias, de erre csinálhatsz bármikor hookot és megcsinálja automatikusan.

A git tag is csak egy alias egy commitra. 

https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell

A branch in Git is simply a lightweight movable pointer to one of these commits.

https://git-scm.com/book/en/v2/Git-Basics-Tagging

Git supports two types of tags: lightweight and annotated.

A lightweight tag is very much like a branch that doesn’t change — it’s just a pointer to a specific commit.

A tag-eknek van még egy(-két) huncutsága, amelyekből a másodikra most nem emlékszem pontosan, de arra emlékszem, hogy korábban (többször is) belebotlottam.

Az első huncutság az, hogy a tag-ek nem repo- (= nem remote-) specifikusak, mint a branch-ek. Ha van két remote-ot egy local clone-ban, akkor mindegyik remote-nak lehet azonos B nevű branch-e, amelyek tudnak tök máshova mutatni. A tag-ekre ez -- tudtommal -- nem igaz; ott egyetlen közös névtér van. Ezért is szoktam nem-kanonikus remote-okat mindig a "--no-tags" opcióval klónozni, illetve (a "git remote add -f" paranccsal) létező helyi klónhoz hozzáadni -- nem akarom, hogy "beszennyezzék" a kanonikus repo tag-névterét. (Megfigyelhető, hogy azok a kanonikus repo-k / remote-ok, amelyeknél tervezett, hogy a fejlesztők egyazon helyi klón-on belül többet is használjanak belőlük, ügyelnek arra, hogy valamilyen tag-elnevezési konvencióval az ütközéseket elkerüljék. Pl. mainline és stable fák között a "git cherry-pick -x" nagyon hasznos, és mindegyik ilyen fa használ tag-eket; nekik muszáj figyelni arra, hogy a tag-ek ne ütközzenek.)

A második huncutság valahol a push vagy a pull környékén volt. Úgy rémlik, hogy klónoztam egy repo-t, amiben voltak olyan tag-ek, amelyek nem voltak egyúttal valamely branch-en is. A git clone csak a branch-eket hozta le (mint symbolic ref-eket), illetve (természetesen) a gráf mindazon részét, amely ezekből a branch-ekből elérhető volt; a tag-eket viszont (és a gráf azon részét, amely csak a tag-ekből volt elérhető) nem töltötte le. És ha jól emlékszem, ez nem a "--no-tags" következménye volt... de már homályos.

en szemely szerint a git submodule-lal allok ilyen felemason.

Valahogy nem lehet ertelmesen adott git projekt branchere iranyitani, csak egy adott commitra vagy a main(?) branchre.

 

Szóval csinalsz egy hibajavitast egy olyan projektben ami submodulet hasznal, es le kell nyulni egyik submoduleba ott is hobajavitabi. Ezt normal esetben egy sajat branchben intezned, de ultraszopas a git submodul.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

A submodule-ok tényleg vérverítékesek, de azért valamivel jobb a helyzet. Meg lehet azt jelölni, hogy a superproject a submodule-nak egy adott branch-ét kövesse, és akkor a "git submodule update --remote" onnan fogja lehúzni az újdonságokat. Sőt, van arra is szintaxis, hogy ha a superproject-ben a B nevű branch-en vagy, akkor automatikusan az adott submodule-nak is a B nevű branch-ét fogyasszuk. gitmodules(5):

submodule.<name>.branch

A remote branch name for tracking updates in the upstream submodule. If the option is not specified, it defaults to the remote HEAD. A special value of . is used to indicate that the name of the branch in the submodule should be the same name as the current branch in the current repository. See the --remote documentation in git-submodule(1) for details.

Így azért kellemesebb (de azért így is nagyon kényelmetlen, valóban).

Minden commit megőrződik

Ez nem így van. A git elvileg bármikor eldobhat minden olyan commit-ot, amely a commit gráfban egyetlen symbolic ref-ből (branch-ből, tag-ből) sem elérhető, parent pointer-ek mentén. Lásd "git gc [--prune]". Ha nem így lenne, akkor a repo-kban a hulladék mennyisége korlátlan lenne; a git-rebase és a non-fast-forward push rengeteg orphan commit-ot generálnak; ezeket időnként el kell takarítani. Természetesen a garbage collection nem azonnali; az nem lenne hasznos.

(Jó példa a késleltetett szemétgyűjtés hasznosságára a "git reflog --date=local BRANCH". Ha elrontasz egy rebase-t, de úgy, hogy be is fejezed (tehát a branch "át is áll"), akkor még egy ideig a branch-et "git reset --hard"-dal vissza tudod irányítani a branch egy korábbi változatára, amit a git-reflog-ból tudsz esetleg kinézni. De a szemétgyűjtés ritkasága nem garantált; elvileg semmi nem zárja ki, hogy egy cron job naponta futtasson a nagy repo-kon git-gc-t.)

A másik ellenvetésem az, hogy a commit hash-ek (az élettartamuktól függetlenül) nem beszédesek; sokkal beszédesebb, ha "feature-v1", "feature-v2" stb hivatkozásaink vannak.

erre csinálhatsz bármikor hookot és megcsinálja automatikusan

Ez mondjuk jó ötlet!; nem gondoltam rá.

githubon ha rebase-elsz egy branchet, vagy barmi modosult akkor lesz egy ilyen sorod a PR-ben

tenstad force-pushed the sftp branch from 9b9a13d to 0828535 3 months ago

es a ket hash kattinthato marad. tehat a github ha nyom is gc-t akkor az ilyen hivatkozasok megmaradnak

 

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Ez ugyanis azt jelenti, hogy aki pl. a harmadik vagy negyedik változatnál kapcsolódik be a review-ba, nem tudja áttekinteni a korábbi patch series változatok közötti strukturált változtatásokat

Dehogynem. A Github felületén tök jól látszik az, hogy hogyan fejlődött egy branch. 

Hogy egy példát mutassak: https://github.com/openjdk/jdk/pull/26504/files

Ez egy olyan PR, amihez négy kommit volt.

Itt baloldalt fent láthatsz egy lenyílót: Changes from all commits vagy éppen adott commit változásai. Külön eset a "Show changes since your last review", de commitonként is megnézheted a változásokat.

Hogy ez a változat hogyan alakult ki, irreleváns.

Abszolút nem értek veled egyet; a PR végterméke, végeredménye nem egy lenyomat (nem a fa állapota az utolsó commitnál), hanem a commit history-nak egy szakasza (esetleg részgráfja). A kódot (és a kommenteket és a commit message-eket) elsősorban emberek közötti kommunikációra írjuk; az mellékes, hogy a gép futtatni is tudja. (Sarkítok, de érted, mire gondolok.) A PR végterméke az, hogy az egész gondolatmenet, aprólékosan, fokozatosan felépítve, megmarad a commit history-ban. Ha van egy hiba a kódban, amely egy olyan téves elgondolásból származik, amely a patch set közepét érinti, akkor a javítás nem az, hogy a végére rádobjuk a fixet (azért, hogy te könnyen megnézhesd azt az 1 dolgot), hanem az, hogy a patch set közepén kijavítjuk a hibás patch-et, frissítjük hozzá a commit message-et (amelyben a téves elgondolás szerepel), kiegészítjük az adott patch changelog-ját. Ezután a reviewer megnézi az egész új patch set verziót inkrementálisan (git-range-diff-fel). Nemcsak azt fogja látni, hogy a végső kód, a végeredmény (ami futni fog) jó, hanem azt is látni fogja, hogy a patch set közepén, az eredeti helyén, a gondolati hibát kijavítottuk. Az adott patch előző és mostani változatát összehasonlítva (ami egy interdiff) a reviewer látni fogja a commit message, esetleg a commit subject (!) változását is -- a github képtelen commit message-eket összehasonlítani, ami pedig nagyon nagy hiba; szerk.: hasonlóan, nem enged a commit message-hez kommenteket fűzni --, és persze azt is, hogy a patchen belüli változás hogyan változott meg. Ha úgy tetszik: második deriváltat néz.

Igen, de (ld. a másik válaszomban) itt az a döntő, hogy az a másik honnan használta fel a hibás commit-ot. Ha a master branch-ről, akkor joga van elvárni, hogy csak fast-forwardable mozgást lásson a HEAD-en. Ha bárhonnan máshonnan vette a hibás commit-ot, akkor magára vessen. A projektben van egy megegyezés, hogy mi számít a fejlesztői gárda számára publikáltnak, "nyilvánosan közöltnek". A non-ff rebase ill. push olyan branch-eken lehetséges, amelyek nem számítanak közöltnek.

az a másik honnan használta fel a hibás commit-ot.

Teljesen mindegy. Nem a commit hibás, hanem a kód. Az, hogy az a hiba melyik commitban került bele a kódba, a hibajavítás szempontjából teljesen mindegy, ki kell javítani. Abból a szempontból nem mindegy csak, hogy értesíteni kell a felhasználókat, hogy az X.Y.Z. verzió óta hiba van.

A projektben van egy megegyezés, hogy mi számít a fejlesztői gárda számára publikáltnak, "nyilvánosan közöltnek".

Ezt nem igazán értem. Minden commit nyilvánosan közölt azzal a repoval, ahova pusholod.

A PR végterméke az, hogy az egész gondolatmenet, aprólékosan, fokozatosan felépítve, megmarad a commit history-ban.

De hát ez csak annyit jelent, hogy a PR egy külön branch, aminek ott a commit historyja. És merge után nem törlöd ki a branchet. Ennyi az egész, megmarad az egész gondolatmeneted.

Ha van egy hiba a kódban, amely egy olyan téves elgondolásból származik, amely a patch set közepét érinti,

Nincs ilyen, hogy a patch set közepe. Maximum az, hogy a PR-ban többféle funkcionalitás van, amelyek a PR-on belül külön életet élnek.

Csinálhatod azt, hogy van egy PR branched, és ebből a PR branchből te még ágaztatsz le "patch" brancheket, amiket a PR branchbe mergelsz be, amikor az a rész készen van és már nincs benne hiba.

Szóval valahogy így:

1. mastert leágaztatod a PR-odhoz, legyen a neve pr-foo

2. A PR-ban, mivel több patched is van (patch set), minden egyes patchhez létrehozol egy branchet. Azt a branchet reviewzod, commitolsz oda, hívhatod ezeket a brancheket úgy, hogy pr-foo-patch-bar

3. Ezeket a pr-foo-patch-x brancheket mergeled folyamatosan a pr-foo branchbe. Megmarad minden kommit a pr-foo-patch-x brancheken is.

4. Amint a PR branchbe minden patch branch bekerült, akkor a PR branch bekerülhet a masterbe.

A reviewerek mindig megnézhetik a pr-foo-patch-x brancheket, és reviewzhatják azt.

Az egész csak annyit jelent, hogy a fejlesztés során hány különálló életet kódrészed van, mindegyik megérdemel egy branchet. Az, hogy ez a branch miből származik (a masterből, PR branchből, vagy éppen a patch branchből is - ha esetleg szükség van rá), az a fejlesztői folyamat része.

De git szintjén csak branchek kellenek és kész. És semmilyen historyt nem kell újraírni, soha.

Az azért előfordulhat, hogy egy PR mondjuk több modult/alrendszert érint egy komplex kódbázisban, és a változásnak együtt van értelme.
Főleg egy monorepo stílusú fejlesztés esetén igaz ez. A monorepo sokszor kényelmes, de azért vannak kényelmetlen dolgai is.

Ott mondjuk egy PR-on belül lehet az, hogy module1 és module2 is módosul, akár pont azért, mert a teljes funkcionalitáshoz az kell, hogy mindkét modul funkcionalitása módosuljon.

Nincs annak értelme, hogy feladsz egy PR-t a module1 módosítására, meg egy másikat a module2 módosítására, hiába különálló modulok, a funkcionalitásnak együtt van értelme.

És akkor csinálsz egy PR-t a hozzá tartozó PR branch-csel, amiből még leágaztathatsz egy pr-patch-module1 meg egy pr-patch-module2 branchet, azt fejleszthetik a megfelelő module1 és module2 felelősök.

De ez az egész már inkább projektszervezési dolog és nem a git mint eszköz által diktált jellegzetesség.

A git egy technikai eszköz csak a fejlesztés támogatására, a feladata ezt a projektszervezést támogatni, és a git ezt kiválóan támogatja a branchekkel, másra nincs itt szükség, pláne nincs szükség a history módosítására soha.

Ez egy olyan PR, amihez négy kommit volt.

Igen, és már itt látszik a baj: a negyedik commit egy olyan hibát (missing EOF) javít, amit a harmadik commit vezetett be. Ilyenkor nem a tetejére dobunk rá egy fixupot, hanem megjavítjuk a harmadik patch-et, és az egész branch-et újra feltoljuk. (Az a tény, hogy itt ez az eljárás eleve a v1-en belül történt (vagyis hogy a "tetejére dobott fixup" már a legelső push-nak a része volt), számomra még inkább elfogadhatatlan. Ki a csuda tol fel úgy egy patch series-t, hogy saját maga is tudja, hogy egyes patch-ek a sorozatban félkészek, hibásak?)

Changes from all commits

Igen, ez a kumulatív diff; áttekinteni hasznos lehet, kommentáláshoz nagyrészt haszontalan, mert nem követi azt a vonulatot, evolúciót, ahogyan a végállapot kialakul.

Show changes since your last review

Ilyet még nem láttam, és (mivel ezen a PR-en nincs több, külön push / review) itt nem is tudom megnézni.

commitonként is megnézheted a változásokat

A fő kérdés az, hogy a legutolsó review óta és commit-onként láthatom-e a változásokat. Igazából engem nem a git diff érdekel, mert nem (csak) a kód változása érdekel. Engem az egyes patch-ek változása érdekel (diff-ek diff-je --> interdiff).

Igen, és már itt látszik a baj: a negyedik commit egy olyan hibát (missing EOF) javít, amit a harmadik commit vezetett be.

De honnan tudod*, hogy a harmadik commitnál nem csinált valaki egy branch-ot, nem volt release (ha releasable branchen vetted észre a bugot, nyilván), stb.? Olvasva a kommentjeidet, (nyilván látatlanul) arra tippelnék, hogy túl hosszú életűek a feature branchek azokban a projektekben, amiben dolgozol. 

* Értelemszerűen egy kis projektnél beleférhet, de ahol több ember dolgozik együtt, ott nem véletlenül tilos például a force push. 

De honnan tudod*, hogy a harmadik commitnál nem csinált valaki egy branch-ot, nem volt release (ha releasable branchen vetted észre a bugot, nyilván), stb.?

Onnan, hogy a feature branch-et még nem merge-elték a master branch-be. Nyilván a master branch csak előre megy! De amíg egy feature branch különféle verzióin dolgozik az ember (hogy úgy mondjam: egy egyszemélyes branch-en), addig annak a branch-nek a verziói között bármi előfordulhat.

Másként kifejezve: a history megváltoztatása addig járható út, amíg a bírálat folyamatban van (akár a feature branch több verzióján átívelve is). Onnantól, hogy a teljes sorozatot jóváhagyta mindenki, akinek kellett, onnantól jön a merge, és akkor véssük kőbe a commit-okat. Ha ezt követően veszünk észre hibát valamelyik patch-ben, akkor természetesen már külön patch kell a javításához. Lényegében a master branch-en való megjelenés az az aktus, amitől egy commit read-only-vá válik, mivel akkor már a "világ" fetch-elhette. A master branch a publikációs csatorna. Amíg csak egy személyes feature branch-ben van egy commit, addig nincsenek stabilitási garanciák.

hogy túl hosszú életűek a feature branchek azokban a projektekben, amiben dolgozol

Ezt nem mondanám; az viszont igaz, hogy a branch-ek, amelyekről beszélek, egyszemélyi kontroll alatt állnak.

ahol több ember dolgozik együtt, ott nem véletlenül tilos például a force push

Ezzel teljesen egyetértek; ahol már 2 ember dolgozik egy feature-ön, ott már kettejük között is kell koordinálni (erre valók pl. a linux tematikus / alrendszeri levlistái, sub-maintainer-ei). Az alrendszer központi branch-én / fájában játsszák azt, ami kisebb projekteknél a main branch.

... Érdekes; úgy látszik, hogy én feltételeztem egy olyan kontextust ebben a beszélgetésben, ami nem általános. Azok a branch-ek, amelyekre gondolok, pár hetes, kivételesen esetben pár hónapos kort érnek meg (beleértve az összes verziót), és univerzálisan egyszemélyi kontroll alatt állnak. Egy néhány tíz patch-ből álló branch már nagynak számít.