git – jak udělat commit dílčí změny (diskuse)

[jiwopene]

Toto používám celkem často (nadělám změny třeba ve více nesouvisejících souborech a až potom je po kouskách commituji). Pokud ale třeba mám necommitované změny a chci provést jinou, nesouviseící, změnu, tak používám git stash (uložení rozpracovaného stavu na zásobník, vrátí se to git stash pop) a commituji potom.

[Aleš Kapica]

Tak tohle je určitě dobré při práci. Mně se častěji stává – a netýká se to zrovna programování zdrojového kódu – že něco dělám, přijde někdo kdo mne vyruší s tím, že mám jít udělat něco jiného a pak už ten commit neudělám protože se k tomu nedostanu, nebo na to zapomenu. Když o nic nejde, commitnu to pak později i s jinými změnami. Také se mi nechce commitovat každou dílčí změnu. Dřív jsem to takhle dělal ale pak už jsem se ztrácel v tom, která změna byla ok, a která se ukázala jako slepá cesta.

[podlesh]

Proto zásadně používám PS1 se scriptem zobrazujícím stav git repository a pokud někde vidím že je cokoliv necommitnuto, tak nedělám další změny než provedu commit. I kdyby to mělo být jenom git commmit -a -m 'WIP'

[Aleš Kapica]

Bohužel, ne vždy realizovatelné. Nejsem vývojář co by se věnoval pouze prgání.

[kralyk z abclinuxu]

Já se stashování odnaučil a radši udělám nějaké WIP commity a pak si to přeházim/transformuju rebasem do správný podoby. Přijde mi, že Super jsou na tohle fixup commity (+ následně rebase --autosquash), akorát si člověk musí dát pozor, aby neopakoval stejnou commit message vícekrát, protože fixup commit se váže na commit message, ne na hash (což mi přijde jako blbý rozhodnutí, ale nic s tim neudělám).

git add -i je určitě fajn, ale git gui umožňuje stagovat s vyšší granularitou (jednotlivé řádky).

[kralyk z abclinuxu]

*Přijde mi, že stash zbytečně neumožňuje běžné operace jako branching atd.

[xxx]

protože fixup commit se váže na commit message, ne na hash (což mi přijde jako blbý rozhodnutí, ale nic s tim neudělám).

Protoze to ma implikace, ze pak musis umet ty fixup commity mit svazane s tim fixovanym, i kdyz udelas treba rebase bez toho autosqashe, atp. A muj tip je, ze kdyz se tim smerem vydas, tak skoncis zpatky ve stavu, ze ktereho si vysel. Ze nejjednodusi (mozna i jedinny) zpusob, jak toho dosahnout, je normalni commit se specialnim jmenem.

A trochu se obavam, ze neco podobneho by se ti stalo i s tim zasobnikem, kde by to vlastne bylo to same akorat by to byla fixup vetev.

[kralyk z abclinuxu]

Protoze to ma implikace, ze pak musis umet ty fixup commity mit svazane s tim fixovanym, i kdyz udelas treba rebase bez toho autosqashe, atp.

Rebase by to mohl celkem snadno umět aktualizovat, stejně už IIRC upravuje časový razítko u všech commitů... A u nějakýho jinýho způsobu úpravy historie by to bylo holt na tobě.

Ale souhlasim, že to je implementačně/koncepčně složitější...

[Michal Kubeček]

akorát si člověk musí dát pozor, aby neopakoval stejnou commit message vícekrát

Celý commit message stejný, to je při rozumně napsaných prakticky nemožné, pokud nejde o cherry pick. I úplně stejný subject je na pováženou, pokud je to v jedné sérii.

[kralyk z abclinuxu]

U finálních, slušně naformátovaných samozřejmě jo, měl jsem na mysli situaci, kdy mam rozdělanou nějakou práci lokálně a dělám commity á la "WIP něco něco", kde typicky tam dám jenom hodně stručnou sumarizaci, třeba jméno modulu/funkce apod., takže když pak pokračuju v tom samým, commit message má tendenci být stejný... takže tam dávám třeba číslo nebo něco...

[cezz]

Ja tieto ciastocne commity vyuzivam velmi casto - napriklad na to, ked chcem oddelit funkcne zmeny v kode od uprav citatelnosti do samostatnych commitov. Lahsie sa potom robi review PR.

A musim povedat, ze v tomto smere je Magit v Emacse naozaj magicky. Clovek poste v diff view vyznaci konkretne zmeny a stlaci stage. V tomto konkretnom pripade by bol napriklad problem s git add -i commitnut samostatne len niektore riadky z prveho hunku a asi by bolo treba pouzit git add -e, co uz zacina byt trochu komplikovane.

Neverim, ze niekto kto pouziva Emacs este o Magite nepocul, ale ak niekto uvazuje Emacs skusit, tak uz len pre ten Magit by som odporucal tomu dat sancu napriklad s niecim ako Doom Emacs.

[Michal Kubeček]

Musím se přiznat, že jakkoli pro tyhle účely většinou preferuji textové rozhraní, "git add -i" mi k srdci nepřirostl a i když jsem se mu párkrát snažil dát šanci, "git gui" je z hlediska uživatelského komfortu úplně jiná liga.

[Aleš Kapica]

Vzhledem k tomu že 90% času tohle potřebuji řešit na vzdáleném stroji s minimalistickou instalací, je pro mne cokoliv závislé na okením prostředí nepoužitelné.

Stejně tak nemám zapotřebí řešit jednotlivé řádky. Důležitý je pro mne commit komplexní změny. Situace že by se mi těsně vedle sebe sešly dvě různé věci, tak že by je bylo nutné separovat po řádcích, je pro mne velmi nepravděpodobné.

[Michal Kubeček]

90% času tohle potřebuji řešit na vzdáleném stroji s minimalistickou instalací

Pak je asi na místě otázka, jestli je rozumné ten git spouštět přímo tam. Já jsem třeba poměrně dlouho z lenosti z domova používal git na počítači v práci (včetně "git gui" přes "ssh -X") a teprve to, že jsem dočasně musel používat jiný VPN endpoint, a s tím související nárůst latencí mne donutil zařídit si to tak, abych tohle dělat nemusel. S odstupem času je to samozřejmě praktičtější, ale kdyby mne k tomu nedonutily okolnosti, nejspíš bych to tím krkolomným způsobem dělal dodnes.

Situace že by se mi těsně vedle sebe sešly dvě různé věci, tak že by je bylo nutné separovat po řádcích, je pro mne velmi nepravděpodobné.

Mně se to naopak děje docela často. Což ale možná souvisí s…

Důležitý je pro mne commit komplexní změny.

Commit by právě pokud možno moc komplexní být neměl. Naopak, měla by to být co nejmenší změna, která sama o sobě ještě dává smysl. Jak kdysi podotkl jeden maintainer, pokud píšete commit message a chystáte se začít větu slovem "Also", je to obvykle znamení, že byste měl commit rozdělit.

[Aleš Kapica]

Pak je asi na místě otázka, jestli je rozumné ten git spouštět přímo tam.

To teda rozhodně je Je to nejrychlejší způsob, jak zjistit jestli, nebo kdy někde nastala nějaká nežádoucí změna. Často toho využívám při dohledávání změn realizovaných někdy v minulosti.

[Aleš Kapica]

A komplexní znamená několik souvisejících změn na různých místech. Ne sadu různých, vzájemně nesouvisejících změn. Právě o tom, jak se tomu vyhnout, je tenhle blogpost.

[dolik.rce]

Vida, git add -i jsem ani neznal. Osobně používám git add -p (případně i s cestou), který spustí rovnou tu interaktivní "patchovací" část.

[ttttttttttt]

Používám https://github.com/bigH/git-fuzzy založený na fzf, výborný pokud jsou změny v různých souborech. Pro stejný soubor pak taky interaktivní git.