Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Praktisk livredning med git Miniseminar NTNU, 22. september 2011 Åsmund Eldhuset.

Liknende presentasjoner


Presentasjon om: "Praktisk livredning med git Miniseminar NTNU, 22. september 2011 Åsmund Eldhuset."— Utskrift av presentasjonen:

1 Praktisk livredning med git Miniseminar NTNU, 22. september 2011 Åsmund Eldhuset

2 Hvem kjenner seg igjen her?

3 Hvorfor?  Hvor mange har samarbeidet om koding/dokumentskriving og løst det ved å... –Kreve at alle må være fysisk til stede og samarbeide om det samme fysiske dokumentet –Ha et delt dokument og kreve at bare én jobber av gangen –Ha et delt dokument som man kopierer hver gang man skal jobbe med det, eller ett dokument per person, og én person som har som jobb å lime sammen alle endringer  Hvor mange har backups av formen Versjon1.doc, Versjon1.5.doc, Versjon2.doc, Versjon2_korrigert.doc, Versjon_ doc, Versjon doc, Versjon2_slettes.doc,...?  (Hvis noen har brukt Dropbox, er det et godt stykke bedre, men git er et enda bedre alternativ, så lenge man jobber med ren tekst)

4 Hva er et versjonskontrollsystem?  Et system for å holde styring på... –Programkode –HTML og CSS –LaTeX-dokumenter –Hva som helst som er ren tekst  Vedlikeholder en fullstendig historikk over alle endringer –Kan spole tilbake til en tidligere tilstand –Kan vise hvem som har gjort endringer  Kan la folk jobbe på de samme filene samtidig uten å forstyrre hverandre –Endringene slås automatisk sammen etterpå

5 Git vs. andre versjonskontrollsystemer  Versjonskontrollsystemer kan være... –Sentraliserte –SVN, CVS, TFS,... –Historikken finnes på en sentral server; nesten alle operasjoner går mot denne –Distribuerte –Git, Mercurial, Bazaar,... –Hele historikken finnes lokalt; fleste operasjoner gjøres lokalt –Kan likevel samarbeide via en sentralisert server  Distribuerte systemer er generelt sett mer fleksible  Git er ekstremt kraftig, men... –Brattere læringskurve –Litt lettere å skyte seg selv i foten  Mercurial (Hg) ligner på git, men er lettere (se hginit.com)hginit.com

6 Installasjon  Anbefaler MSYSGit med GitExtensions  Litt knot på Windows, men går stort sett bra  Må sette opp PuTTY, PuTTYgen og Pageant hvis du skal jobbe mot en server

7 git config  git config --global user.name "Aasmund Eldhuset"  git config --global user.  Kan gi problemer hvis Windows-brukernavnet ditt inneholder norske bokstaver (men det funker fra GitExtensions sitt config-vindu) – Dropp --global og konfigurer per repository i stedet

8 git init – get it going!  Lager et nytt repository i mappen du står i  Et repository inneholder den magiske.git -mappen; ikke rør innholdet her –Unntatt.git/config hvis du føler deg barsk –Repositoryet er en slags database som inneholder historikken til alle filene  Alt utenfor.git kalles for working directory; inneholder den nåværende tilstanden til alle filene dine –Det finnes mange operasjoner for å sammenligne working directory med repository  git init --bare lager et repository, men ingen working directory (bra å bruke dette på servere)

9 git status  Viser forskjellen mellom working directory og siste commit i repositoryet

10 git diff  Viser hvordan innholdet i filene i working directory er forskjellig fra den siste committen

11 git add  Registrerer nye eller endrede filer i staging area / index, som er et område man bruker til å forberede en commit  git diff --cached viser hvilke endringer som ligger i staging area  Det går også an å registrere bare deler av en fil: git add -p filename

12 git commit  Registrerer alle de stagede endringene som én commit / revision – Du må også oppgi en beskrivende commitmelding: git commit –m "Message" –Dato, tidspunkt og hvem du er registreres automatisk – Committen får en id, som er en hashkode som er basert på innholdet i committen, f.eks. a e2766e4b0ab6791ca53d44d0d1e499d7. Denne må senere brukes hvis man skal referere til committen. Det holder heldigvis å bruke et prefiks, f.eks. a5760. –Grunnen til at committene ikke nummereres på "normal" måte er at historikken ikke nødvendigvis er lineær – mer om dette senere  Commit ofte! –En commit er et checkpoint som du når som helst kan gå tilbake til når du har rotet til ting –Det er heller ikke nødvendig å ha noe som fungerer for at du skal kunne committe (selv om det er det optimale)  git commit -a (amend) kan fikse på den siste committen (legge til/fjerne/modifisere ting, og modifisere commitmeldingen). Ikke gjør dette hvis du allerede har pushet commiten! (Mer om pushing senere.)

13 Hva ligger i repositoryet? Repository hello.txt +Hello world! hello.txt +Hello world! hello.txt +It's a lovely day. hello.txt +It's a lovely day. hello.txt -Hello world! +Hello there! hello.txt -Hello world! +Hello there! :23:48 – Åsmund Eldhuset :15:01 – Anders Hammervold :18:24 – Jonas Follesø hello.txt +Enjoy it! hello.txt +Enjoy it! :29:18 – Åsmund Eldhuset hello.py +print "Hello world!" hello.py +print "Hello world!" Working directory Hello there! It's a lovely day. Enjoy it! Hello there! It's a lovely day. Enjoy it! print "Hello world!" hello.txt hello.py

14 git log  Viser endringsloggen (sekvensen av commits)

15 git show  Viser hvilke endringer en commit inneholder

16 .gitignore  Filnavn, mappenavn og patterns som står i filen.gitignore vil ignoreres av git status .gitignore i seg selv må committes

17 Git Extensions  git log er litt strevsom å lese, særlig når historikken blir lang  Mye bedre med grafiske verktøy

18 git checkout  Å sjekke ut en commit vil gjøre at hele innholdet i working directory endrer seg til å gjenspeile tilstanden ved den committen – altså er det som om at man går tilbake i tid –Men endringene du gjorde etter committen du sjekket ut ligger fortsatt bevart, og du kan sjekke dem ut for å komme tilbake dit –Det holder å bruke et prefiks av commit-hashen  git checkout ab391c

19 git reset  git reset --hard nullstiller endringene i working directory slik at du kommer tilbake til tilstanden i den siste committen –Kan ikke angres!

20 git branch  En branch er en slags etikett som er klistret på en commit  En branch kan dessuten sjekkes ut –Dette vil sjekke ut committen branchen peker på –I tillegg vil selve branchen få status som "den utsjekkede branchen" –Til enhver tid er én eller ingen brancher sjekket ut (hvis du sjekker ut en commit direkte, vil ingen brancher være sjekket ut)  Hvis du har sjekket ut en branch, vil branchen flytte seg fremover automatisk når du committer  I tillegg finnes en "usynlig" branch som heter HEAD, og som alltid peker på den committen du står på

21 git branch og git checkout  git branch branchname lager en branch der du står nå, men uten å sjekke den ut  git branch branchname commit lager en branch på den oppgitte committen  git checkout branchname sjekker ut en branch  git checkout -b branchname lager en branch der du står nå og sjekker den ut  git checkout commit/branchname -- filename setter en fil tilbake i den tilstanden den var i den aktuelle branchen/committen

22 git merge  Du kan sjekke ut en commit som har etterfølgende commits, og så gjøre en ny commit. Da vil du skape to forskjellige stier i historikken (dette er det som tradisjonelt sett har blitt refert til som en "branch" i andre versjonskontrollsystemer)  Ekstremt nyttig –Flere personer kan utvikle forskjellige ting samtidig uten å forstyrre hverandre med halvferdig kode –Én person kan utvikle forskjellige ting samtidig, og hoppe mellom de forskjellige branchene uten å bli forstyrret  git merge otherbranch

23 git merge

24 git clone  Kopierer et repository fra en annen server og registrerer server- repositoryet som en remote  Gjøres som regel over SSH –Må ha PuTTY installert –Bør bruke PuTTYgen og Pageant til å forenkle innloggingen

25 git fetch  git fetch remotename Laster ned nye commits fra remote, men bare fra de branchene du tracker  Bruk git fetch remotename branchname:branchname for å laste ned en branch du ikke har

26 git fetch RemoteLocal

27 git push og git pull  git push remotename branchname laster opp dine nye commits fra den angitte branchen til det angitte repositoryet –Dette får du bare lov til dersom ikke noen andre allerede har gjort nye commits på den samme branchen  git pull remotename branchname gjør først en git fetch remotename og så en git merge branchname

28 git pull (egen branch) RemoteLocal

29 git pull (annen branch) RemoteLocal

30 Vanlige tabber  Sjekke ut en commit (ikke via en branch), gjøre nye commits, å så sjekke ut noe annet –De nye committene vil tilsynelatende forsvinne fordi de ikke hadde noen branch knyttet til seg –Løsning – Hvis du oppdager dette før committen, lag enten en ny branch med git checkout -b newbranch, eller flytt en eksisterende branch dit du er med git branch -f oldbranch – Hvis ikke, bruk git reflog for å finne den "tapte" committen i "søppelbøtten" til git. Gjør git branch newbranch commit eller git branch -f oldbranch commit, og så git checkout newbranch eller git checkout oldbranch

31 github – fork me, baby!  Populær nettside som hoster git-repos for open source-prosjekter gratis –Kjekt hvis man skal samarbeide om et prosjekt –Kan også betale for å få private repos (vi bruker dette i BEKK)  Kan også fork'e andres prosjekter, gjøre forbedringer og sende committene tilbake

32 BEKK CONSULTING AS SKUR 39, VIPPETANGEN. P.O. BOX 134 SENTRUM, 0102 OSLO, NORWAY. Åsmund Eldhuset Konsulent, Avdeling Trondheim


Laste ned ppt "Praktisk livredning med git Miniseminar NTNU, 22. september 2011 Åsmund Eldhuset."

Liknende presentasjoner


Annonser fra Google