Lokal guide til Git

1.1???Hvorfor git?

Git er for tiden (2012) det mest popul?re systemet for revisjonskontroll, ihvertfall innen fri programvare. Git har flere kararteristikker som er sv?rt tiltalende. Her er de viktigste:

God st?tte for ikke-linj?r utvikling

Git st?tter enkelt ? raskt lage nye grener i utviklingen (branching) og sammensmelting av grener (merging). Git har spesielle verkt?y for ? visualisere og navigere en ikke-linj?r utviklingshistorikk. En gren (branch) i Git er sv?rt lettvekt, den er kun en referanse til en enkelt commit. Hele grenstrukturen kan bli konstruert ved ? se bakover p? slike referanser.

Distribuert utvikling

Som endel andre tilsvarende verkt?y for versjonskontroll (men ulikt Subversion og CVS), gir Git hver utvikler en lokal kopi av hele utviklingshistorikken. Endringer kan kopieres fra ett slikt repository til et annet. Disse endringene importeres som ekstra grener (branches), og kan smeltes sammen (merges) p? samme m?te som en lokalt utviklet gren (branch).

Kompabilitet med eksisterende systemer og protokoller

Repositories kan bli publisert via kjente protokoller som HTTP, FTP og rsync. I tillegg finnes det en egen Git-protokoll som enten kan brukes over en vanlig socket eller via ssh. Git har ogs? st?tte for ? kunne brukes sammen med Subversion eller CVS.

Effektiv behandling av store prosjekter

Git har et sv?rt godt rykte for ? v?re effektiv og rask, ogs? n?r det handler om store prosjekter med sv?rt mange filer og komplisert utviklingshistorikk. Git blir ikke tregere etter hvert som historikken blir st?rre.

Kryptografisk autentisering av historikk

Git-historikken lagres p? en slik m?te at navnet p? en revisjon (dvs. en commit) avhenger av den komplette historikken som leder opp til denne enkelte commit'en. N?r historikken er publisert, er det teoretisk umulig ? endre eldre versjoner uten at det kan bli lagt merke til.

3.1???Bestilling

For ? bestille et nytt Git-repository m? man sende en e-post til unix-drift@usit.uio.no med f?lgende informasjon:

• Navn p? git-repository. Dette skal best? av kun sm? bokstaver, tall og spesialtegn - og _. Navn b?r inneholde avdeling, f.eks.: "usit-foo", "ifi-bar".
• Kort beskrivelse av repo, brukes til Gitweb og/eller utsending av mail om endringer (push) til repoet.
• UiO-brukernavn til ansvarlig eier.
• Hvem andre som skal ha tilgang (UiO-brukernavn). Dersom det skal gis tilgang til personer utenfor UiO: Fullt navn. Hvis noen skal ha kun lesetilgang eller tilgang skal styres p? branch-niv? m? dette spesifiseres.
• Offentlig SSH-n?kkel til de som skal ha tilgang, dersom n?kkel ikke ligger inne fra f?r. Se SSH-n?kler for informasjon om dette
• Skal repoet v?re tilgjengelig for hele verden via web og git-protokollen?
• Dersom det er ?nskelig med e-post om hver push til repoet, hvilken e-postadresse dette skal sendes til.

3.2???SSH-n?kler

Vi bruker SSH-n?kler for ? gi tilgang til git-repoet. Slik gj?r du for ? lage et n?kkelpar p? en Linux-maskin:

1. Hvis du ikke har en RSA-n?kkel fra f?r, lag en ny slik:

   ssh-keygen -t rsa -b 4096
   

2. Send ~/.ssh/id_rsa.pub til unix-drift@usit.uio.no sammen med bestillingen. Vi trenger ogs? SSH-n?kkel for andre brukere som skal ha tilgang. Kall dem gjerne <brukernavn>.pub.

Vi vil legge inn n?kkelen i systemet og gi deg tilgang til det som du skal ha tilgang til.

Ved endring av tilgang til repoet, kontakt unix-drift@usit.uio.no, vi kan erstatte eksisterende SSH-n?kler, legge til for nye brukere eller slette. Kun den registrerte eieren av et repo kan be om endring av tilganger.

3.3???Sette opp config for git

Git forventer ? finne en fil ~/.gitconfig som minst inneholder f?lgende:

[user]
        name = <ditt navn>
        email = <din e-postadresse>

Denne kan enten lages manuelt, eller man kan bruke git config, slik:

git config --global user.name '<ditt navn>'
git config --global user.email '<din e-postadresse>'

Se for ?vrig git-config(1).

5.1???Legge til en fil lokalt

For ? legge til en fil:

git add <filnavn>

Filen m? eksistere fra f?r.

Se for ?vrig git-add(1).

5.2???Sjekke inn endringer lokalt

For ? sjekke inn endringer:

git add [filer...]
git commit [filer...]

Hvis man ikke vil kontrollere hvilke filer det gjelder trenger man ikke spesifisere filer. Da vil git s?ke gjennom hele katalogen for ? finne ut hva som er endret. Det vil komme opp en editor der man skal skrive commit-melding. Man kan isteden angi denne p? kommandolinjen:

git commit -m '<melding>' [filer...]

Man kan ogs? velge ? gj?re "add" i samme prosess, dvs. at man slipper ? gj?re en egen "git add", men kun hvis filen finnes i git fra f?r:

git commit -a [filer...]

Ting kan kombineres:

git commit -a -m '<melding>' [filer...]

Se for ?vrig git-commit(1).

5.3???Pushe endringer til sentralt repo

En "git commit" vil kun sjekke inn endringer lokalt, i ditt lokale repository. For ? f? dette inn p? git-serveren m? man bruke push:

git push

Se for ?vrig git-push(1).

5.4???Hent endringer fra sentralt repo

Man kan oppdatere sitt lokale repo fra det sentrale ved ? bruke pull:

git pull

Se for ?vrig git-pull(1).

7.1???Merging

Dersom man er forn?yd med endringene som er utf?rt i en branch, kan man gj?re merge av denne inn til en annen, f.eks. fra en test-branch til en prod-branch. I eksemplet gj?r vi merge av innholdet i test inn i master:

1. S?rg for at aktiv branch er den som det skal merges inn i:

   $ git checkout master
   Switched to branch 'master'
   

2. Kj?r git merge:

   $ git merge test
   Updating bdebdfc..10c644c
   Fast-forward
    minfil.txt |    1 +
    1 files changed, 1 insertions(+), 0 deletions(-)
   

   Dersom du f?r en konflikt ser det slik ut:

   Auto-merging minfil.txt
   CONFLICT (content): Merge conflict in minfil.txt
   Automatic merge failed; fix conflicts and then commit the result.
   

   Ev. konflikter m? l?ses f?r en merge kan fullf?res.

3. Til slutt gj?res commit:

   $ git commit -a -m 'melding'
   [el6 5ad8e86] melding
   

For mer informasjon, se git-merge(1).

7.2???Slette en branch

Dette gj?res slik:

$ git branch -d test
Deleted branch test (was 8f08040).

Dette forutsetter at man har gjort git merge f?rst. Dersom endringene i 'test' skal kastes uten videre, bruk git branch -D test.

For mer informasjon, se git-branch(1).

8.1???Farger i diff og annen output

For ? f? farger fra git diff og andre Git-kommandoer kan man sette f?lgende i ~/.gitconfig:

[color]
        ui = auto

Dette kan ogs? settes vha. git config:

git config --global color.ui auto

8.2???Aliaser til Git-kommandoer

Man kan sette aliaser for Git-kommandoer p? denne m?ten:

[alias]
        <alias> = <kommando>

Eksempel:

[alias]
        co = checkout

Dette kan ogs? settes med git config (eksempel):

git config --global alias.co checkout

8.3???Bruke meld som verkt?y for merging

Meld er et GUI-program (GNOME) for ? visualisere og hjelpe med merging. Dersom man ?nsker at Git i tilfelle konflikt ved merge skal starte Meld automatisk, kan man sette i ~/.gitconfig:

[merge]
        tool = meld

Eller med git config:

git config --global merge.tool meld

Husk ? ogs? installere Meld:

sudo yum -y install meld

8.4???Vise aktiv branch i prompt

For ? f? bash til ? vise aktiv branch i prompet kan man sette PS1 p? f?lgende m?te i ~/.bashrc:

if [ -f /etc/bash_completion.d/git ]; then
    source /etc/bash_completion.d/git
    export GIT_PS1_SHOWDIRTYSTATE=true
    export GIT_PS1_SHOWUNTRACKEDFILES=true
fi
export PS1='[\u@\h \W$(declare -F __git_ps1 &>/dev/null && __git_ps1 " (%s)")]\$ '

Dette vil s?rge for at bash-prompten ser slik ut:

[user@host directory-name (master)]$

I tillegg til ? vise hvilken branch man jobber p?, vil dette ogs? vise om men er i en merge eller rebase:

[user@host directory-name (master*)]$
[user@host directory-name (master+)]$
[user@host directory-name (master%)]$

• P? den f?rste linjen er en fil endret
• P? den andre linjen er en fil endret og man har gjort git add men ikke git commit
• P? den tredje linjen er det laget en ny fil som ikke er i git

Disse vil naturligvis kombineres.