Republic / Artiklar /

Artikeln uppdaterad 2020-05-26.
Skriven av Christofer Sandin.

Ver­sion­shanter­ing med Git

Vi hade använt Sub­ver­sion under en gan­s­ka lång tid, och det funger­ade väldigt bra, men efter­som alla de tuffa grab­bar­na och tje­jer­na kör dis­tribuer­ade ver­sion­shanter­ingssys­tem som Git eller Mer­cu­r­ial så tänk­te jag att vi skulle kika på hur man kom­mer igång med Git.

Det­ta är ingen kom­plett guide, utan snarare en lath­und med de van­li­gaste kom­man­dona och kon­cepten. Jag förut­sät­ter att du kan installera Git på egen hand och att du har lite koll på hur man använ­der ter­mi­nalen. Artikeln skrevs allt­så fram­förallt för vår egen del under tiden vi bytte till Git, men om någon annan får lite hjälp av den på sam­ma gång är det givetvis bara roligt.

En bät­tre miljö

En stor fördel med Git är att det är rel­a­tivt enkelt att ska­pa oli­ka grenar (branch­es) i ett pro­jekt. Det kan till exem­pel vara bra att ha en gren där du utveck­lar en ny funk­tion medan du har en gren där du bara gör bug­gfixar under tiden. När du sedan är färdig med den nya funk­tio­nen kan du slå ihop dessa två grenar, genom en så kallad merge, och på så sätt få med både bug­gfixar­na och den nya funktionen. 

En mer infor­ma­tiv prompt

En bra start är där­för att se till så du enkelt kan hål­la reda på vilken branch du arbe­tar med för tillfäl­let. Jag tyck­er att Devot:ee har en bra beskrivn­ing av hur du får en mer infor­ma­tiv prompt en bit ner i deras artikel om Git.

Även Net­Tuts har en bra artikel om du vill göra om din prompt.

Inställ­ningar

Sit­ter du som jag på en Mac och job­bar i Text­Mate är det lika bra att du även ser till så att Text­Mate är din för­val­da editor:

git config --global core.editor "mate -w"

Job­bar du i Sub­lime Text så är det föl­jande som gäller:

git config --global core.editor "subl -n -w"

Pas­sa även på att läg­ga till ditt namn och din e‑postadress:

git config --global user.name "Your Name"
git config --global user.email "your@email.com"

Ska­pa ett repos­i­to­ry lokalt

Det går utmärkt att använ­da Git lokalt på din dator när du utveck­lar egna pro­jekt. Även om Git givetvis kom­mer ännu mer till sin rätt i någon form av nätverk där flera per­son­er eller åtmin­stone oli­ka dator­er är inblandade är ett lokalt repos­i­to­ry ett bra sätt att lära sig.

Ska­pa ett nytt projekt

I ter­mi­nalen byter du till den kat­a­log som du vill ska­pa ditt pro­jekt i och kör:

git init

Nu ini­tieras pro­jek­tet och det ska­pas en kat­a­log som het­er .git. Till skill­nad från Sub­ver­sion som ska­par en .svn-kat­a­log i var­je pro­jekt-kat­a­log så finns det bara en .git-kat­a­log i pro­jek­tets rot-kat­a­log. Vill du ta bort ver­sion­shanterin­gen är det bara att ta bort den här dol­da katalogen. 

Ignor­era vis­sa fil­er i pro­jek­tet med .git­ig­nore

Ska­pa en fil som het­er .git­ig­nore i rotkat­a­lo­gen och lägg till alla fil­er du vill exk­lud­era i den­na. För ett Expres­sio­nEngine-pro­jekt kan den se ut såhär:

# cache files
.DS_Store
admin/expressionengine/cache/**/*

# config files
admin/expressionengine/config/config.php
admin/expressionengine/config/database.php

# uploaded images
images/avatars/uploads
images/captchas
images/member_photos
images/pm_attachments
images/signature_attachments
images/uploads

Håll koll med status

För att se vil­ka fil­er som är tillag­da, bort­tagna och redi­g­er­ade sedan föregående com­mit används kom­man­dot status:

git status

Läg­ga till fil­er i Gits index med add innan commit

När du sedan arbe­tat med dina fil­er är det dags att läg­ga till dessa i Gits så kallade index innan du kan göra en com­mit. Det­ta är ett extra steg jäm­fört med Sub­ver­sion, men är gan­s­ka prak­tiskt då du enkelt kan väl­ja ut vil­ka fil­er som skall ingå i sam­ma commit.

För att läg­ga till alla fil­er skriv­er du en punkt efter add:

git add .

Eller om du vill vara mer speci­fik kan du givetvis vara det:

git add .gitignore
git add *.php

För att även få med fil­er som du rader­at i pro­jek­tet kan du använ­da flag­gan ‑u, annars kom­mer dessa fil­er att synas var­je gång du kör en status:

git add -u

För att ta bort en eller flera fil­er som du lagt till med använ­der du:

git reset HEAD file1 file2 …

Därefter, dags för en förs­ta commit

När fil­er­na du vill läg­ga till är adder­ade med add så är det dags att göra en com­mit. Det­ta görs genom: 

git commit -m "This is a commit message"

En ny koll med sta­tus vis­ar att det nu inte finns några rap­porter­ade ändringar sedan senaste com­mit. Här är ett exem­pel på detta:

~/Sites/project (master): git status
# On branch master
nothing to commit (working directory clean)
~/Sites/project (master):

Ska­pa och slå ihop grenar

Som jag skrev inled­ningsvis så är en av de mest upp­skat­tade funk­tion­er­na i Git möj­ligheten att enkelt ska­pa och slå ihop oli­ka grenar av koden. Här är de grundläg­gande kom­man­dona. Van­ligtvis het­er de

Ska­pa en gren med bransch

För att ska­pa en ny gren, eller bran­sch som det het­er på engel­s­ka, så kör du:

git branch branchname

För att byta till en annan gren används:

git checkout branchname

Det­ta gör ock­så att alla fil­er i din arbet­skat­a­log ändras och du får en rep­re­sen­ta­tion av den aktuel­la grenens fil­er. För att se vil­ka oli­ka grenar som finns och vilken du arbe­tar med för tillfäl­let är det bara att knap­pa in:

git branch

Lägg ock­så märke till att den aktuel­la grenen hela tiden finns med i din prompt:

~/Sites/project (master): git checkout branchname
~/Sites/project (branchname): git checkout master
~/Sites/project (master):

Slå ihop

För att sedan slå ihop en gren med den aktuel­la grenen du arbe­tar med så använ­der du kom­man­dot merge på det­ta sätt:

~/Sites/project (master): git merge branchname

Det­ta skulle allt­så slå ihop grenen branch­name med den aktuel­la grenen master.

Och, slut­li­gen, ta bort en gren som inte används längre

~/Sites/project (master): git branch -d branchname

Lägg upp ett repos­i­to­ry på en serv­er som alla i pro­jek­tet kan kom­ma åt

Vi använ­der en extern serv­er för vis­sa av våra pro­jekt. Tjän­ster som Beanstalk och Springloops gör det enkelt för de som inte gillar kom­man­do­raden att log­ga in i web­b­gränss­nit­tet och se vad som händer. 

För att läg­ga upp det repos­i­to­ry du ska­p­at lokalt läg­ger du först till ett nytt pro­jekt i Beanstalk. 

Lokalt läg­ger du sedan till Beanstalks serv­er i ditt git-projekt:

git remote add beanstalk git@republicfactory.beanstalkapp.com:/project.git

vilket läg­ger till föl­jande rad­er i din .git/­con­fig-fil:

[remote "beanstalk"]
url = git@republicfactory.beanstalkapp.com:/project.git
fetch = +refs/heads/*:refs/remotes/beanstalk/*

Nu kan du allt­så använ­da beanstalk istäl­let för git@republicfactory.beanstalkapp.com:/project.git.

När du sedan gjort ändringar lokalt, kört add och com­mit kan du nu köra push för att läg­ga till dina ändringar till ditt repos­i­to­ry hos Beanstalk. Det­ta funger­ar pré­cis på sam­ma sätt till vilken annan serv­er som helst.

git push beanstalk master

Klona ett repos­i­to­ry till en annan server

Har man sedan en utveck­lingsserv­er som går att kom­ma åt via SSH så är det bara att log­ga in där, ska­pa en ny kat­a­log och klona pro­jek­tet från Beanstalk. Det­ta kan jäm­föras med att man ​”checkar ut” ett repos­i­to­ry med Git:

git clone git@republicfactory.beanstalkapp.com:/project.git .

Punk­ten på slutet gör så att du ska­par .git-kat­a­lo­gen i den kat­a­log där du står istäl­let för att det repos­i­to­ry du checkar ut ham­nar i en egen kat­a­log. För att sedan hål­la utveck­lingsservern upp­dat­er­ad med de ändringar som är com­mi­tade till Beanstalk är det bara att köra:

git pull

Du kan givetvis ock­så klona ett repos­i­to­ry på din lokala dator och hål­la det­ta upp­dat­er­at genom git pull.

Ref­er­enser

Jag har inte använt Git under någon län­gre tid och den här lil­la lath­un­den kom­mer att upp­dat­eras då och då. Det är på lån­ga vägar inte allt som man kan göra, men det ger i alla fall en liten intro­duk­tion. Nedan finns en lista med intres­san­ta artik­lar om du vill läsa mer om Git.