Github ved UiO

Dette dokumentet beskriver UiOs lokale Github-tjeneste. Det er ogs? en introduksjon til bruk av Git, samt litt generell informasjon om Git-kommandoer.

1???Litt om GitHub

GitHub er en fullverdig Git-tjeneste samt at den har et visuelt grensesnitt som lar deg enkelt behandle og bla i gjennom kode og informasjon som har blitt lastet opp av deg selv og andre. I tillegg til dette har den funksjoner som Github Pages som enkelt lar deg sette opp sider hvor du kan legge opp tekst og bilder som kanskje er relevant til prosjektet du har lagt inn p? Github.

2???Hvordan ta i bruk GitHub

Straks du logger deg inn p? nettsiden https://github.uio.no vil du ha f?tt opprettet en bruker og kan ta i bruk GitHub. For ? kunne laste ned et repository til din datamaskin m? du f?rst ha lagt inn en SSH-n?kkel. Nedenfor f?lger en instruksjon til hvordan du tar dette i bruk.

For IT-ansatte ved UiO anbefales ? det lese f?lgende dokument: .. _Github for IT-ansatte: /tjenester/it/lagring-澳门葡京手机版app下载/versjonskontroll/github-for-it-ansatte.md

NB. Hvis du har reservert deg mot at din e-post skal v?re synlig for andre ved UiO s? vil dette ikke fungere i GitHub, din e-post vil v?re synlig for andre brukere i GitHub s? lenge de er innlogget p? GitHub.

2.1???SSH-n?kler

GitHub bruker SSH-n?kler for ? autentisere brukere som vil koble seg til Git-tjenesten.

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

    ssh-keygen -t rsa -b 4096
    

Du vil her bli spurt om hvor du vil lagre id_rsa-filen, og i tillegg om en passordfrase. Ved UiO m? alle SSH-n?kler beskyttes med passordfrase, s? det er ikke lov ? velge en tom passordfrase.

  1. N?r du har denne n?kkelen klar, s? laster du opp .pub-filen som ble opprettet, eller som du allerede har tilknyttet din SSH-n?kkel. Dette gj?r du ved ? logge deg inn p? github.uio.no og s? trykker p? bildeikonet tilh?rende din profil i h?yre hj?rne. Du vil da f? opp en meny hvor du kan velge "Settings". N?r du da har navigert videre til "Settings" finnes det en lenke kalt "SSH keys". Trykk s? p? "Add SSH key" og du vil f? opp et skjema hvor du vil kunne lime inn innholdet fra din pub-fil. Veldig viktig her at du limer inn fra filen kalt id_rsa.pub og ikke fra id_rsa, da sistnevnte er din private n?kkel som du ikke skal dele med noen andre.

2.2???Opprette et nytt repository

Du oppretter et nytt repository ved ? enten trykke oppe i h?yre hj?rne p? pluss-ikonet og velge "create new repository" eller ved ? g? til https://github.uio.no/new . Her vil du kunne velge om det skal v?re et offentlig repository som er tilgjengelig for alle ved UiO som er innlogget, eller et privat repository som bare du har tilgang til.

2.3???Opprette en organisasjon

Om du skal 澳门葡京手机版app下载e om flere prosjekter med en gruppe mennesker s? kan det v?re fint ? bruke en organisasjon for ? organisere sammen flere repositories p? en enkel m?te. Ved ? trykke p? pluss-ikonet i h?yre hj?rne vil du kunne velge "Create new organization" og bli ledet til skjemaet for opprettelse av dette.

Rettighetsstyring innenfor her kan foreg? p? et granul?rt niv?, slik at man kan for eksempel ha b?de offentlige og private repositories, som b?de er tilgjengelig for alle UiO-brukere, og kun for en liste over brukere som du selv har definert.

Et konkret eksempel p? hvordan man kan ta dette i bruk er ved ? bruke det i klasseromsammenheng. Der vil man kanskje ha et repository som kun er tilgjengelig for gruppel?rere, og et kun tilgjengelig for studenter.

2.4???Videre dokumentasjon

GitHub sitt utviklingslag har dokumentert deres applikasjon GitHub Enterprise ganske godt s? om det er noe man lurer p? s? finner man det meste forklart b?de i applikasjonen og eventuelt ved ? s?ke det opp p? dokumentasjonssidene som man finner her: https://docs.github.com/en/free-pro-team@latest/github/creating-cloning-and-archiving-repositories https://docs.github.com/en/free-pro-team@latest/github/using-git

3???Hvordan bruke Git p? din klient

I den videre teksten refereres det til git-repoet mittrepo. Bytt ut dette navnet med det egentlige navnet p? repoet.

Hent ned en lokal kopi av mittrepo:

$ git clone git@github.uio.no:amedov/mittrepo.git
Cloning into 'mittrepo'...

N? er katalogen mittrepo laget, og denne katalogen vil v?re tom siden det ikke lagt inn noe innhold forel?pig.

N? kan du begynne ? dytte inn innhold, la oss si at vi lager en fil til ? begynne med, kalt minfil.txt. F?rst legge den til:

$ git add minfil.txt

Deretter commit:

$ git commit -m 'Initial commit'
[master (root-commit) 1a2dcd1] initial commit
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 minfil.txt

Push endringene til remote:

$ git push origin master
Counting objects: 6, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 3.38 KiB, done.
Total 6 (delta 0), reused 0 (delta 0)
To git@github.uio.no/amedov/mittrepo.git
 * [new branch]      master -> master

Videre kan vi bruke git push uten ? spesifisere hvordan ting skal merges.

4???Enkel bruk av git

Her forutsettes det at aktiv katalog er mittrepo.

4.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).

4.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).

4.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).

4.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).

5???Overgang fra Subversion

Det er mulig ? overf?re et subversion-arkiv til Git og ta med all historikk fra Subversion i prosessen. Det forutsettes at dette skal inn i et nylig opprettet og tomt Git-repository. Videre gj?res dette p? f?lgende m?te:

  1. Installer rpm-pakken git-svn (som root):

    $ sudo yum install git-svn
    
  2. Bruk git-svn til ? klone ut fra Subversion og omgj?re til et lokalt Git-repository:

    $ git svn clone svn+ssh://vcs-usit.uio.no/svnroot/eksempel/trunk/mittrepo
    [...]
    Checked out HEAD:
       svn+ssh://vcs-usit.uio.no/svnroot/eksempel/trunk/mittrepo r22220
    
  3. Katalogen for repoet opprettes i prosessen, cd til denne:

    $ cd mittrepo
    
  4. Legg til ny upstream for repoet:

    $ git remote add origin ssh://git@github.uio.no:amedov/mittrepo.git
    
  5. Dytt det lokale repoet upstream:

    $ git push -u origin master
    Counting objects: 1506, done.
    Delta compression using up to 4 threads.
    Compressing objects: 100% (1502/1502), done.
    Writing objects: 100% (1506/1506), 329.91 KiB, done.
    Total 1506 (delta 1377), reused 0 (delta 0)
    To ssh://git@github.uio.no/mittrepo
     * [new branch]      master -> master
    Branch master set up to track remote branch master from origin.
    

    Opsjonen -u s?rger for at ny default upstream settes.

N?r dette er gjort kan git-repoet brukes p? vanlig m?te.

6???Enkel bruk av branching

Den normale m?ten ? utvikle p? med Subversion og CVS er noe slikt som dette:

Linj?r utviklingsmodell

Git sin commit-historikk er mer kompleks enn det man finner i Subversion, CVS og tilsvarende systemer. I Git kan en commit ha flere foreldre og flere barn (rettet asyklisk graf). Dette betyr at man ikke er n?dt til ? redigere p? siste revisjon av koden. Man kan lage en commit basert p? en hvilken som helst commit og lage en gren av den. N?r man s? ?nsker ? smelte disse sammen (merge), lager man en commit som er et barn av to commits. Slike barn kalles "merge commits".

Den vanligste m?ten ? bruke branching er til eksperimentelle features i et prosjekt, ev. til back-porting av endringer til en stabil branch.

Ettersom branching i Git er s?pass effektivt og enkelt er det naturlig ? f?lge en utviklingsmodell som ser slik ut:

Grenet utviklingsmodell

For ? se hvilke grener som er tilgjengelig, og hvilken som er aktiv (angitt med stjerne "*"):

$ git branch
* master

For ? lage en ny branch:

$ git branch test

$ git branch
* master
  test

For ? endre aktiv branch:

$ git checkout test
Switched to branch 'test'

$ git branch
  master
* test

Man kan ogs? ta en snarvei og spesifisere ny branch ved checkout:

$ git checkout -b test2
Switched to a new branch 'test2'

$ git branch
  master
  test
* test2

6.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).

6.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).

7???Tips og triks

7.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

7.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

7.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

7.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.

8???Om Git

Git er et distribuert revisjonskontrollsystem med fokus p? hastighet. Git var i begynnelsen designet og uviklet av Linus Torvalds for ? holde orden p? utvikling av Linux-kjernen, men har siden blitt utviklet videre til ? bli et sv?rt kraftig verkt?y brukt i sv?rt mange store prosjekter.

Hvert arbeidstre i Git er et fullt repository med all historikk og full sporing av revisjoner. Man er ikke avhengig av nettverk eller en sentral tjeneste. Git er fri programvare under GPLv2.

8.1???Hvorfor git?

Git er for tiden (2015) 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.
Av Safet Amedov
Publisert 19. nov. 2020 10:50 - Sist endret 23. aug. 2021 14:50