Vilken versionshanterare använder ni?

Permalänk
Medlem

Vilken versionshanterare använder ni?

Som det står i rubriken: Vilken versionshanterare använder ni till ert projekt/arbete? Detta gäller både programmering och digitalt skapande.

Själv använder jag Git när jag kodar. Smidigt och enkelt

Innan jag fick höra talas om versionshantering så syncade jag mina filer via Google Drive. Det fungerade...inte bra...

Permalänk
Inaktiv

TFS och GIT. Ja föredrar TFS då jag anser den är så användarvänlig för enkla saker, ofta ska alla tekniker versionshantera sina filer och TFS skiljer sig knappt ifrån hur man jobbar med vad som helst.

Permalänk
Medlem

Gör jag något litet använder jag bara CTRL Z (Sublime sparar ändringar väldigt länge)

Gör jag något väldigt dramatiskt, typ ta bort en stor bit kod, duplicerar jag filen och byter namn på en av dem till "program (backup innan *stor ändring*).ext"

Har jag gjort en enorm tabbe går jag in på Dropbox historiken och återställer på det sättet

Visa signatur

13600KF, RTX 4070 FE, B760I, 32GB DDR4, NR200P

Permalänk
Medlem

Mercurial.

Permalänk
Hedersmedlem

Enbart Git.
Samt om jag ska göra någon stor grej, framför allt komplexa Git-kommandon som jag är känner mig osäker på, så kör jag ofta fulvarianten med copy+paste på hela projektmappen, i fall att.

Visa signatur

Asus ROG STRIX B550-F / Ryzen 5800X3D / 48 GB 3200 MHz CL14 / Asus TUF 3080 OC / WD SN850 1 TB, Kingston NV1 2 TB + NAS / Corsair RM650x V3 / Acer XB271HU (1440p165) / LG C1 55"
Mobil: Moto G200

Permalänk
Inaktiv
Skrivet av lambdan:

Gör jag något litet använder jag bara CTRL Z (Sublime sparar ändringar väldigt länge)

Gör jag något väldigt dramatiskt, typ ta bort en stor bit kod, duplicerar jag filen och byter namn på en av dem till "program (backup innan *stor ändring*).ext"

Har jag gjort en enorm tabbe går jag in på Dropbox historiken och återställer på det sättet

Nu vet jag inte vad du sysslar med, men ditt sätt gör många i skolan. I arbetslivet bör man dock skarpt unvika det av hur många orsaker som helst. Med riktig versionshantering kan man enkelt spåra buggfixar och det går fint att kanske 20st är inne och kodar i samma projekt samtidigt.
Nu jobbar jag inte i större projekt, men jag vet folk som använder sig av byggservrar, så om någon checkar in koden kompilerar servern koden, kör unitstest etc och skickar tillbaka en felrapport vid fel.
En klassiker är annars att en person ska gå iväg till något viktigt precis innan gör en incheckning som ej är kompileringsbar och folk sitter kvar och jobba och sedan upptäcker detta och ropar f-n..

Jag arbetade för tag sedan på en skarp server där det var något liknande, man skulle driftsätta olika koder i en gemensam lösning och det var en 30 personer från olika konkurrerade företag som driftsatte sina nya koder samtidigt.
Där det vid fel så ville de ha tillägg för detta och man kunde få betala kostnaden för detta.

Vad jag har förstått så under många IT utbildningar på högskola nu 2008 så jobbar de inte ens med versionshantering och flera personer i samma projekt samtidigt, vilket är väldigt konstigt. YH utbildningar är det mer självklart.
Om 10år alltså år 2018, så förstår jag ej hur programmeringslärare på högskolor som ej lär ut detta kan sova om nätterna. Det är ju inget teknisk komplicerat på något sätt. Det borde snarare vara ett krav för att eleven ska få godkänd, är koden ej versionshanterad så blir det ett IG även om det är en ny Mindcraft som studenten har gjort.

Permalänk
Medlem

@anon159643: Jag jobbar inte "professionellt" med programmering så det är lugnt för min del. Det är bara något jag håller på med på fritiden (mest min egna blogg/hemsida).
Jag använder dock github för att dela med mig av koden, men jag har det bara för grova milestones. Jag använder inte flera branches osv, vilket jag bör göra.
Jag satte även upp en egen git server engång, och använde det någon enstaka gång, men sedan gick det ett tag och jag glömde kommandona och inte använt den sedan dess.

Visa signatur

13600KF, RTX 4070 FE, B760I, 32GB DDR4, NR200P

Permalänk
Medlem

Använder mig av GoodSync, då det är det enda (som jag har hittat efter många sökningar) program som stödjer synkronisering genom Google Drive, Dropbox, SFTP, FTP och en drös med fler metoder.

Visa signatur

Citera mig om du vill att jag ska hitta till ditt svar.
airikr.me /device:desktop. Andra projekt: Keizai, Koroth & Serenum.

Permalänk
Hedersmedlem

Jag minns att jag bildligt talat singlade slant en gång i tiden om ifall jag skulle köra Mercurial eller Git till ett projekt. Det var då dessa användes ungefär lika mycket i världen och Google Code fortfarande var mer naturligt än GitHub. Det blev Mercurial för mig, möjligen med viss anledning av att det själv och dess standardwebbgränssnitt var skrivet och enkelt expanderbart i Python, samt att det kändes rätt mycker mer polerat vid tillfället. Efter det beslutet så blev det Mercurial av bara farten under flera år.

Med tiden och framför allt med GitHubs uppgång så är väl användarfördelningen mellan Git och Mercurial nu snarare 95/5 eller så till Gits fördel, och i och med att projekt jag var delaktig i använde Git mer och mer så gled jag över till att även köra detta för egna projekt (misstänker att jag inte kört hg init sedan ~2015). Jag lekte ett tag med saker som hg-git för att kunna jobba mot Git-projekt med Mercurial-klienten, men det kändes snabbt vettigare att bara köra Git direkt.

Jag använder nu enbart Mercurial i legacy-syfte för en del äldre projekt, och jag har även konverterat historiken för en del projekt från Mercurial till Git.

För egen del så kan jag väl efter att ha använt båda varianterna hyfsat mycket konstatera att jag inte skulle ha något problem att hamna i projekt med endera system, men att jag personligen inte ser någon anledning att gå tillbaka till Mercurial igen om jag får välja. Gits inlärningskurva må vara brantare, men det känns som att när bara väl ett fåtal grundkoncept sitter så har man all kontroll i världen över varenda liten detalj.

Några noterbara skillnader som jag upplever mellan Mercurial och Git:

  • Gits grenkoncept känns för mig vettigare än Mercurials (som visserligen har mer eller mindre ekvivalenta "bookmarks", men de känns inte som "första klassens medborgare" på samma sätt). Gits grenar ger en större frihet i att skulptera repografen så som man vill ha den, och de saker som Mercurial-liknande "named branches" å andra sidan ger (typiskt metadata om på vilken gren en viss commit gjordes) känner jag inte ger mig något extravärde, så länge som Git används på ett ansvarigt sätt. Då tar jag hellre styrkan med att kunna jonglera hur som helst med commit-objekten, utan att känna att jag jobbar emot verktyget på något sätt.

    (En annan feature med Gits grenkoncept är att SVN-rävar får en "reality check" och inte tror att det bara är att tuta och köra som tidigare .)

  • Att Git så explicit skiljer på arbetsträd, index och repo och lämnar över kontrollen till användaren känner jag synkar bättre med hur jag själv tänker på versionshantering. Möjligen mitt mest använda Mercurial-kommando var hg record för att göra partiella commits, vilket var en "extension" snarare än en fundamental del av verktyget med en rätt bökig implementation jämfört med git commit -p och dess kompisar (inte minst så bröt hg record hårdlänkade filer utifrån hur det är implementerat – brasklapp för att jag inte använt detta sedan det inkorporerades i grundutbudet som hg commit --interactive).

    Min tolkning är att Mercurial medvetet försöker hålla abstraktionen enklare, men efter att ha jobbat med alternativet så tycker jag personligen att det känns som en otjänst för användaren över tid.

I andra vågskålen kan man lägga att Git åtminstone tidigare kändes rätt oborstat jämfört med Mercurial, men generellt känns det som något som jobbas aktivt med att förbättra genom att lägga till lite mer lättförståeliga alias för att få ett mer enhetligt gränssnitt. Git ger också användaren en laddad och osäkrad hagelbössa i handen med vilken det inte är några som helst problem att skjuta sig i foten på ett sätt som jag aldrig känt Mercurial göra.

För att återkomma till en annan punkt ovan så är Git rätt skoningslöst mot de som inte tar sig över inlärningströskeln och åtminstone börjar förstå hur en commit byggs upp. Mercurials förenklade gränssnitt där "indexet" är mer dolt för användaren är nog lättare att resonera kring direkt.

Sammanfattat så kan nog Git- och Mercurial-användare samsas ganska väl i samma religiösa samfund. Så länge ingen föreslår att man ska använda något annat så kan högaffeln få stå kvar på sin plats…

Visa signatur

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Permalänk
Hedersmedlem
Skrivet av Thomas:

Enbart Git.
Samt om jag ska göra någon stor grej, framför allt komplexa Git-kommandon som jag är känner mig osäker på, så kör jag ofta fulvarianten med copy+paste på hela projektmappen, i fall att.

Du har alltid ref-loggen som livlina – våga hoppa!

Visa signatur

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Permalänk
Inaktiv

Använder Git.

Permalänk
Medlem

Git till 99%. Linuxdistributionen Debian har nyligen gått från samarbetsplattformen alioth som körde Fusionforge (som har stöd för Bazaar, Mercurial, SVN och allt annat) - till Gitlab som endast stöder Git.

Permalänk
Medlem

Använder Git tillsammans med GitHub. Tycker det är väldigt smidigt och enkelt att hantera sin källkod och kunna delta i andras projekt

Visa signatur

AMD R5 1600 3.2 GHz | Gigabyte AX370 Gaming K3 | Corsair Vengeance LP 2x8GB 3200MHz CL16 | Sapphire RX580 Nitro+ 8GB | Phanteks Eclipse P400S | 1x Samsung 970 EVO 500GB 1x WD 500GB | Windows 11 Pro

Permalänk
Medlem
Skrivet av anon159643:

Nu vet jag inte vad du sysslar med, men ditt sätt gör många i skolan. I arbetslivet bör man dock skarpt unvika det av hur många orsaker som helst. Med riktig versionshantering kan man enkelt spåra buggfixar och det går fint att kanske 20st är inne och kodar i samma projekt samtidigt.
Nu jobbar jag inte i större projekt, men jag vet folk som använder sig av byggservrar, så om någon checkar in koden kompilerar servern koden, kör unitstest etc och skickar tillbaka en felrapport vid fel.
En klassiker är annars att en person ska gå iväg till något viktigt precis innan gör en incheckning som ej är kompileringsbar och folk sitter kvar och jobba och sedan upptäcker detta och ropar f-n..

Jag arbetade för tag sedan på en skarp server där det var något liknande, man skulle driftsätta olika koder i en gemensam lösning och det var en 30 personer från olika konkurrerade företag som driftsatte sina nya koder samtidigt.
Där det vid fel så ville de ha tillägg för detta och man kunde få betala kostnaden för detta.

Vad jag har förstått så under många IT utbildningar på högskola nu 2008 så jobbar de inte ens med versionshantering och flera personer i samma projekt samtidigt, vilket är väldigt konstigt. YH utbildningar är det mer självklart.
Om 10år alltså år 2018, så förstår jag ej hur programmeringslärare på högskolor som ej lär ut detta kan sova om nätterna. Det är ju inget teknisk komplicerat på något sätt. Det borde snarare vara ett krav för att eleven ska få godkänd, är koden ej versionshanterad så blir det ett IG även om det är en ny Mindcraft som studenten har gjort.

Där jag studerade så gjordes alla projekt med git samt github och på så sätt kunde även läraren gå in och titta exakt vad alla har gjort i projektet med tanke på vad man checkar in och comittar under hela förloppet. Förstår inte hur man _inte_ kan jobba på det sättet i ett projekt, låter så sjukt jobbigt att arbeta utan versionshanterare.

Visa signatur

"Happiness is only real when shared"

Permalänk
Tangentbordskonnässör

Git och TFS. Skulle jag få välja själv är det Git som gäller för hela slanten, TFS är ju bara osmidigt.

Permalänk
Medlem

Vi kör endast git

Skickades från m.sweclockers.com

Permalänk
Medlem

GIT för det mesta, SVN för RANCID

Permalänk

SVN mestadels. En del TFS också beroende på projektets storlek.

Visa signatur

På tok för många datorer för att skriva här

Permalänk
Medlem

Enbart Git, men det är nog mest för bekvämlighets skäl, de allra flesta kan ju redan det så blir enklast så. För egen del kör jag enbart git då min Github blir mitt portfolie, så vill bygga vidare det. Är ju trevligt för framtida arbetsgivare att kunna se att man brukar koda på fritiden.

Skrivet av sebbeharry:

Där jag studerade så gjordes alla projekt med git samt github och på så sätt kunde även läraren gå in och titta exakt vad alla har gjort i projektet med tanke på vad man checkar in och comittar under hela förloppet. Förstår inte hur man _inte_ kan jobba på det sättet i ett projekt, låter så sjukt jobbigt att arbeta utan versionshanterare.

Smidigt. Tyvärr ville de flesta av våra lärare att vi zippade koden eller kopierade in det i ett word dokument(!) där formateringen dessutom blir helt förstörd.

Permalänk
Medlem

"En annan feature med Gits grenkoncept är att SVN-rävar får en "reality check" och inte tror att det bara är att tuta och köra som tidigare :-)"

Vi använder SVN på jobbet, jag lärde mig grunderna i GIT i plugget för några år sedan men det sitter ganska långt inne nu.. Vad är det för reality check jag skulle riskera att stöta på menar du?

Skickades från m.sweclockers.com

Permalänk
Medlem

Använder Git, SVN och Mercurial i yrkeslivet. Har även varit med och migrerat mellan dessa med bibehållen historik. Känner mig inte direkt bunden till någon av dem på personligt plan.

För 15 år sedan kom jag även i kontakt med Visual Source Safe. Det kändes inte direkt seriöst

Skickades från m.sweclockers.com

Visa signatur

Windows 11 Pro | Intel i7 8700 | ASUS Prime Z370-P | Corsair 16GB 3000MHz | ASUS GTX 1080 | Fractal Design Define S | Corsair RM750x | Hyper 212 EVO

Permalänk
Medlem

På min avdelning på jobbet används CVS för källkod, vet också att en annan avdelning kör Git. Vi har tidigare också använt SVN för dokument, men bytte för något år sedan till Doxis Wincube (klienten alltså, ingen aning vad som ligger bakom) iom att vi gick över till SAP.

Visa signatur

Redbox: Asrock B650 Lightning ATX, 7800x3D -20CCO, XFX 6950XT, 2x32GB Corsair Vengence 6400 CL32, WD SN770 2TB, Corsair RMe 1000, Lian Li Lancool 216, Peerless Assassin 120 SE
Purpbox: Z87-Pro, I5 4670K@4.2, Sapphire 290 TRI-X, 2x8GB Crucial Tactical@stock, Deep Silence 1
Samsung Evo 250+500GB + QVO 1TB, 2x1TB 7200RPM backup/lagring
Det var bättre förr: E5300 2600MHz -> 3640MHz, Celeron 300A -> 450MHz

Permalänk
Medlem

Nu för tiden använder jag git, både privat och på jobbet. Men genom åren har jag jobbat med lite av varje som mercurial, svn, cvs och clearcase.

Visa signatur

Arch | 1440p 165Hz IPS | 7800X3D | 1080ti | 64GB@6GHz | SN850 2TB

Permalänk
Medlem

Kör enbart GIT numera.
Automatiska byggen med Jenkins.
Gerrit för kodgranskning.
SonarQube för automatisk kvalitetsgranskning av koden.

Visa signatur

I am not a politician and my other habits are also good.

Permalänk
Hedersmedlem
Skrivet av mmarks:

"En annan feature med Gits grenkoncept är att SVN-rävar får en "reality check" och inte tror att det bara är att tuta och köra som tidigare :-)"

Vi använder SVN på jobbet, jag lärde mig grunderna i GIT i plugget för några år sedan men det sitter ganska långt inne nu.. Vad är det för reality check jag skulle riskera att stöta på menar du?

Även om SVN och Git på något plan har samma slutmål i att hantera revisioner av data, så skiljer sig den fundamentala designen sig åt ordentligt. Just när det handlar om vad båda dessa system menar med "grenar" så blir det extra tydligt.

Generellt så kan man i SVN prata om att "klona en gren", en "gren" är lokalt representerad som en separat katalog i filsystemet (och existerar i någon mån inte ens lokalt förrän den checkas ut), en "gren" är något som sköts av servern (eftersom SVN per design är ett centraliserat system) och en "commit" är alltid kopplad till en "gren". Inget av detta gäller i Git .

I Git är en "gren" bara en referens till en viss punkt i commitgrafen, som är det fundamentala objektet. En gren är bara ett "human readable" alias för en viss commit (jag brukar använda liknelsen "post-it-lapp"), med egenskapen att detta alias automatiskt följer med om du gör en ny commit på grenen* (post-it-lappen flyttas). Varje klon av ett repo inkluderar typiskt den fulla grafen så som den är känd vid tillfället av källan, samt en ögonblicksbild av referenser in i grafen (grenar och taggar) och dessa referenser kostar egentligen aldrig något i sig — allt som kostar är objekt som hör till de commits som hålls vid liv av de referenser som finns för stunden. Git Branching — Branches in a Nutshell för att se vad dokumentation själv säger.

Beroende på sin design är merge, rebase, etc., mellan grenar mindre dramatiskt i Git ("det bara fungerar" i mycket större utsträckning) vilket gör att utvecklare lockas att arbeta annorlunda, på ett sätt som jag skulle hävda också är "bättre" när det gäller versionshantering av kod. Featuregrenar och "pull requests" kan utan problem leva parallellt utan att någon behöver känna ångest inför vad som händer på huvudspåret för stunden, eller hur snirklig historiken kommer se ut när man väl är klar med kodgranskningen. "Grenar på grenar" och "pull requests till pull requests" är vanligt att se, utan att någon behöver känna sig begränsad under utvecklingen.

När man skapar en gren i Git är det en rent lokal operation. Att skapa en gren tar inte mycket längre tid än det tar att skriva 40 byte (OK, lite metadata också ) till disk, men vi snackar millisekunder även om din dator har en dålig dag. Att pusha en gren uppströms är också en smal sak: om den pekar på en commit som redan finns i grafen på fjärrsidan så är det återigen bara en post-it-lapp med ett namn och en commit-hash på som behöver pushas — nätverkslatensen för att sätta upp anropet är sannolikt det som tar majoriteten av tiden i dessa operationer. Om grenen pekar på delar av grafen som ännu inte finns uppströms så skickar man detta också, och någon som hämtar ögonblicksbilden från ett repo får alla dessa delar lokalt direkt.

Utan att fastna i detta för mycket så är en av SVNs "talking points" att det går "snabbt" att skapa grenar där också (om man gör "rätt") jämfört med CVS, men dels är "snabbt" relativt (och Git är bra mycket snabbare ), och dels är det egentligen inte skapandet av grenar som är det viktiga, utan hur snabbt det går att hantera dem därefter, och inte minst sammanfoga i ett senare skede.

När CVS (som SVN ärver mycket av sin design från) designades så var idén om fulla kopior på allas datorer orimlig beroende på nätverkshastigheter och lagringskapacitet ("Menar du att jag ska behöva ladda hem och lagra 50 kB extra bara för att Olof ändrat fem filer i sin temporära gren?!"), men idag är det otvivelaktigt så att sättet SVN arbetar på är mycket långsammare än distribuerade system i egentligen alla rimliga fall för källkodslagring†.

Typiskt när man jobbar i Git så ser den lokala ögonblicksbilden av grenarna annorlunda ut än hur andra ser på saken. En commit på en gren (som primärt innebär att man utökar commitgrafen, samtidigt som grenens referens automatiskt uppdateras till att peka på den nya committen) sker alltid lokalt. Det går snabbt, och ingen annan behöver ens veta något‡. Utvecklare masserar om grenar kontinuerligt för att kunna skulptera den mest användbara bilden av historiken för eftervärlden.

(Mercurial är mer likt Git, men även Git och Mercurial skiljer sig i hur de ser på "grenar", där det Mercurial kallar "bookmarks" är mer likt det Git menar med "gren", likt jag nämnde i ett tidigare inlägg. En vanligt arbetssätt i Mercurial är att man klonar hela repot när man checkar ut eller skapar en ny gren, och när en commit görs så sparas information om grenen i själva committen, vilket har större analoger med SVN, även om grunddesignen mellan systemen egentligen skiljer sig lika mycket som SVN och Git.)

Torvalds tidiga presentation om Git för Googles utvecklare fokuserar en del på hur grunddesignen skiljer sig:

Skrivet av Linus Torvalds:

If there are any SVN users in the audience, you might want to leave, because my hatred of CVS has meant that I see SVN as being the most pointless project ever started.

Edit: Jag tittade genom ovanstående klipp nu igen, och det var nästan ännu bättre än vad jag mindes. Extra intressant är det att höra hur saker har ändrats på de 10 åren sedan klippet spelades in. De flesta hade inte ens hört talas om Git, och bara någon enstaka person i publiken visste ens om något företag som använde ett distribuerat versionshanteringssystem i skarp produktion.


*: Jag minns att jag först verkligen insåg hur enkel en gren i Git var när jag märkte att man kunde stå på en gren och bara köra git reset --hard godtycklig-referens för att på alla sätt övertyga hela systemet om att min gren nu pekade någon helt annanstans. Det finns ingen magisk extrasås någonstans: en gren är en pekare in i grafen, och ändrar jag vart den pekar så har jag ändrat allt grenen står för.

——

†: Det finns vissa atypiska användningsområden där SVN fortsätter leva — exempelvis i projekt som versionshanterar stora binärfiler (vanligt i exempelvis modellbaserad utveckling) där antagandet att nätverksöverföring och lokal lagring är "dyrt" fortfarande kan gälla. Personligen är jag snabb på att argumentera för att ett arbetssätt som bygger på samarbete kring versionshantering av binära blobbar är felaktigt från grunden och att de som tycker det är en bra idé bör ta en ordentligt funderare på sina utvecklares välmående (typiskt är operationer som merge, rebase och ens diff döda (eller åtminstone otroligt ineffektiva) i ett sådant arbetssätt, vilket gör att hela idén med versionshanteringssystem får en rätt stor smäll). Man kan självkritiskt ställa sig frågan varför majoriteten av världens mjukvaruutvecklare så snabbt migrerade till distribuerade system.

Det finns också Git LFS som adresserar många av dessa saker i en Git-kontext, om man strikt vill hålla kvar vid sina binära blobbar.

——

‡: Detta nämner SVN-material ibland som en fördel för centraliserade system, då exempelvis SVN "tvingar" alla att publicera sina grenar kontinuerligt, så att novisa programmerare inte i sin blyghet inför att visa upp sitt arbete hellre jobbar parallellt i tysthet med egna spår. Om något skulle jag argumentera för den direkta motsatsen, där det enda detta leder till är att de som inte vågar visa sitt arbete då helt går utanför versionshanteringssystemen och jobbar med "en katalog på min dator"-systemet vilket bara blir sämre för alla parter. Jag har åtminstone själv inte upplevt den hypotetiska situation SVN försöker adressera med detta argument.

Visa signatur

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Permalänk
Medlem

@phz: Oj, stort tack för givande inlägg! Försöker lära mig mer om designen bakom Git och "hur man ska tänka" kring vad Git egentligen gör bakom kulisserna. Det längsta jag kommit när man går bakåt i grafen är att man flyttar en pekare(?) och där HEAD är pekaren/noden som pekar på den första elementet/commiten i grafen. Längre än så har jag inte kommit. (skulle säga att jag precis lämnat nybörjarstadiet efter att man lärt sig att hantera branches, commits, stash, logs, resets, merges etc.)

Till er andra som vill fördjupa era kunskaper i Git så kan jag rekommendera dessa:
Den officiella Git boken (är själv på kapitel 2 just nu)
Se hur var olika kommandon aktiveras
Fusklapp till viktiga kommandon
Git officiella dokumentation
https://www.tutorialspoint.com/git/git_tutorial.pdf

Permalänk
Hedersmedlem
Skrivet av Alotiat:

Försöker lära mig mer om designen bakom Git och "hur man ska tänka" kring vad Git egentligen gör bakom kulisserna. Det längsta jag kommit när man går bakåt i grafen är att man flyttar en pekare(?) och där HEAD är pekaren/noden som pekar på den första elementet/commiten i grafen. Längre än så har jag inte kommit. (skulle säga att jag precis lämnat nybörjarstadiet efter att man lärt sig att hantera branches, commits, stash, logs, resets, merges etc.)

HEAD är en referens som precis som alla andra referenser pekar på en viss commit i en given stund. Det som är speciellt med HEAD är att den alltid pekar på den commit du just nu har utcheckad i ditt arbetsträd. Om du checkar ut någon annan commit så hoppar HEAD med.

HEAD kan användas för sin egen skull (om man inte anger någon referens så är HEAD ofta defaultvärdet för kommandon), men kanske än oftare i angivelser som exempelvis HEAD^, där ^ betyder "första förälder". HEAD^ betyder alltså "(första) föräldern till den commit jag har utcheckad just nu", vilket är användbart i många sammanhang.

Något som kan vara intressant att fundera på är huruvida det — på samma sätt som att ^ pekar på en förälder — finns någon generell beteckning för "barnet" till en commit, och (spoiler!) varför inte . Det är relaterat till att när man läser manualerna så visar de ofta pilar som till en början kanske mot intuitionen alltid pekar "bakåt" till föregående commits, men aldrig "framåt" längs någon sorts tänkt tidsaxel (Git bryr sig för övrigt generellt väldigt lite om tid). Det finns helt enkelt ingen information i en commit om vilka "barn" den skulle ha: Git beskriver en riktad graf (acyklisk, dvs utan "loopar") där varje commit förr eller senare når en rot-nod i grafen. Man kanske tycker att den intuitiva "riktningen" på ens commits är från roten fram till den senaste, men det vore inte vettigt för ett distribuerat system.

En annan intressant sak att fundera på är att exempelvis skapa en gren, göra en commit på grenen, notera denna commits SHA1-hash och sedan ta bort grenen igen. Är denna nya commit nu "borta"? Testa med git show commit-hash — den var tydligen kvar, men var? Den syns ju inte längre i git log..? Kan man checka ut committen, och i vilket stadie befinner man sig då? Kan man få tillbaka sin gren?

Poängen med ovanstående övningar är att om man är bekväm med hur Git arbetar så är de uppenbara att svara på, och om Gits beteende känns märkligt så betyder det att det är något man missat .

Vill man lära sig mer om Git från grunden så rekommenderar jag också att rota runt lite i .git-katalogen i ett projekt och leka med git cat-file -p. Gits design är i grunden väldigt enkel, vilket är mycket av dess styrka — Torvalds såg bara till att få till rätt design i grunden (hashsumma på allt i alla lägen, försök inte vara smart och lagra diffar eller liknande, utan fokusera bara på att vara "the stupid content tracker", men gör det bra) och sedan löste sig resten organiskt.

Skrivet av Alotiat:

Den officiella Git boken (är själv på kapitel 2 just nu)

Personligen tycker jag att just den boken räcker i stort sett hela vägen för att lära sig så mycket som går att lära sig "teoretiskt" i Git. Har man bara fått rätt idé om några grundkoncept som beskrivs i den boken så kan man sedan i praktiken hugga vilken manualsida och förstå innehållet, och sedan är det bara att använda Git så kommer resten in (ingår i phzs teori om Git-inlärning ).

Jag brukar uppmana personer att hitta ett sätt att visualisera commitgrafen (exempelvis git log --graph --all --oneline --decorate) och sedan inför varje kommando som förändrar grafens tillstånd på något sätt (merge, fetch, pull, push, rebase, checkout, branch, tag, …) förutspå vad som kommer förändras, och verifiera att det blev som tänkt. Det tränar snabbt upp rätt mental bild av vad som händer.

Alternativt kan man alltid arbeta enligt:

Visa signatur

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.