Oh Shit, Git!?!

Segédprogramok

Már többször volt szó itt a HUP-on arról, hogy mennyire szar használni a git-et. Nos, nem vagyunk ezzel egyedül, a minap véletlenül belebotlottam ebbe a jópofa oldalba:

https://ohshitgit.com/

Ez bár kicsit gúnyosan, de konkrét példákat szed össze, "ha ezt cseszted el -> akkor ezek a kapcsolók kellenek" stílusban, így könnyen átlátható és roppant hasznos. Szvsz tényleg egy átlagos programozó mindennapi használata során előforduló eseteket vesz számba. Mindesetre az biztos, hogy könnyebb megtalálni benne, amit keresünk, mint a gitscm doksiban vagy a git manpage-ekben.

Nálam több, mint 10 év git használat után is repült az instant könyvjelző, remélem másnak is hasznára válik!

( zrubi v | 2025. 01. 17., p – 11:34 )

azért lássuk be a legtöbb "oh shit" az tulajdonképpen user error. :)

zrubi.hu

A git esetében nem. A felhasználói felülete (úm. parancssori kapcsolói) egy kész istencsapása, amit a legtöbb programozó képtelen megjegyezni (engem is beleértve). 10 év git használat után is azon kapom magam, hogy előjönnek olyan esetek, amikor keresnem kell a megoldást, mert annyira nem tanulhatóak a kapcsolói, képtelenség megjegyezni őket. Érdekes, más programoknál sosincs ilyen problémám, a git-nél viszont folyton folyvást előjön.

Ezt egyébként az oldal gyönyőrűen szemléltetni, lássunk egy példát: "I committed and immediately realized I need to make one small change!" ez teljesen tök tipikus, mindennapi eset, számtalanszor előjön. És mi a megoldás rá? Két egymásutáni git parancs kiadása. Miért nem egy szimpla kapcsoló, ha egyszer gyakori eset?

Az, hogy több parancs kiadása szükséges egy ilyen tipikus eset megoldásához, NEM user error, még véletlenül sem, ez bizony az app hibája. (Az meg különösen, hogy nem a megszokott nomenklatúrát használja, mármint minden IT szakember értené azt, hogy "update", na de "amend"??? Miért nem a megszokott IT-s szakzsargont használja, minek kellett újra feltaláni a kereket?)

En a Dockerrel es a kubernetes-szel vagyok ugy, hogy keptelen vagyok megjegyezni a kapcsoloit, mai napig egy cheat sheet txt-bol vagy zsh history-bol paste-elem ki a legalapabb funkciok kapcsoloit is.

A git ehhez kepest elegge az agyamba irodott, amig a  HEAD string nem a parancs resze, fejbol dolgozok cheat sheet nelkul.

 lássunk egy példát: "I committed and immediately realized I need to make one small change!" ez teljesen tök tipikus, mindennapi eset, számtalanszor előjön.

Ja gondolom az outlookban is ezért csinálták a 'recall' feature-t, ugye? :)

Azoknak azkik nem képesek átgoldolni/átolvasni/kipróbálni! amit alkottak, mielőtt elküldik :D

 

No offense, de a 'többiek' az ilyen fícsörökön, és a felhasználóikon is csak röhögnek.

zrubi.hu

Azoknak azkik nem képesek átgoldolni/átolvasni/kipróbálni! amit alkottak, mielőtt elküldik :D

Esetemben akkor szokott ez előjönni, amikor megírom a MarkDown-t, jónak is tűnik a szerkesztőben, majd miután felrakom gitlab-ra és ott HTML-é konvertálva csecsén megjelenítve újfent átolvasom, akkor veszem észre, hogy valamit elütöttem vagy valamit nem úgy jelenít meg, ahogy szerettem volna.

No offense, de a 'többiek' az ilyen fícsörökön, és a felhasználóikon is csak röhögnek.

No offense, de attól még valós igény, mivel a programozók döntő többségével elég gyakran előfordul. Azt hinni, hogy valami nem probléma, csak azért, mert neked személy szerint nem probléma, eléggé szűk látókörűségre vall.

És mi a megoldás rá? Két egymásutáni git parancs kiadása
 

több parancs kiadása szükséges egy ilyen tipikus eset megoldásához, NEM user error, még véletlenül sem, ez bizony az app hibája.

Nem kell hozzá két parancs; ebben az esetben semmi hibája nincs az appnak programnak. Az általad keresett (git commit) kapcsoló az `--all`.

-a, --all                                                     
    Tell the command to automatically stage files that have
    been modified and deleted, but new files you have not told
    Git about are not affected.

Tehát: minden, már követett fájl változását automatikusan (azaz `git add` nélkül) belerakja a commitba. Ez épp arra jó, amit hiányolsz, ti. hogy gyakori, egyszerű eseteket lerövidít. Én pl. legtöbbször egyszerűen kiadom a parancssori előzményekből a `git commit --verbose --all` parancsot, és kész. Az általad és az oldal által említett esetben pedig csak egyetlen kapcsolót kell hozzáadni a commit parancshoz, és máris nem kell `git add`: `git commit -a --amend --no-edit`.

Azért vegyük észre, hogy főleg akkor kell rákeresni a megoldásra, ha valami nagyon ritkán kell. A gyakori dolgokat én is fejből vágom git-ben. Eleinte én is elcsesztem sokszor, hogy létrehoztam a branch-et és elfelejtettem átváltani rá, majd commitoltam. Megtanultam hogy kell áttenni a commit-ot egyik branchről a másikra. (Nyilván a cherry-pick-es megoldás a "jó" kb erre találták ki. Amit a linkelt oldalon első helyen írnak az szerintem borzalmas).

Egyszer venni kell a fáradtságot és rendesen felfogni, hogy működik belül a git, mi az adatmodellje. Akkor helyrekerülnek a műveletek.

Régóta vágyok én, az androidok mezonkincsére már!

Azért vegyük észre, hogy főleg akkor kell rákeresni a megoldásra, ha valami nagyon ritkán kell.

Pontosan. Az általam kiemelt példa is tipikusan ilyen: nem gyakran fordul elő velem, hogy commit után veszem észre, hogy módosítani kell, de azt sem mondhatnónk, hogy soha nem fordul elő (tipikusan md fájlokkal járok így, miután látom őket push után HTML-ként).

Egyszer venni kell a fáradtságot és rendesen felfogni, hogy működik belül a git, mi az adatmodellje.

Azért már ajánlottak nekem fizetést, hogy feltegyek valamit egy git hostra, de azért még soha senki sem akart fizetni, hogy megtanuljam a git belső lelki világát.

Ezt egyébként az oldal gyönyőrűen szemléltetni, lássunk egy példát: "I committed and immediately realized I need to make one small change!" ez teljesen tök tipikus, mindennapi eset, számtalanszor előjön. És mi a megoldás rá? Két egymásutáni git parancs kiadása. Miért nem egy szimpla kapcsoló, ha egyszer gyakori eset?

Ez engem sohasem frusztrát. Felétek elfogynak a verziószámok? Én egyszerűen kiadom három perc múlva nagyobb verziószámmal, és meg is vagyunk.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Te valamit nagyon benéztél. Senki sem beszélt semmiféle verziószámokról...

Arról volt szó, hogyha gyakori esetekhez kilométer hosszú kapcsolók kellenek és/vagy több parancs, az igenis a program hibája. Egy jól megtervezett programnál ugyanis a gyakorabb parancsokhoz kevés kapcsoló kell, és a ritkán használtakhoz sok, nem pedig fordítva, mint a git-nél.

Kiadsz valamit v541 alatt, majd három perc múlva ráébredsz, hogy elfelejtettél egy pointert NULL-ra vizsgálni, meg kimaradt egy komment. Ezeket orvosolod, a verziószámot v542-re módosítod, majd kiadot a cuccot újra. Gondolom, ha az első commit kevés kapcsolóval történt, akkor három perccel később a következő commit pontosan ugyanannyi kapcsolóval történik. Erre írtam, hogy ebben az esetben én ezt csinálom, semmivel sem bonyolódik az életem.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Übermegalol!

Tisztában vagy vele, hogy mi is az a kapcsoló? Vagy hogy általad megadott 5 paraméteres (!) parancsból mennyi kapcsoló? (Elárulom, nem, nem megy kapcsolók nélkül, te is használtál, nem is egyet!)

Mégegyszer: a kritikám az, hogy 5 paraméter kell ilyen egyszerű művelethez, mint fájl hozzáadása. Ez nem normális, és épeszű ember nem jegyez meg ilyeneket, hanem cheat sheet használatára kényszerül.

...épeszű ember nem jegyez meg ilyeneket, hanem cheat sheet használatára kényszerül.

Felhívnám a figyelmedet, hogy már a XXI. században vagyunk, és már a negyede annak is eltelt.

Használni kell a technológia vívmányait.

Ez 3 perc, 4 prompt volt ChatGPT-vel.

Az aliasok tab-completionelhetők, vagy fzf-fel fuzzy módon kereshetők, szóval még annyit se kell gépelni.

----

# Basic Git Commands
alias git-status='git status'               # Show the current status of the working directory
alias git-pull='git pull'                   # Pull changes from the remote repository
alias git-push='git push'                   # Push local changes to the remote repository
alias git-commit-msg='git commit -m'        # Commit changes with a message
alias git-amend='git commit --amend'        # Amend the last commit
alias git-amend-with-file='git commit --amend -C HEAD'   # Amend the last commit with file (ezt én adtam hozzá utólag)
alias git-add='git add'                     # Stage specific changes for the next commit
alias git-add-all='git add .'               # Stage all changes
alias git-remove='git rm'                   # Remove files from the working directory and index
alias git-checkout='git checkout'           # Switch branches or restore files
alias git-new-branch='git checkout -b'      # Create and switch to a new branch

# Branch Management
alias git-branches='git branch'             # List, create, or delete branches
alias git-unmerged-branches='git branch --no-merged' # List branches not merged into the current branch
alias git-delete-branch='git branch -d'     # Delete a branch
alias git-force-delete-branch='git branch -D' # Force delete a branch

# Log and History
alias git-log='git log --oneline'            # Show a concise, one-line log of commits
alias git-log-graph='git log --graph --oneline --decorate' # Show a visual graph of commits
alias git-log-detailed='git log --stat --decorate' # Show a detailed log with file changes
alias git-last-commit='git log -1 HEAD'      # Show the most recent commit

# Stash Commands
alias git-stash='git stash'                  # Stash changes
alias git-stash-pop='git stash pop'          # Apply and remove the last stash
alias git-stash-list='git stash list'        # List stashes
alias git-stash-apply='git stash apply'      # Apply a stash without removing it

# Fetch and Remote
alias git-fetch='git fetch'                  # Fetch updates from the remote repository
alias git-fetch-origin='git fetch origin'    # Fetch updates from the origin remote
alias git-remotes='git remote'               # Manage remotes
alias git-remotes-list='git remote -v'       # List remotes with their URLs

# Rebase and Merge
alias git-rebase='git rebase'                # Rebase the current branch
alias git-rebase-continue='git rebase --continue' # Continue rebase after conflicts are resolved
alias git-rebase-abort='git rebase --abort'  # Abort a rebase
alias git-merge='git merge'                  # Merge branches
alias git-merge-squash='git merge --squash'  # Squash and merge changes into a single commit

# Reset and Clean
alias git-reset='git reset'                  # Reset the staging area
alias git-reset-hard='git reset --hard'      # Reset to the last commit, discarding changes
alias git-unstage='git reset HEAD'           # Unstage changes
alias git-clean='git clean -fd'              # Remove untracked files and directories
alias git-undo-last='git reset --soft HEAD~1' # Undo the last commit but keep changes

# Tagging
alias git-tags='git tag'                     # List, create, or delete tags
alias git-create-tag='git tag -m'            # Create an annotated tag with a message
alias git-delete-tag='git tag -d'            # Delete a tag

# Diff and Compare
alias git-diff='git diff'                    # Show changes between commits, branches, etc.
alias git-diff-staged='git diff --staged'    # Show changes in the staging area
alias git-diff-cached='git diff --cached'    # Alias for staged changes

# Custom Aliases for Efficiency
alias git-fixup='git commit --fixup'         # Create a fixup commit
alias git-restore='git restore'              # Restore working directory files
alias git-commit-short='git commit'          # Shortened commit command
alias git-cherry-pick='git cherry-pick'      # Apply commits from another branch

---

Szerk: kézzel hozzáadtam a git-amend-with-file aliast a fenti parancsnak.

Na ezért nem szoktam ide, a hupra írni. Te is csak egy tipikus troll vagy. Übermegalol, hogy szakmai problémákat nem tudsz megoldani (feltételezve, hogy épeszű embernek tartod magad). Tudok én is trollkodni, meg személyeskedni, kár, hogy jobban preferálom a szakmai beszélgetést.... Ja és alapból sértegetsz, ugyanis én meg tudok jegyezni ilyeneket, ergo nem tartasz épeszű embernek.

Úgy 17 éve van a fenti parancsra aliasom. Ha meg esetleg bonyolultabb, shell függvényt vagy scriptet írtam. Egyszer megértem, megjegyzem, aztán megoldom, hogy ne kelljen fejben tartanom.

Előbb túljutottam az opciók problémáján, minthogy a stack overflow, github, pláne ChatGPT létezett volna.

meg aztan a git-ben (de amugy az egesz Linux mindenben is) az opciok nevei altalaban elegge beszedesek es nem urdungtu valo egy kibaszott man-t megnyitni es keresni benne. Nyithatnak egy "jujj, a vim szar, mert keptelen vagyok megjegyezni, hogy a w = word a d = delete, stb opciokat igy nem tudok 5 szot torolni ugy hogy d5w, mert ez mar mekkora gagyisag", de igazabol csak lejaratna vele az ember magat :D

Aztan irja itt hogy a git abajgatasa penzugyi kiesest okoz, ami netto hulyeseg. A szarul megirt programok, es tesztek meg a szarul mnegdesignolt infrastruktura ami miatt penzugyi veszteseg eri legtobbszor a cegeket. Ha nagyon elbassza az ember a local copyt, kb 30 masodperc egy szep uj ropogost csinalni, amennyiban ehhez valakinek meg a man-t is meg kell nyitnia. A tobbi hulyesegrol meg nem is irok. Elkezdtem, de aztan inkabb megse irtam le. :D 

Így van!

Mindjárt az elsőből is látszik, hogy a készítő sem igazán érti a git lényegét és általában nem jól használja:

 I use reflog A LOT. 

Én még a kezdetekben voltam kénytelen használni, amikor sok kezdő git-es mindent össze-vissza próbálkozott, alapfokú tudás nélkül. Évek óta már nem igen kellett, hogy rápillantsak.

( Zsugabubus | 2025. 01. 17., p – 11:45 )

Na eddig nem tudtam, hogy a git diff --cached helyett lehet azt is írni, hogy --staged.

( NevemTeve | 2025. 01. 17., p – 12:20 )

Egyet én is ismerek: ha egy helyi fájlt nagyon elrontok, akkor rm file; git checkout file (ez véletlenül CVS-ben is pont így megy).

( nevergone v | 2025. 01. 17., p – 12:29 )

Szar használni? Vagy inkább csak b*sznak megismerni?

A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.

Na ha a Zenről lenne szó, akkor helyeselnék: jogos, hogy a megvilágosodás eléréséhez sok munka kell. Na de itt egy verziókezelőről van szó, nem a megvilágosodásról. Pláne, hogy egy olyan eszközről van szó, amit azért erőltettek ránk, mert a CVS-t túl egyszerűen lehetett használni.

egy olyan eszközről van szó, amit azért erőltettek ránk, mert a CVS-t túl egyszerűen lehetett használni

Használtam eleget CVS-t, ezért ezt a mondatot sokat fogom emlegetni.

A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.

a megvilágosodás eléréséhez sok munka kell.

Azért ha megnézed a hivatkozott oldalt, tényleg tele van PEBKAC-cal. Pl. "Oh shit, I need to undo a commit from like 5 commits ago! [...] Turns out you don't have to track down and copy-paste the old file contents into the existing file in order to undo changes! If you committed a bug, you can undo the commit all in one go with revert." Mi az, hogy "turns out"?! Értem, hogy semelyikünk se tud semmit magától, "csak úgy", de ha nem hajlandó semmiféle bevezetőt elolvasni (vagy ráDuckDuckGózni a problémájára), akkor azt ne hazudja már a program hibájának, és főleg ne ekkora arccal tegye azt.

Tény, hogy a git kézikönyvrengetegében könnyű elveszni (ami a systemd-re legalább ennyire igaz, de "érdekes módon" ez nem sokakat zavar), de rögtön a `man git` második és harmadik bekezdése úgy szól, hogy (kiemelés tőlem):

See gittutorial(7) to get started, then see giteveryday(7) for
a useful minimum set of commands. The Git User’s Manual[1] has
a more in-depth introduction.

After you mastered the basic concepts, you can come back to
this page to learn what commands Git offers. You can learn more
about individual Git commands with "git help command".
gitcli(7) manual page gives you an overview of the command-line
command syntax.
 

Már a `man git` is megemlíti pl. a revert parancsot is, és röviden elmondja, mi az ("Revert some existing commits.", ill. "git-revert(1) is about making a new commit that reverts the changes made by other commits.".), de tegyük fel, hogy nem olvassuk végig az oldalt (ami érthető, mert tényleg rohadt hosszú), hanem a jótanácsot megfogadva elkezdjük nézni a gittutorial (7)-t. Már az elején ("Making changes") szerepel a `git diff --cached` (és itt is elmondja, mi az a `--cached` és miért kell), kicsivel alatta pedig szerepel egy `git commit -a`, ez is megmagyarázza, mire jó a(z) `-a`.

Nem fogok hazudni, én is sokszor szeretnék azonnal használni valamit a lehető legkevesebb olvasgatással, de lássuk be, semmiből nem lesz semmi, azaz muszáj beletenni valamennyi (>0) munkát. Azon vitatkozhatunk, hogy valaki miért nem talál megfelelő bevezető szintű oktatóanyagokat, de ahogy nézem, ez pont a git esetén adott (lásd a fent idézett `man git` részt, és akkor az ingyenes Pro Git könyvet és a git saját bevezetőit másoló ezernyi online anyagot nem is említettem).

Értem, hogy semelyikünk se tud semmit magától, "csak úgy", de ha nem hajlandó semmiféle bevezetőt elolvasni (vagy ráDuckDuckGózni a problémájára), akkor azt ne hazudja már a program hibájának

Nem hazugság, és de bizony, a program hibája. Méghozzá konkrétan az, hogy normál használathoz is "ráDuckDuckGózni" kell.

Én vagyok az élő példa. Egy évtizede használom már legalább a git-et, a doksiját és manpage-eit legalább 3x végigolvastam elejétől a végéig, mégsem emlékszem a kapcsolóira. Nyilván ennek több oka van:
1. nem vétek olyan gyakran hibákat, hogy folyton kellene használnom (amire ritkán van szükségem, azt bizony haljamos vagyok elfelejteni, de ez NEM user error, ilyen az ember, tetszik, nem tetszik)
2. nem a megszokott, jól bejáratott szakzsargont használja (ez sem segíteni a megjegyzést, ugye)
3. amit használ a szakzsargonból, azt meg kifejezetten hibásan használja (nem, a "reset" számomra nem azt jelenti, hogy visszalépni eggyel és/vagy megszűntetni a kijelölést, ahogy az "rm --cached" sem)
4. nem a felhasználás szemszögéből nevezték el a kapcsolókat, így lehetetlen kitalálni őket (hacsak valaki nem keni-vágja a git internals-t a legapróbb részletekig, sosem fog rájönni)
5. nem egyszerűek a kapcsolók, kifejetten túlburjáznak (pl. "reset --hard HEAD", hát a f*m, miért nem csak "undo" és kész, ugye)
6. látszólag ugyanazt többféleképp is meg lehet csinálni (de csak látszólag, programozó legyen a talpán, aki átlátja, melyik kapcsoló mit eredményez under the hood hosszútávon)
7. a doksija tényleg szar, ahogy mondod; úgy van megírva, hogy csak akkor találj meg benne valamit, ha már eleve tudod azt, amit keresnél (de akkor meg minek keresnéd, ugye)

Nem fogok hazudni, én is sokszor szeretnék azonnal használni valamit a lehető legkevesebb olvasgatással

Teljesen félreérted a dolgot. A kritikám nem az, hogy utánna kell olvasni valaminek, amibe először belefutok. A kritikám az, hogy idegesítő, hogy sokadjára is utánna kell olvasnom, mert legutóbb fél éve kellett, és már csak arra emlékszem, hogy volt valami ilyesmi parancs, de azt lehetetlen megjegyezni, hogy mi is volt (vagy mert idióta a kapcsoló, vagy mert mást jelent, mint az összes többi UNIX parancs esetén, stb), vagy hogy legutóbb hol (milyen kifejezésre keresve) találtam meg a választ a doksiban.

( joco01 v | 2025. 01. 17., p – 12:36 )

Egyet kell értsek. A legtöbb ellenkritika azoktól jön, akik ezt már nagyon megtanulták, de ez ilyen "git gud" (no pun intended) jellegű értéktelen semmi. Attól, hogy megtanultad, még lehet szar. Én ebből a szempontból nagyon szeretem a mercurialt. A hg parancsok intuitívek, sok esetben befigyel egy ncurses-jellegű UI (hg histedit, hg split), és ritkán kell kapcsolókat használnom.

Git-hez is vannak TUI-s könnyítések (tig, lazygit), sok text editorban, IDE-ban vannak UI-s git pluginek. Én ritkán használom, de akkor inkább a hagyományos CLI-nél maradok. Azt az egy-két parancsot nem olyan nehéz fejben tartani, akinek nem megy, csinálhat hozzá aliast vagy szkriptet, opcionálisan fzf-et is bevonva.

Az a baj, hogy ha valami nem GUI, akkor sokan megijednek, teljesen feleslegesen. Pedig ha belegondolunk, a legtöbb ma használt eszköz nem GUI-s, web/SQL szerverek, docker-alapú megoldások, fordítók, ffmpeg, stb.. A CLI sem nehéz, megszokás kérdése. Értem, hogy aki csak GUI-n nőtt fel, annak idegen elsőre, de ha megismeri, akkor nem rossz.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

A hg command-line valóban sokkal érthetőbb és logikusabb, de sajnos lemaradt a versenyben, és most már kb esélytelen, hogy ugyanúgy elterjedjen, mint a git. 

Ráadásul azért a git sem annyira katasztrófális, hogy érdemes legyen mondjuk valami hg wrapperrel használni.  Én is sokáig maradtam hg-n,  de egyre több helyen használtak git-et, muszáj volt azt is megérteni, megszokni.  A megszokàs után meg már igazából egyáltalán nem rossz :)

Szerk: a gui eszközöket kerülöm verziókezelés kapcsán, szóval az nekem nem szempont.

A mercuriallan sokkal kevesebb marhaságot lehet csinálni, ez tény. Sokkal jobban megvédi a felhasználót saját maga ellen. Kár hogy kevesebben használják már. Én nagyon szeretttem.

Kicsit offtopic, de: Amikor a bitbucket kivezette, az fájdalmas volt. Körbeírtak, hogy megszüntetik, és persze a legnagyobb meló kellős közepén kellett git-re migrálni. Nem tudom, hogy rövid határidőt adtak, vagy mi voltunk végig nagyon elfoglaltak, de nagyon nem jókor jött. Ebből látszik, hogy azért felhő szolgáltatásokat használni sem életbiztosítás, bármikor egy tollvonással megszűnhet bármi (ha nem is gyakori), és kénytelen vagy igazodni.

( Fisher v | 2025. 01. 17., p – 18:15 )

Mondjuk pl. én arra lennék kíváncsi, hogy amihez két parancs kell, azt meg lehet-e csinálni másik verziókezelőben. Vagy egyszerűbb-e. Valamikor, ~20 éve svn-t használtam, most jó ideje git-et, más nem ismerek. Mondjuk se a gitről, se az svn-ről nem állítanám, hogy ismerem őket.

Biztosan létezik git-nél egyszerűbb, de kisebb tudású alternatíva, de nem néztem. Nekem már a git is eléggé minimalista, ez lett a sztenderd mindenhol, ezt kérik, ezt kell ismerni. Lassan már átlag linuxos user szintjén is egyre megkerülhetetlenebb, hogy legalább egy git clone-t tudjon, ha nem akar zip-et töltögetni, és kicsomagolgatni külön lépésben.

A másik, hogy igen, a git elég bonyolult, komplex, de mégis csak egy 4,5 megás CLI tool, sehol nincs a mai gigantikus Electron appokhoz képest. Nem kötelező benne használni minden funkciót, elég azt a pár parancsot ismerni belőle, amit az ember napi szinten használ. Aki ezt a keveset nem tudja megtanulni, ne legyen fejlesztő. Én se vagyok az, meg nagy git guru se, és mégis megtanultam alap szinten használni. Nem mondom, hogy a kedvencem, de mindenhol alap ma már, és kibírható. Sokkal jobb, mint a régi verziókezelőkben, meg kézileg zip-pegetve, meg sourceforge-olva szerencsétlenkedni, ahogy korábban tették a fejlesztők.

Ha annyira akarnék, tudnék írni magamnak egy rettenet primitív verziókezelőt, ahol a kódfát kézileg elágaztatnám, és a diff/patch-eket ahhoz tárolnám el egy mappába, ami mondjuk egy tömörített meghajtón, tömörített mappában van, a diff/patch-ek fájlnevei meg a commit message funkcióját töltenék be. Simán megcsinálható shell scriptként. A kerék újrafeltalálását nem érné meg, egyszerűbb azt a pár git parancsot megjegyezni.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

elég azt a pár parancsot ismerni belőle, amit az ember napi szinten használ

Ezekkel nincs is baj. Nem akkor van baj, amikor nincs, hanem amikor van. (Vagy hogy is szól az egyik fórumtárs aláírása, ide nagyon illik.)

A gond ott kezdődik, ha a normál napi működéstől eltérő dolog történik (ami ugye nem túl gyakori, de azért előfordul, emiatt nem emlékszel az akkor szükséges kapcsolókra), na akkor megy el több értékes munkaóra arra, hogy guglizik meg doksit nyálaz az ember, csak azért, hogy helyrehozza a git repót. Ez konkrét anyagi veszteségben mérhető a cégeknek, mert a drága pénzen fizetett programozók a git-et tutujgatják, ahelyett, hogy projektjükön dolgoznának.

A topiknyitóban linkelt oldalon található esetek gyönyörű példái ennek szvsz. És az ilyen cheat sheetek ki is húznak a csávából, de azt látni kell, hogy ez nem megoldás, hanem ugly workaround.

Ez ilyen. Ha nem tetszik, írj jobbat. Ezt most teljesen komolyan írom, és nem is gúny vagy trollkodás képpen, belőled ki is nézem, hogy simán tudnál ilyen verziókezelő rendszert írni saját magad, ami jóval minimalistább. Én nyitott lennék az ilyesmire, mert a git tudásának saccra 90%-ára nincs szükségem. Amíg viszont nincs másik, addig a git marad továbbra is a leghasználhatóbb, legsztenderdebb megoldás, és megéri ezt megtanulni, megszokni, ha az ember nem akar a széllel szemben hugyozni. Akárkivel is kell majd a jövőben esetleg munkahelyen vagy netes projektben összedolgozni, ők is git-et fognak jó eséllyel használni, ez az a műfaj, amiben nem éri meg különcködni.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Ahogy az általad linkelt oldalak is írják, a dolog azért veszélyes, mert az SVN nem elosztott, a commit azonnal megy a közös repo-ba (mivel csak az van). A probléma ugyanúgy fennáll git esetén is, ahogy a manual említi: ne csinálj amend commitot ha már pusholtál! Csuda jó móka, ha már pusholt branch-en csinálsz bármit, ami "history rewrite"-al jár... Egyszer sikerült rebase-elnem egy origin branchet, hát hónapokig szívtunk miatta. Greg Kroah-Hartmann is azt mondta egyszer nagyon nyomatékosan, hogy sose rebase-elj

A git minden szart megenged, aztán pisloghatsz, ha figyelmetlenségből elszúrtál valamit.

A push --force-t tiltani kell a közös repoban, különben valaki csinál egy git init, git push --force manővert, aztán leshettek. Vagy akár bármilyen history rewriteot is csinálhat, az se egészséges.

Szerintem a rebasenek is megvan az értelme, merge a masterbe, vagy akár PR beküldése előtt is.

Szinte napi szinten használom a rebase/amend/force push lehetőségeket, sosem szokott belőle gond lenni. Legfeljebb a saját munkámat tudom vele összekavarni, ha nagyon figyelmetlenül bűvészkedek. :)

Nyilván az integrációs brancheket védeni kell ilyesmitől (mifelénk ezekbe nem is lehet közvetlenül pusholni), de a saját használatú feature/bugfix-brancheknél nagyon hasznosak ezek, hogy kulturált commitokat és PR-eket tudjak gyártani.

Najó, de nem muszáj rosszul használni, csak azért, mert lehet. Ugye arról van szó, hogy a "Oh shit, I committed and immediately realized I need to make one small change!" ami ezek szerint egy "mindennapi használata során előforduló eset", azt a szar gitben - push előtt, mert hogy immediately -, könnyen meg lehet csinálni. Aki sűrűn komitol ész nélkül, az meg úgyis hamar megjegyzi az amendet.

Plusz a számomra egy megnyugtató dolog, hogy push előtt legfeljebb csak a saját motyómat borítom meg.

( deje | 2025. 01. 17., p – 23:38 )

Azt vettem észre, hogy azok istenítik a gitet, akik nem használtak másik dvcs-t előtte.

Mindig eszembe jut: "a szar nem is lehet olyan rossz, egymilliárd légy nem tévedhet!"

A git azért készült, hogy a Linux kernel fejlesztési workflow-ját támogassa. Semmi másra. Csakhogy ne felejtsük el, hogy ennek a projektnek a workflow-ja eléggé sajátos, s legtöbb projekt nem ilyen. Sokat fejlődött az eszköz, hogy másra is jó legyen, de az egész olyan, mintha random legó elemekből rakták volna össze (mellesleg így történt...). A kifejezések és elnevezések benne nagyon nem intuitívek, nem is vagyok hajlandó parancssorból használni, egyszerűen fáj. Szerencsére az Eclipse és az IDEA vcs GUI-ja nagyon jól használható.

Én a Mercurial-al kezdtem a dvcs világot, főleg SVN-t használtam előtte, nem volt nehéz átállni. A git totál agyrém ezekhez képest, persze sokat tud, meg gyors, meg minden, de rettenetesen túlértékelt. Nem attól lesz jó egy szoftver, hogy Linus Torlvards húzta elő a seggéből, vagy hogy mivel kurva nehéz a paranccsori interfészét használni, ezért aki képes megtanulni, azonnal felsőbbrendűnek érezheti magát.

A hard branch-ek nekem a mai napig hiányoznak, a fene se akar állandóan forkolgatni.

Tudom, rosszul tartom...

( timar | 2025. 01. 18., szo – 12:03 )

Túl van ez a kérdés misztifikálva. Semmit nem láttam ezen az oldalon, amit ne tudtam volna, és az egész egy 2 perces olvasmány. Manapság minden bonyolult és szar, amit nem lehet 10 másodperc alatt megérteni vagy nem lehet 3 mondatban elmondani. Ez nagy gond, és elszomorító. 

Ez pont hogy alátámasztja, amit mondtam. A git bonyolult, sokat tud, de senkinek nincs szüksége arra, hogy minden lehetőséget ismerjen. A legtöbb fejlesztőnek elég (nagyságrendileg) 10 git parancs, és egy alapvető megértés a működéséről (hogy pl. nem patcheket tologat a git ide-oda, és akkor nem lepődünk meg, hogy miért van conflict pushnál, amikor nem is ugyanazok a fájlok módosultak helyben, mint a távolban).

Én amúgy minden verziókezelőről találtam könyvet a Google-n, CVS, SVN, Mercurial... 

Manapság minden bonyolult és szar, amit nem lehet 10 másodperc alatt megérteni vagy nem lehet 3 mondatban elmondani.

Tévedésben vagy. A git nem a cél, hanem egy eszköz. Ha valakinek nem tudod elmagyarázni a kalapácsod használatát 10 másodpercben, akkor mennyi esélye van, hogy majd hatékony munkát fog végezni neked? Na ugye.

Bezzeg az őskorban, ott még voltak olyanok, hogy User Interface Guideline-ok, amiknek az volt az értelme, hogy a felhasználók ne azzal basszák el az idejüket, hogy az eszközeikkel szenvednek a munkájuk végzése helyett. Persze mára az ilyen hatékonyságnövelő úri huncutságok kikoptak, mert minek, ugye? Aztán csak kiderül, mégsem voltak az öregek olyan hülyék. (Mielőtt valaki megjegyezné, igen, a POSIX kapcsolóknak, de még külön a GNU-nak is vannak guideline-jai, amikre szarik a git.)

PS: Amennyiben nem szarkazmusból, gúnyosan írtad, úgy igen, egyetértek veled, tényleg baj, hogy egy ilyen sokat használt tool bonyolult és kilóg a sorból.

Abban egyetértek, hogy a bazár jellegű fejlesztés miatt a git kissé eklektikusra sikerült. Valahol mélyen engem is zavarnak ezek a dolgok és hátráltatnak is (más példa, de pl. rendszeres UI redesignok, ikonok cserélgetése és átszínezése is lelassítja a munkát). De ez nem új keletű, már negyven éves a vicc, hogy a UNIX-ban ezen héten hogy hívják a PRINT parancsot. A fiatalok meg úgyis a VS Code-ban nyomkodnak, talán az elvesz a bonyolultságból, meg ott az AI is, ami ebben jó. 

Nem különítem el a célt és az eszközt, mert nem válogathatom meg az eszközt. Ha egy projekt gitben van és én azon dolgozom, akkor a feladat része, hogy a gitet is használni kell. Szerintem egy elosztott verziókezelőt nem lehet olyan egyszerűen megvalósítani, hogy kalapácshoz hasonlóan egyszerű legyen használni. Nem értem, hogy működik, és nem is érdekel, csak a használathoz szükséges alapelveket tanultam meg. Arra én is láttam példát a környezetemben, hogy mint fentebb, valaki aliasokkal számára logikusabbá teszi a parancsokat, az is egy jó módszer. 

más példa, de pl. rendszeres UI redesignok, ikonok cserélgetése és átszínezése is lelassítja a munkát

Ezt speciel sosem tapasztaltam. Mondjuk én mindig MVC-t implementáltam, így a megjelenítés átvariálásához csak egy sablont kell pofozgatni, programozni egyáltalán nem is kell. (Azzal egyetértek, hogy tényleg idegesítő, amikor folyton átvariálják az UI-t és hogy mennyire gyakori probléma ez, pont ezért is használtam mindig is sablon alapú megjelenítést, hogy ezzel ne szivassam meg magam.)

A fiatalok meg úgyis a VS Code-ban nyomkodnak, talán az elvesz a bonyolultságból, meg ott az AI is, ami ebben jó.

Hát igen, a mai fiatalok már semmit sem értenek a dolgok működéséből sajnos, csak kopipészt huszárok, a többit meg oldja meg nekik valami tool. Ez egy darabig megy, amíg magával a tool-al nincs probléma.

Nem különítem el a célt és az eszközt, mert nem válogathatom meg az eszközt.

Bizonyára ismered azt a mondást, ha valakinek kalapácsa van, az mindent szögnek néz. Még a csavart is.

Ha egy projekt gitben van és én azon dolgozom

Ez azért sántít picit, mert mára gyakorlatilag minden git-ben van, minden más scm megoldás kihalt. (És jó okkal, a git belseje remekül van kitalálva, technikai értelemben kenterbever minden más megoldást, ez nem vitás.) Szóval ha akarná az ember, akkor sem választhat verziókezelőt, mert nincs már más alternatíva.

Szerintem egy elosztott verziókezelőt nem lehet olyan egyszerűen megvalósítani, hogy kalapácshoz hasonlóan egyszerű legyen használni.

Biztos vagyok benne, hogy lehetne. A git a motorháztető alatt zseniálisan van megírva, az egyetlen baj vele, hogy direktben vezették ki a belső lelkivilágát a kapcsolókra, ahelyett, hogy a felhasználás szempontjából fontos kapcsolók lennének, amiket a git programnak kellene lefordítania libgit hívásokká, figyelembe véve a repó aktuális állapotát.

Jelenleg a git olyan, mintha UNIX parancsok helyett lenne egyetlen shell-ből hívható "syscall" program, aminek hexában kellene átadni a paramétereket. Mivel direktben van a belső világa a kapcsolókra leképezve, ezért egy nagyon fontos absztrakciós szint teljesen hiányzik belőle, erre értem, hogy ez a program hibája.

Megpróbálom egy hasonlattal érthetőbbé tenni, mire gondolok: ott az apt. Az "apt update" frissíti a listát (függetlenül attól, hogy mi van a motorháztető alatt, lokális CD repó vagy hálózat, ftp vagy https), az "apt install" pedig telepít (függetlenül attól, hogy meta csomag-e, konkrét csomag-e, mennyire kacifántos a dependency, stb.). A lényeg az, hogy a felhasználás szempontjából közelítve tervezték meg a kapcsolóit (ezért azokat tényleg bárki 10 másodperc alatt képes megjegyezni), és azok nem is változnak attól, hogy mi az épp aktuális konfig vagy állapot, na ezt a git-tel is simán meg lehetne tenni.

Konkrét példával: állítsuk be azt, hogy a "git push" csak jelszót kérjen, felhasználónevet ne! Ezt ssh kapcsolat esetén egyáltalán nem sikerült megoldanom. Https esetén az url-be rakható felhasználónév a szervernév elé, de ez csak akkor működik, ha az url egyébként ".git"-re végződik (legalábbis github-on és gitlab-on). Biztos megvan a belső lelkivilágából eredő oka ennek, na de ezt a git parancssornak el kellene fednie, ugyanis rohadtul nem intuitív, hogy az url felhasználónév részét kiterjesztéstől függően parszolja csak.

git clone https://user@gitlab.com/user/repo      - be fogja kérni a git push a felhasználót
git clone https://user@gitlab.com/user/repo.git  - csak jelszót kér majd a git push
Arra én is láttam példát a környezetemben, hogy mint fentebb, valaki aliasokkal számára logikusabbá teszi a parancsokat, az is egy jó módszer.

Sajnos nem ilyen egyszerű, mert a git-nél ismerned kell a repó állapotát, és attól függően kell különböző parancsokat kiadni (konkrét példa, a legelső "git push"-nak több kapcsolót kell megadni, mint egyébként, azaz a program helyett a fejlesztőnek kell odafigyelnie a repó belső állapotára, és attól függően más-más kapcsolókat használnia).

Ettől függetlenül tényleg nem lenne hülyeség ezeket a git cheat sheet-eket egy alias dotfájlba összegyűjteni, amit csak source-olni kell a bash profile-ból. Régen sok aliast használtam, de aztán valamiért leszoktam róluk. Igazából nem tudnám megmondani, miért, pedig ha mindent nem is lehet megoldani velük, tényleg elég sok esetet lefedésére alkalmasak. Lehet össze is dobok egy alias dotfájlt.

Konkrét példával: állítsuk be azt, hogy a "git push" csak jelszót kérjen, felhasználónevet ne! Ezt ssh kapcsolat esetén egyáltalán nem sikerült megoldanom.

Emlékeim szerint ezt a $HOME/.ssh/config fájlban tudod szépen bekonfolni. (Nem emlékszem, hogy ezzel bármilyen problémám lett volna, pedig régebben elég sokat dolgoztam ssh-n keresztül.)

Emlékeim szerint ezt a $HOME/.ssh/config fájlban tudod szépen bekonfolni.

Rosszul emlékszel. Ott nem tudsz git repónként más-mást beállítani. (Azaz csak akkor jó megoldás a $HOME/.ssh/config, ha egyetlen felhasználót használsz, akkor nem, ha többfélére van szükség.)

Szóval a sameserver.com-on van projekt1 és projekt2, az egyikben user1 vagy, a másikban user2?

Szerk: ha így lenne, akkor megpróbálnék felvenni a ~/.ssh/config-ban két szakaszt, hogy

Host sameserver-project1
  Hostname sameserver.com
  User git
  IdentityFile ~/.ssh/user1_prvkey

Host sameserver-project2
  Hostname sameserver.com
  User git
  IdentityFile ~/.ssh/user2_prvkey

A szerver webes felületen pedig a user1-hez a ~/.ssh/user1_pubkey-t állítanám be, a user2-höz pedig a ~/.ssh/user2_pubkey-t.

amennyire tudom minden ilyen rendszer a `git` user-t hasznalja SSH belepeshez, es a kliens altal kuldott kulcs alapjan donti el, hogy te ki vagy, es mihez van jogod. ez nem a git hianyossaga, hanem a gitlab/github implementacioja miatt van igy. Ha osszeraksz egy ssh szervert ACL-ekkel, akkor valoszinuleg mukodesre tudod birni, hogy a `<sajat usernev>@repopath` kapcsolat mukodjon.

Azt sem tudom, hogy gitlabot SSH-n lehet-e jelszo alapu hitelesitessel hasznalni.

Leírták/leírtuk hogy ez hogyan működik most gitlabon.
Nagyjából hasonlóan működik ez mindenhol máshol.

Szerintem érdemes látni hogy ezeknek az implementációknak (gitlab, github) már sokkal nagyobb a scope-ja mint a gitnek valaha is volt.

Ehhez már a gitnek semmi köze (a.k.a. rendszerhatárok).

Gábriel Ákos

Nem tudom, a .git kiterjesztésen akkor múlik, ha a túloldalon az ssh/http úgy van konfigurálva. Ennek igazából nem sok köze van a githez, ugye az áhított "egy dolgot csináljon, de az jól" harap vissza.

Mivel amit én láttam, ott eleve .git-tel copyzza ki a clone urlt, ha rákattintok, sose írtam be nélküle. Azt mondja, hogy az az url, akkor az az url :)

"Konkrét példával: állítsuk be azt, hogy a "git push" csak jelszót kérjen, felhasználónevet ne! Ezt ssh kapcsolat esetén egyáltalán nem sikerült megoldanom."

https://git-scm.com/docs/gitcredentials - mivel ha van path, akkor egyeznie kell, azt várom, hogy ssh-val is működik. Kipróbálni nem tudom, mert nincs több accom a githubhoz (annyit meg nem ér, hogy legyen).

Vagy:
 

GIT_SSH_COMMAND="ssh -l egyikuser"

GIT_SSH_COMMAND="ssh -l másikuser"

ez meg állítgatni ügyesen.

 

Manapság minden bonyolult és szar, amit nem lehet 10 másodperc alatt megérteni vagy nem lehet 3 mondatban elmondani.

Olyankent mondom, aki ismeri jol a gitet:

-10 masodperc alatt
+5 perc alatt egy amugy senior fejlesztonek

-3 mondatban
+max 2 A4-es oldalnyi plain text leirasban egy senior fejlesztonek (ami csak azert lehet ilyen hosszu, mert peldakodok kozti kulonbsegeket is osszehasonlit)

Igen. Minden bonyolult es szar, ami ezt nem pipalja ki. Eloismeretekre lehessen raepiteni ilyen nem tul lassu magyarazatokkal.

Akkor en egy tiszteletlen barom vagyok, vallalom. De nem fogadom el, hogy azok szartak ki a szakmankat, akik egy 600 oldalas, de hossza ellenere kozel semmire se jo szakkonyvet irtak, ami mar akkor elavult tudast tartalmazott, amikor kinyomtattak. :)

(De a masodperces ervekkel fentebb egyetertettem, lehessen a seniortol 5 perc raszanast demonstrativ pelda es ellenpelda ertelmezesere elvarni)

Szerintem a "parancssori kapcsolo UX" akkor is valid kerdeskor onmagaban. Fentebb irtam a Dockert meg a Kubernetes-t, mint gitnel is jobb peldat ennek hianyara: es nem irnanak hozza 30 frontendet, ha olyan intuitiv lenne, mint a regebben tervezett parancsok. :) Gitnel meg a Hevi kommentjeben listazott alias-okat tartom jo peldanak arra, hogy miert valos igeny, ami itt felmerult. Es ezt ugy mondom, hogy nekem ezekre a git eseten pont nincs szuksegem. A docker es a kubernetes miatt ertem meg azokat, akik a git parancssori kapcsoloit nem tartjak eleg intuitivnak. :)

Annyiban értek egyet hogy nekem sem triviális a git parancssor. Abban óvatos lennék hogy "lehetne-e jobban csinálni" mert én pl. nem tudnám. A git aliasok jó ötlet - addig amíg egy környezetben egy workflow-ban használod és pont ott pont úgy kell.

Amiben 100% egyetértek az a docker és a kubernetes commandline, azok teljesen hasonló trágyadombok, kubernetes különösen

De valójában ha körbenézel a mostani szoftverekből ez a fajta letisztultság és igényesség teljesen kiveszett..

Az agilitás sajnos nem támogatja az igényességet.

Gábriel Ákos

Tulajdonkeppen a leglenyegesebb dolgokban egyetertunk.

A vita egyetlen targya az, hogy hany perc/ora/oldal attention span elvarhato egy senior fejlesztotol egy uj dolog megtanulasara jelen jol fizeto munkaja mellett? Es ezzel szemben mennyire elvarhato, hogy legyen egy tomor oktatoanyag, cheat sheet, stb.

(Probaljuk meg a ma divatos "kepzesrol-lemaradas-szorongas" jelensege nelkul realisztikusan megvalaszolni - kivancsi volnek)

Miért "munkája mellett"?
Szerintem a munkája része kellene hogy legyen.

Open source + ingyenes "új dolgok"kal szemben szerintem nem fogalmazható meg elvárás - legalábbis nem úgy mint egy fizetős termékkel szemben - a.k.a. "szabad kontributálni" - és igen, a dokumentáció is egy igen jófajta kontribúció, nem csak a kód.

Gábriel Ákos

Goto 10
Ha a Jedi szent könyvekről lenne szó(*), akkor ez tök jogos lenne, de hogy egy verziókezelő program használatához vallásos áhítat kelljen, az talán túlzás.

(*)
Luke: Ezek szent Jedi-könyvek, hogy is képzeltem, hogy felgyújtsam őket?!
Yoda: Te talán olvastad őket?
Luke: Basszus, dehogy!

( bzt | 2025. 01. 20., h – 12:24 )

Szerkesztve: 2025. 01. 20., h – 12:26

Látom, a szokásos trollok befutottak. Mindenki figyelmébe: számoljuk meg, mennyi érdemi hozzáfűznivaló van a hozzászólásaikban!
És @gabrielakos szokás szerint nem szól rájuk, sőt, csak eteti őket. Ez amolyan adminperverzió lehet nála, gondolom, mert hát végső soron saját maga alatt vágja a fát azáltal, hogy hagyja a trollokat szabadon garázdálkodni. SZVSZ.

Hat ez csak nekem szolhatott, ugyanis gabrielakos egyetlen kommentet irt, es arra egyedul en valaszoltam.

Idorendben az elso kommentem teljes mertekben a temahoz kapcsolodott:

https://hup.hu/comment/3154822#comment-3154822

Nem reszleteztem, hogy altalaban barhol dolgozok, nekem szolnak hogy conflict van, mert folyton belefutok, hogy csak en ismerem a feloldasi modokat, meg hogy hol hibazhatnak a nevesebb IDE-k, es mar megtanultak, hogy en tudom.

-

Mint azt a másik hozzászólásomban jeleztem, nem, nem rád vonatkozott.

Sorolhatnék neveket, de felesleges, a legnagyobb baj, hogy gabrielakos moderátor egyetlen hozzászólása semmi témábavágót nem tartalmaz, nincs benne semmi szakmai, csak másokat próbál ócsárolni benne, mint egy TROLL. Ez bizony baj, ha egy moderátor így viselkedik.