TortoiseGit linuxos alternatívája

Fórumok

Létezik ekvivalens funkcionalitású alternatívája a Tortoisegit -nek Linuxon? 

Értem ezalatt jobb kattintásos file manager integrációt a következő funkciókkal: Clone, pull, commit, push, sync funkciókon túl Diff valamilyen winmerge linuxos alternatívával, pl Meld vagy Kdiff3. Illetve log history, branch kezelés. 

Hozzászólások

Szerkesztve: 2023. 03. 31., p – 14:51

Git Cola, Git Kraken, SmartGit mind elég jónak tűntek, amikor néztem (és tudják ezeket).

dolphin-plugins telepítés, context menu beállításokban git engedélyez

Ezekhez a parancsokhoz egy parancssor is bőven elegendő...

Mondjuk a filekezelő integráció pont nem érdekel engem, de speciel commitok rendes összerakásához egy guis eszköz, ahol össze tudod kattogtatni, hogy melyik chunkok menjek a commitba, az igen hasznos. Azt biztos lehet cliből is csinálni, de elképesztő mazohizmusnak tűnik.

Szerintem meg csak azt segiti elo, hogy legyenek mukodeskeptelen senki altal egyszer sem futtatott buildek/commitok. De van a ritka cherry-pick orientalt eloregondolas, amikor ez hasznos, de ez nem kene mindennapi git hasznalat resze legyen.

Ezenkivul ha abba a toolba bug kerul, senkinek el nem magyarazod rendesen, hogy mi tortent.

Egyszer az IntelliJ hiresen jo es aranylag teszteltnek minositett 3 way merge tooljaval nagyon megszivtam 8 eve: a "cancel" gombtol azt vartam volna hogy ott fogok tartani ahol akkor tartottam, mielott megnyitottam. Helyette mindket conflictolo branch valtozasait eldobta.

Elotte is tobbnyire parancssorrol giteztem, azota ala is huzom, hogy ez a helyes viselkedes. Sajat/kozeli kollega altalad is ertett bash scriptjet hasznalni git write-ra oke, a tobbi idozitett bomba.

Szerintem meg csak azt segiti elo, hogy legyenek mukodeskeptelen senki altal egyszer sem futtatott buildek/commitok. De van a ritka cherry-pick orientalt eloregondolas, amikor ez hasznos, de ez nem kene mindennapi git hasznalat resze legyen.

Elsőre lehet így tűnik, de igazából csak azért, mert cliből ember nincs, aki megpróbálná rendbeszedni a commitjait. :P

Viccet félretéve, szerintem a git history alapvető célja, hogy a jövőben értsd, mi és miért történt, szóval jó, ha szép rend van benne, fel van darabolva érthető részekre Nyilván workflowfüggő, de azért az a jellemző, hogy az ember nekilát egy feladatnak (jellemzően mondjuk egy feature branchen). Fejleszt, annak is lesznek darabjai, meg közben kiderül, hogy ezt-azt át kell kicsit alakítani, esetleg még meg is javítunk öt kicsi bugot, ha már arra jártunk. És még ha nagyon ügyes gyerek vagy, akkor sem fog ez elsőre teljesen szépen menni, de inkább az a jellemző, hogy az ember valamennyi haladvány után összerendezgeti commitokba, amit csinált. Ebben a folyamatban pedig nagyon hasznos egy jó kis céleszköz, ahol látom, hogy na, akkor most összekattogtatom ami mondjuk x fgv szignatúrájának megváltoztatása miatt volt, aztán y-t, aztán z-t. Ennek a folyamatnak az eredménye szokott aztán általában egy normális, érthető history lenni, amit sokkal könnyebb reviewzni, meg később is gyönyörűen látszik, hogy mi a fenéért került oda, ami odakerült.

Persze előfordul bizonyára néha, hogy valami nem teljesen kerek, ezért van benne olyan commit, ami éppen nem futna, vagy el volt rajta törve 2 unittest. De őszintén, amíg egy feature branch headje jó (márpedig az jó lesz) addig ez bőven jó kompromisszum.

Ráadásul ha nem így csinálod, se sincs ez feltétlen másképp, ott is simán előfordul, hogy nem minden commit mellett jók akárcsak a unittestek sem, nem beszélve mondjuk az integrációsokról. (Hovatovább, ez simán nem is elvárás feltétlenül).

A cherry pick meg nem tudom hogy jön ide, de az attól nettó lábrázást kapok. Néha muszáj, de kurva idegesítő, hogy nem látszik a gráfban.

Hat ez nagyon szepen hangzik.

De kozben a valosag:

git commit -am 'checkpoint as need to change branch for another more urgent fix'

Aztan ennek a rendbeszedese meg valakinel elmarad, valakinel meg nem ez lesz az egyetlen mukodeskeptelen commit, ahogy varnad. A ketto kozti atmenet ritka sajnos, de az elmeleti lehetosege jol hangzik.

Egyik elmeletem szerint azert ment a vilag az amugy szinten problemas (csak maskepp) microservice-ek vilagaba, mert monolithok karbantartasanal mindig mindenki osszeveszett a tobbi fejlesztovel a git workflowjan.

Hát, nálunk ez pl kb így megy, és tapasztalataim alapján nem egyedi eset. Ha nálad ez a valóság, akkor engedd meg a világ többi részének, hogy ne kelljen nekünk ilyet ne csinálni azért, mert a te valóságod egy kupleráj, ahol hiányzik bármiféle elemi kontroll a processzekből.

Hany fos a csapat?

Mindenki egyetertett a dontessel?

Szerinted ez 100-200 fos csapatban is elvarhato, hogy az emberek szetszedegessek a commitjaikat? Kiutazol majd Mumbaiba es elmagyarazod egyesevel minden fejlesztonek? :)

Elhiszem, hogy nalatok mukodik.

De nem varhatod el, hogy mindenhol mukodjon, es muszaj definialnod mukodest olyan esetekre, amikor emberek nem tudnak annyit a gitrol.

Es kezdetnek batortalani a gui write-ot nem rossz iranyelv, jol skalazhato sok emberre. Aki nagyon tudja mit csinal, az is hasznalja titokban az ilyen gui-kat, ne terjessze az iget a Dunning-Kruger szintu tudasuaknak.

Hany fos a csapat?

Jelenleg olyan 20-30 ember, de láttam már ennél nagyobbat is.

Mindenki egyetertett a dontessel?

Melyikkel? Ilyen toolt nem kötelező használni, mindenki felnőtt ember, az eredménye érdekes. De egyébként szerintem a többség használ ilyesmit.

Azzal, hogy rendnek kell lenni a commitokban? Abban egyébként igen. A részleteken van időnként csavargatás, erre valók pl a retrók. De egyébként van az a pont, ahol azért elmúlik a demokrácia, tudod, ez egy cég, lehet ám elvárásokat támasztani, meg meg lehet kérni azokat, akik szerint ez csak az architect faszsága, hogy ne itt írjanak kódot.

Szerinted ez 100-200 fos csapatban is elvarhato, hogy az emberek szetszedegessek a commitjaikat?

Persze, hogy elvárható. Miért, egy 100-200 fős csapatban nem kell normális melót kiadni a kezedből? Nincs ott struktúra, ami rendet tart? Egy 100-200 fős fejlesztő csapat képtelen megérteni a gitet?

Kiutazol majd Mumbaiba es elmagyarazod egyesevel minden fejlesztonek?

Hát, ahova kiszerveznek 100-200 fős fejlesztést, ott bizony előfordul, hogy az ember kimegy, és elmondja, hogy mit vár. Egyébként meg nem kell nekem egyesével, azért van ott egy szervezet, hogy ezt csinálja. Lesz majd mellé mentor, a reviewn vissza fogják baszni, elhúzódik az egész, nem lesznek kész időben, bemergelni nem fogják tudni a szemétdomot, amit csináltak, én itt a megrendelő oldalon csúnyán nézek, aztán majd rendbe szedik magukat. 

Elhiszem, hogy nalatok mukodik.

De nem varhatod el, hogy mindenhol mukodjon, es muszaj definialnod mukodest olyan esetekre, amikor emberek nem tudnak annyit a gitrol.

Es kezdetnek batortalani a gui write-ot nem rossz iranyelv, jol skalazhato sok emberre. Aki nagyon tudja mit csinal, az is hasznalja titokban az ilyen gui-kat, ne terjessze az iget a Dunning-Kruger szintu tudasuaknak.

Hogy a véres francba ne várhatnám már el fejlesztőktől, hogy tudják használni alapszinten a gitet? Ne vicceljünk már. Rádásul itt semmi bonyásról nincsen szó, a branchinget merginget ilyesmit egyébként is tudniuk kell hozzá, amiről én beszéltem, az gyakorlatilag annyi, hogy miután kb megvagy, szépen összekattogtatod, hogy a diff melyik része az első commit, a maradékból melyik a második és ígytovább. Aki ezt nem érti, az nem érti a többit se. Ráadásul ugyanakkora foshalmazt fog gyártani a cliből is, teljesen mindegy, azt még annyira se fogja érteni

Egyébként csodálatos, ahogy tekergeted a targetet.

- Közlöd, hogy semmi writera nem szabad guit használni

- Hozok egy példát, ahol kifejezetten hasznosak ezek az eszközök

- Erre közlöd, hogy hát ettől csak nem jó commitok lesznek

- Elmesélem, hogy miért nem, és hogy mi a haszna

- Akkor elismered, hogy ja, hát az jó lenne, dehát a gyakorlatban úgyis összevissza kell ugrálni, akkor ottmarad félkészen, és jajj

- Szólok, hogy az, hogy a workflow szar, annak ehhez semmi köze

- Akkor jön az, hogy egy rakás életképtelen nem tudja használni, és jajjmilesz

Meanwhile az igazság az, hogy aki ezt képtelen megérteni, annak a kódjával az lesz a legkisebb gond, hogy elkeveri a gitet, az már úgy is meg van baszva. Szóval szerintem maradjunk annál, hogy ne játsszuk már azt, hogy a guis chunk összevállogatást tiltjuk meg, mert az okoz bajt, miközben a baj láthatólag teljesen máshol van.

alapszinten a gitet

  1. ez nem alapszint
  2. elvarhatod, de akkor csalodni fogsz
     

A tobbi leirttal nagyjabol egyet is ertenek, de csunyan elbeszelunk egymas mellett.

Tiltas != batortalanitas - ne adjuk a gui toolt olyanok kezebe, akik parancssorrol nem tudjak hasznalni, nem ertik. Mert oket ha szamonkered, az IDE-re fognak mutogatni, veletlen se az o hibajuk volt, ha batoritod, hogy pl. hasznaljak az IntelliJ git pluginjat. Leginkabb itt van a felreertes.

Meg ott, hogy akarmit csinalsz, a legtobb dev ugy fogja rendezgetni a commitjait, ahogy jonak latja, vagy ahogy epp mukodesre birta birni a gitet, nem ugy, ahogy te elkepzeled.

>> Mondjuk a filekezelő integráció pont nem érdekel engem, de speciel commitok rendes összerakásához egy guis eszköz, ahol össze tudod kattogtatni, hogy melyik chunkok menjek a commitba, az igen hasznos. Azt biztos lehet cliből is csinálni, de elképesztő mazohizmusnak tűnik.

> Szerintem meg csak azt segiti elo, hogy legyenek mukodeskeptelen senki altal egyszer sem futtatott buildek/commitok. 

Innen indultunk, aztán innen jöttünk vissza a mindenhova máshova az InteliJ git pluginjáig, meg az életképtelen 200 indiaiig.

Mert oket ha szamonkered, az IDE-re fognak mutogatni, veletlen se az o hibajuk volt,

Oszt, hol szarom én le mire mutogat. Majd megtanulja használni. Ha meg tényleg szar az eszköze, majd csinálja másképp. 

Meg ott, hogy akarmit csinalsz, a legtobb dev ugy fogja rendezgetni a commitjait, ahogy jonak latja, vagy ahogy epp mukodesre birta birni a gitet, nem ugy, ahogy te elkepzeled.

Ne vicceljünk már, hát úgy baszom vissza codereviewn, mint a szél.  Az továbbra se az eszköz hibája, hogy idióták kezébe adva felügyelet nélkül egy rakás fos fog kijönni. Az csak illeszkedni fog minden máshoz abban a kódban.

Lattam pedig nem egy olyat, aki jo kodot irt, de egy conflictot nem tudott feloldani, ahhoz mar en kellettem. Meg az ujabban divatba jott "tok normalis a -f, mert mar mindenki rebase-el" es a -f-es commit torles revert commit keszitese helyett olyan, hogy elengedtem: hiaba vitatkozok masokkal, mit nem kene, egyszerubb helyettuk megcsinalni. Ha ez mindig ilyen egyszeru lenne: egy elmeny olyan utan takaritani, aki nem erti a -X ours es -s ours kozti kulonbseget.

Csak ha ezekutan valaki megmondja, hogy nem elegge jol vannak felosztva a commitjaim, korberohogom. Ha meg valaki megkerdezi javaslok-e gui-s git write toolt, hadd javasoljam neki a parancssort.

Masik, nem gites pelda:

"Ezt hogy tudom a localomban mukodesre birni?"
"Bekattintod ezt a 3 plugint az IDE-ben es megy"

Kiderult, hogy azt a projektet CLI-bol senki nem birta mukodesre birni, csak az IDE run gombjabol, es igy dolgoztak tobben rajta evek ota. :( Ezzel kapcsolatos ptsd-mhez kapcsolodik a grafikus git toolok batortalanitasa is. Csak az hasznalja, aki tenyleg pontosan erti mit csinal, es batoritani legyen mar tilos. Azt elhiszem, hogy te meg par kollegad erti, de azt nem, hogy nalatok a tobbseg erti mit csinaljon ha egy ilyen tool bajt csinal, vagy bugos.

Lattam pedig nem egy olyat, aki jo kodot irt, de egy conflictot nem tudott feloldani, ahhoz mar en kellettem. 

Tök őszintén, az a programozó, aki nem tud megtanulni egy rohadt conflictot feloldani gitben így 2023-ban, az menjen, és csináljon valami mást, annyi szép szakma van még.

Meg az ujabban divatba jott "tok normalis a -f, mert mar mindenki rebase-el" es a -f-es commit torles revert commit keszitese helyett olyan, 

Ez teljesen helyzet és megállapodás függő. Pl feature branches fejlesztésnél szerintem teljesen normális, hogy masteren revert commit kell ilyenkor, nem is fogsz tudni force pusholni, a feature branchről viszont merge előtt igenis tűnjön el a francba, tök fölösleges, legyen rajta rend rakva. Hogy menet közben mikor van rajta force push, azt meg attól függ, mi a folyamat.

hogy elengedtem: hiaba vitatkozok masokkal, mit nem kene, egyszerubb helyettuk megcsinalni

Ja, hogy húzod magadra a szart, aztán frusztrálódsz, értem :)

 Ezzel kapcsolatos ptsd-mhez kapcsolodik a grafikus git toolok batortalanitasa is

Asszem el is értünk a lényeghez, egyszer seggbe harapott, és azóta fáj, és ezt vetíted ki mindenki másra is :) Egyébként tőlem bátortalanítsd, csak az eredeti kijelentésed az volt, hogy ezek semmire se jók, közben meg...

Nézd, személy szerint többnyire én is a cli gitet használom, de nem ezen múlik, ez csak megszokás, meg kinek mi a kényelmes kérdése. Azon múlik, hogy érted-e a git (a legtöbb helyzethez egyébként szerintem túlbonyolított, de azért fejlesztőnek érthető) adatmodelljét, meg hogy mi mit csinál. Ha ezt megérted, akkor jó lesz, ha meg nem, akkor nem lesz az. Láttam én már hardcore cli-s kezéből is kiesni olyan szellemvonatos rendező pályaudvart, hogy ahhoz képest Harry Potter 9 és 3/4-ik vágánya sehol se volt, 4 féle tool 4 féle merőben egymásnak ellentmondó gráfot rajzolt belőle. 1 órát néztük a kollégával a reflogot, mire nagyjából kihámoztuk, hogy vajon mi a faszt sikerült csinálni ehhez (pusztán a sportértéke miatt, egyébként fubar volt az egész).

Tök őszintén, az a programozó, aki nem tud megtanulni egy rohadt conflictot feloldani gitben így 2023-ban, az menjen, és csináljon valami mást, annyi szép szakma van még.

Alapvetően egyetértenek, de azt a jelenséget is fel kellene számolni, hogy bizonyos fejlesztők commit early commit often helyett szökőévente borítanak a csapatra egy-gy óriási changeset-et, és ha éppen nálad van a forró krumpli, amikor megállítják a zenét, akkor azt tényleg nem jó érzés kiganézni.

A write. Kiveve ha valaki tenyleg nagyon tudja mit csinal a tool - azaz pontosan tudna hogy nezne az ki parancssorban (ritka ez a tudas).

Readnel ertem, hogy szarabb konzolkimenetet nezegetni, mint normalis dinamikusan kirajzolodo grafokat.

Es ez az idezett mondatommal sehol nem utkozik.

Nekem jatszik, mert en ertem, hogy az egy verem (azaz tobbet is stashelhetek, sorrendben visszapoppolom a megfelelo branchekbe - en szemely szerint szigoruan parancssorrol).

Pont azoknal nem jatszik, akiknek a szabalyait kell kitalalni. :)

Pont az a thread erdekessege, hogy egy feature attol meg, hogy letezik, nem feltetlen segiti a csapatmunkat, sot, bizonyos korulmenyek es elvarasok mellett egyenesen akadalyozhatja. :)

$ man git-sync
No manual entry for git-sync

4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.

Fájlrendszer-integráció attól függ, mit használsz.

  • Dolphin (KDE): dolphin-plugins
  • Nautilus/Nemo (Gnome és társai): rabbit-vcs

A standalone GUI toolokat nem szeretem, mert ha diffeket és merge-eket kell nézegetni, stb., jobb, ami az általam használt IDE-kben van. (iDEA, Eclipse).

Normál git CLI. Be lehet építeni GUI-s fájlkezelőkbe.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Szerkesztve: 2023. 04. 02., v – 21:36

Windowson Gitextensionst használok, teljes megelégedéssel sok éve - ahogy a leírásban olvasom, Linuxon is megy monoval.
Mindig jönnek konzolhuszárok, akik szerint hülye vagyok, de igazából sokkal jobban áttekinthető, több információt ad egy grafikus felületen pl. egy kommit gráfhoz, mint konzolban.

Volt már néhányszor, hogy akik le szokták nézni a GUIs toolokat, azok szoktak időnként kétseégbeesett emaileket körbeírni, amiben git expertet keresnek, engem szerencsére ez a tool ettől megkímélt.

Offtopic vagyok, de ...

FLOSS környezetben dolgozom, ahol gyakran távoli gépeken is kell verziót kezelni (pl. teszteket futtatok SSH -n és javítom a hibákat). GUI ezeken a helyeken nincs, vagy a távoli asztal nagyon lassú lenne, ráadásul a sok gép között szinkronizálni a GUI tool beállításokat rémálom. Szóval igyekszem "spártai" körülmények között boldogulni.

A CLI git kliens előnye, hogy rengeteg segítség akad a neten. A GUIs kliensekre ez nem igaz, ráadásul sok GUI kliens nem támogat bonyolultabb képességeket (pl. interactive rebase). Amelyik igen, az fizetős.

Szóval, mindenhol CLI -t használok. Ha a sima git parancsok nem "mutatnak eleget" akkor előveszem a tig -et. Ez egy szöveges módú UI -t implementáló git kliens (kb. mint midnight commander vs alap linuxos fájlkezelő parancsok). Ez egy nagyon jó kis tool, bár nyilván az elején tanulni kell. A legtöbb git -hez kötődő dolgot tudja vizualizálni "pager" -ként (pl: cat <patch file> | tig). Amikor ez is kevés, átpakolom a módosításokat lokális gépre, és a gitk és git-gui kombót használom. Ez a komitokat menedzselni általában elég.

Gyakran használom a vscode beépített git kliensét a módosítások szelektált indexbe pakolásához. Ennek szebb a felülete a git-gui -nál vagy a tig -nél, cserébe nem alkalmazkodik a felhasználóhoz (nem lehet csak úgy akárhol használni a klienst, fel kell venni a könyvtárat a vscode -ba, stb...).

Régebben a Sourcetree -t azelőtt meg a SmartGit -et használtam. A Sourctree általános kliensből elment Atlassian specifikus kliens irányba így váltottam, illetve nem is tudott többet mint a gitk+gut-gui páros. A SmartGit nagyon állat, de fizetős, és FLOSS környezetben FLOSS eszközökkel tudok a felhasználók számára reprodukálható környezetet és folyamatokat definiálni. Amikor "hunk" -öket kell komitok között pakolászni (ez volt a SmartGit kiemelkedő képessége), akkor a CLI sok extra kézi machinációt igényel, de ha az ember ésszel dolgozik, akkor erre ritkán van szükség. Illetve a history -ban pakolászás helyett lehet pl. git worktree -vel csinálni egy új working copy -t (örökli a branch -eket, stash -t, hook -okat és egyéb beállításokat), majd ott egy új ágban cherry-pick -kel felépíteni az új history -t. Evvel a módszerrel sok "kézimunkát" lehet spórolni.

Egy szó mint 100 szerintem klassz megoldás a tig, gitk, git-gui trió, bár tanulás és megszokást igényel.

A git-gui és gitk barátaink egyébkét alapból feltelepülnek Win-en a git-scm.com-os telepítővel. Linuxon nem, de egy mozdulattal felrakhatóak. Az tény, hogy durván rondák. Elsőre nem is értettem, hogy gitk-ban jobb clickre mikor jelenik meg a checkout és mikor a reset. De ha az ember jól érti a CLI-t, akkor jól elvan ezekkel is.

Ami a merge-et illeti, ott a vscode. Vagy ha okosabb kell, akkor a KDiff3-nál aligha akad jobb, nem véletlenül mutat 3+1 (A, B, C, out) kódot. Ezt a KDiff3-at nem is értem, a cégek felének az élete múlik rajta. Hogy nem öntenek oda egy tonna aranyat a fejlesztőjének?

Szerkesztve: 2023. 04. 06., cs – 04:05

Esetleg még ez is egy megoldás lehet :D

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

eletemben nem tudtam hasznalni ezeket a UI version control dolgokat :D

nekem boven megfelel a git parancssor