Git for Cerebrum

Informasjon om korleis vi bruker Git i Cerebrum-miljøet.

TODO: Dokumentet treng å oppdaterast med fleire kommandoar, tips og triks.

1   Generelt

Cerebrum sine Git-repo ligg i Stash. Nokre er leselege for heile verda, andre er berre tilgjengelege for Cerebrum drift og utvikling. Stash har også integrasjon med Jira og andre verktøy, som Jenkins, så vi bruker det til meir enn berre versjonskontroll.

1.1   Førstegangsbrukarar

Om du er vant til å bruke Subversion og/eller CVS, finnast det mange tutorials på nettet for deg, til dømes Git-SVN crash course.

1.2   Oppstart

For å starte med å lese og kode mot Git-repo:

  1. Ein administrator må legge deg til som brukar i Jira og Stash, og legge deg inn i gruppa cerebrum-utvikling for å få tilgang til alle Cerebrum-repo.

  2. Valfritt: Logg deg på i Stash og legg til ssh-nøklar under Manage account. Dette for å sleppe å måtte taste inn passord ved innsjekkingar. Om du ikkje har ein SSH-nøkkel allereie kan du generere denne med:

    ssh-keygen -b 4096

    Set deg ei passordfrase, og bruk heller ssh-agent for å unngå å måtte taste inn passordfrasen kvar gang. Sjå Sikkerhetshåndboken for retningslinjer i bruk av ssh-nøklar, og OpenSSH ved UiO for meir info om av ssh på UiO.

  3. Hent ut dei kodetrea du vil jobbe med. I stash kan du finne eksakt URL ved å gå til repoet og velge "Clone" øvers til høgre. Køyr deretter:

    cd ~/src/
git clone ssh://git@utv.uio.no:7999/crb/cerebrum.git

  4. Du kan no starte å branche ut, utvikle og sjekke inn i branchen.

2   Arbeidsflyt

Vi bruker GitHub flow (meir info) i repo som brukast for utvikling. TODO: Konfigurasjonsrepo og mindre repo er det ikkje blitt diskutert arbeidsflyt for endå.

Sjå Rutiner og arbeidsflyt for Cerebrum utvikling for meir detaljar i korleis vår arbeidslyt er.

2.1   Retningslinjer

Retningslinjene for Cerebrum-utvikling:

  • Ikkje sjekk inn kode til `master`. Denne skal berre brukast av drift når saker er "done-done", altså klare til prodsetting.
  • master-branchen er alltid stabil, og er klar til prodsetting. TODO: Det er visse forbehold til dette, til dømes må ein gjere ei manuell migrering ved prodsetting, til dømes oppretting av nye konstantar.
  • Ein branch per feature eller bugfiks. Branchen skal tilsvare ei Jira-sak.
  • Branchen skal gjennom code review før migrering til master.
  • Ikkje force inn endringar. Når ein må eksplisitt legge til --force for å pushe inn endringar er det ein grunn til det, og du må vite nøyaktig kva du gjer og konsekvensene av det før du tvinger inn slike endringar. I Stash er det valgt å sperre mot force-endringar i kodetrea til Cerebrum.

2.2   Utvikling på ny sak

Når du skal begynne å utvikle på ei ny sak, må du ha ei Jira-sak å gå ut frå, og du må utvikle i ein eigen branch.

  1. Gå til saka i Jira.

  2. Velg "Create branch", opprett ein passande branch og hent den ned med:

    git fetch origin

    Alternativt kan du opprette branchen lokalt først, med:

    git checkout -b CRB-XXX-new-functionality

  3. Rediger kodetreet med vanleg git commit og anna.

  4. Send kodeendringar tilbake til Stash med:

    git push origin BRANCHNAME

2.3   Code review

Etter at du har sjekka kode inn i ein branch kan du be andre utviklarar om å sjå over koden for å få kommentarar eller for at dei kan godkjenne branchen til å bli merga tilbake til master.

  1. Gå til branchen i Stash og klikk på Pull request.
  2. Velg din branch og kven du vil ha som reviewers.
  3. Vent på tilbakemeldingar. :)
  4. Reviewers kan både legge inn kommentarar på kodelinjer, filer og commits, og dei kan også approve branchen, som gjer at den kan bli fletta inn i master.

Merk: Sjekk aldri inn kode direkte i master-branchen. Master skal berre inneholde kode som er heilt klar til å settast i produksjon.

3   Retningslinjer, konfigurasjon og ressurser

  • Bruk git fetch og git merge i staden for git pull ved utsjekking for bedre kontroll og forståelse. Sjå git: fetch and merge, don’t pull.

  • Du kan stille inn git til å ikkje pushe alle branchar du har jobba på som standard, men berre den du sjekka ut. Dette for å unngå å pushe endringar du ikkje er ferdige med, eller du ønsker å rebase først.

    Kommando for å sette dette:

    git config --global remote.origin.push HEAD

    Eller du kan legge til i ~/.gitconfig:

    [remote "origin"]
        push = HEAD

  • Det er anbefalt å lage commit-meldingar i imperativ. Dømer:

    • Fix bug X
    • Extend with featureY
    • Change template with ...

    Sjå https://git.kernel.org/cgit/git/git.git/tree/Documentation/SubmittingPatches?id=HEAD for meir retningslinjer frå Git sin dokumentasjon.

  • For ei bedre forståing av Git: A Hacker’s Guide to Git.

  • Nokre innstillingar i ~/.gitconfig:

    [user]
    name = FIRSTNAME LASTNAME
    # Bruk helst e-postadressa du er registrert med i Stash, så kobler
    # Stash dine commits til deg.
    email = "USERNAME@usit.uio.no"
[core]
    editor = MICROSOFT_WORD
[color]
    # For fargar i output, bl.a. `git diff`
    ui = auto
[remote "origin"]
    push = HEAD

4   Aliaser

Det kan være kjekt med shell-funksjoner, aliaser eller små script-snutter for å utføre de mest brukte git-kommandoene.

Her er noen eksempler:

Mulig alias Kommando Beskrivelse
fetch git fetch last ned endringer, uten å ta de i bruk
branches git branch --all vis alle branches, både lokalt og remote
b git branch vis alle lokale branches
rmlastcommit git reset --hard HEAD~1 slett (!) forrige lokale commit

5   Andre triks

Scenario: Du er på en branch, og ønsker å hente endringer fra en enkelt fil i en annen branch.
Kommando: git checkout --patch branch filnavn
Scenario: Du har klonet et repo og ønsker å sjekke ut en branch du ikke vet navnet på
Kommando: git fetch; git branch -a og så git checkout branch
Av jokim
Publisert 5. sep. 2014 10:30 - Sist endret 10. jan. 2019 14:50
Del på e-post