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.

Ü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.

( 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.

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.