Hva er versjonskontroll?

• Versjonskontroll er verktøy for å lagre forskjellige versjoner av (filene i) et prosjekt
• Forskjellige versjoner kan være:
  • Historien til prosjektet (gir bl.a. "avansert undo")
  • Flere som jobber på samme prosjekt på hver sin maskin
  • At du prøver ut forskjellige ting med samme fungerende kode som utgangspunkt
  • En kombinasjon

git

• Det finnes mange versjonskontrollsystemer (subversion mercurial, git, ...)
• git ble laget av Linus Torvalds til Linux-prosjektet og er for tiden det mest populære
• git er det som kalles distribuert versjonskontroll (det vil si at du ikke å ha en server å jobbe opp mot)

Ordforklaringer

• Repo (repository): En mappe som har versjonshistorie kaller vi et repo.
• Commit: En commit er ett punkt i historien til prosjektet ditt. Én commit er da ett sett med endringer i prosjektet.

git status

Viser status i repoet/mappa du er i. Brukes hele tiden.

~/prosjekt $ git status
On branch master

Initial commit

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    .gitignore

nothing added to commit but untracked files present (use "git add" to track)

Legg merke til at standardutskriften nesten hele tiden sier deg hva du trenger å gjøre.

git status (eksempel)

~/prosjekt $ git status

On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   .gitignore

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    Main.java

no changes added to commit (use "git add" and/or "git commit -a")

git add

Legger til endringer (oftest hele filer) i det du skal lagre i historikken.

~/prosjekt $ git add Main.java

Du kan legge til hele mapper på en gang, for eksempel hele mappa du er i for øyeblikket:

~/prosjekt $ git add .

git add

Vi bruker "git status" for å se at vi fikk lagt til det vi skulle

~/prosjekt $ git add Main.java

~/prosjekt $ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   Main.java

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   .gitignore

git commit

Lager et nytt punkt i historien til prosjektet.

~/prosjekt $ git commit -m "Added main class"
[master a2fd616] Added Main class
 1 file changed, 2 insertions(+)
 create mode 100644 Main.java

git config

Før aller første commit (på maskina, ikke hvert prosjekt) må man fortelle git hvem man er:

~/prosjekt $ git config --global user.name "Ole Olsen"

~/prosjekt $ git config --global user.email "ololse@uio.no"

git log

Viser historien, nyeste commit først

~/prosjekt $ git log
commit a2fd61653dcba6d1a558eee8b0b81ce4564aa0b2
Author: Erik Vesteraas <erikadr@ifi.uio.no>
Date:   Wed Feb 3 21:11:20 2016 +0100

    Added Main class

commit ea81a7d4a3adf01b331d36a09ae65a0cf8559f93
Author: Erik Vesteraas <erikadr@ifi.uio.no>
Date:   Wed Feb 3 20:17:51 2016 +0100

    An older commit

git log

Standard-loggen er dessverre ganske unyttig, en bedre variant er:

~/prosjekt $ git log --all --oneline --graph --decorate
* a2fd616 (HEAD -> master) Added Main class
* ea81a7d An older commit

git config --global alias

Vi kan lage alias for kommandoer vi bruker ofte. For eksempel, for å lage alias for:

~/prosjekt $ git log --all --oneline --graph --decorate

~/prosjekt $ git config --global alias.lg "log --all --oneline --graph --decorate"

~/prosjekt $ git lg

git config --global alias

Flere eksempel (fra mine egne alias):

git config --global alias.st "status -s"

git config --global alias.co "checkout"
git config --global alias.com "checkout master"​
git config --global alias.cob "checkout -b"​

git config --global alias.preview "diff --cached"

git config --global alias.pc "push origin HEAD"

(Alt du gjør med "git config --global" blir forøvrig lagret i fila "~/.gitconfig")

First commit, "hello world"

Added pretty colors

Added sayHello method

Removed silly colors

Added more varied greetings

Added even more stuff (HEAD -> master)

Branching

Historien vår starter som en rett linje, med bare en "gren". Denne grenen har navnet "master"

First commit, "hello world"

Added pretty colors

Added sayHello method

Removed silly colors

Added more varied greetings

Added even more stuff (master)

Branching

(HEAD -> colors)

Men ofte er det nyttig å lage flere grener, her lager vi for eksempel en gren som starter et stykke bak i historien, med navnet "colors"

First commit, "hello world"

Added pretty colors

Added sayHello method

Removed silly colors

Added more varied greetings

Added even more stuff (master)

Branching

Added really colorful greetings (HEAD -> colors)

Navnet – som fungerer som en referanse – flytter seg etter hvert som du jobber på en gren.

First commit, "hello world"

Added pretty colors

Added sayHello method

Removed silly colors

Added more varied greetings

Added even more stuff (master)

Branching

Added really colorful greetings

Added emoji support (HEAD -> colors)

På denne måten kan vi få ikke bare én historie, men flere parallelle historier. 

First commit, "hello world"

Added pretty colors

Added sayHello method

Removed silly colors

Added more varied greetings

Added even more stuff (HEAD -> master)

Branching

Added really colorful greetings

Added emoji support (colors)

Referansen HEAD viser hvor du jobber på ethvert tidspunkt

Samme historie med aliaset gitt i git config-sliden

~/prosjekt $ git lg
* 20c0bfc (colors) Added emoji support
* 0db44f2 Added really colorful greetings
| * 07d5696 (HEAD -> master) Added even more stuff
| * f24a2b2 Added more varied greetings
| * c56db59 Removed silly colors
|/
* 62ac2f6 Added sayHello method
* 6d6b53c Added pretty colors
* a50d6c7 First commit, "hello world"

git checkout

Dette er kommandoen vi bruker for å faktisk navigere historien

~/prosjekt $ git checkout <referanse>

<referanse> kan være navnet på en gren, en tag (laget med git tag) eller hashkoden til en spesifikk commit.

git checkout

Man kan også bruke git checkout til å lage en ny gren. Med "-b" (for "--branch") lages en ny gren der HEAD er for øyeblikket.

~/prosjekt $ git checkout -b <navn-på-gren>

git checkout

~/prosjekt $ git lg
* a2fd616 (HEAD -> master) Added Main class
* ea81a7d An older commit

~/prosjekt $ git checkout ea81
~/prosjekt $ git lg
* a2fd616 (master) Added Main class
* ea81a7d (HEAD) An older commit

~/prosjekt $ git checkout -b colors
~/prosjekt $ git lg
* a2fd616 (master) Added Main class
* ea81a7d (HEAD -> colors) An older commit

For eksempel:

Kalles "detached HEAD state" og bør ikke jobbes i. Lag en branch.

git checkout

~/prosjekt $ git checkout <path>

Vi kan også bruke git checkout til å hente spesifikke versjoner av enkeltfiler.

~/prosjekt $ git checkout <referanse> <path>

Hvis vi ikke sier noen referanse henter vi fra nyeste commit. Altså er den nyttig for å forkaste endringer siden siste commit vi gjorde.

~/prosjekt $ git checkout colors Main.java

~/prosjekt $ git checkout Main.java

"Hent versjonen av Main.java som ligger i grenen colors"

github.uio.no

github.uio.no

• Samme brukernavn og passord som du bruker på ifi-maskiner og devilry
• Gratis (dvs. UiO betaler) så lenge du er UiO-student
• Med andre ord bra til obliger som ikke kan ligge offentlig, men ikke til ting du vil publisere/lagre permanent.
• (Blir faktisk brukt til enkelte fag, altså et krav å lære før eller senere)

1: Helt nytt prosjekt

Readme er alltid fint

Velg språket du skal bruke, så får du en ferdig .gitignore-fil

Kopier addressen herfra og kjør

 ​git clone "Adressen du kopierte"

i terminalen (kommandoen lager en mappe til prosjektet)

2: Du har allerede et prosjekt

Ikke kryss av her

Og ikke velg noe språk her

Hvis vi ikke allerede har gjort prosjektet om til et repo må vi gjøre det nå. Altså:

1. Kjør kommandoen "git init"​

2. Lag en .gitignore-fil

3. Gjør første "git commit"

2: Du har allerede et prosjekt

Kjør denne koden i terminalen i repoet (mappa) til prosjektet ditt

Konflikter

Når du gjør en "git pull" og det er forskjell på historiene vil git vanligvis prøve å fikse problemet selv. Hvis endringene er i forskjellige filer er det ikke noe problem.

Men av og til er det umulig for git å finne ut av problemet selv:

​...
if (foo == bar) {
    doSomething();
}
...

​...
if (foo == bar) {
    sayHello();
}
...

Vil vi "doSomething", "sayHello" eller begge deler?

Konflikter

​...
if (foo == bar) {
    doSomething();
}
...

​...
if (foo == bar) {
    sayHello();
}
...

​...
if (foo == bar) {
<<<<<<< HEAD
    sayHello();
=======
    doSomething();
>>>>>>> do-something-branch
}
...

​...
if (foo == bar) {
<<<<<<< HEAD
    sayHello();
=======
    doSomething();
>>>>>>> do-something-branch
}
...

​...
if (foo == bar) {
    sayHello();
    doSomething();
}
...

Hvis du ville ha begge deler er det da bare å redigere på denne måten:

Å avslutte en merge

Så er det bare å gjøre "git add" og "git commit" så er du ferdig. Altså, hvis filen var FooBar.java:

~/prosjekt $ git add FooBar.java

~/prosjekt $ git commit -m "Merged do-something-branch"

git stash

Denne kommandoen skjuler endringer midlertidig, uten å lage en commit. Filer som er "untracked" blir ikke påvirket.

~/prosjekt $ git status
On branch master
Changes not staged for commit:
  ...
    modified:   .gitignore
Untracked files:
  ...
    Util.java

git stash

git stash pop gir deg endringene tilbake igjen.

~/prosjekt $ git stash pop
On branch master
Changes not staged for commit:
  ...
    modified:   .gitignore
Untracked files:
  ...
    Util.java