Skip to main content
Dat 2. semester
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage

Git Exercises

Git, branches og samarbejde

I skal arbejde parvis i disse øvelser.

1. Forberedelse

  • Én af jer opretter et nyt repository på GitHub
  • Invitér den anden som collaborator
  • Opret et nyt projekt i IntelliJ
  • Tilføj projektet til det nye GitHub repository
  • Commit og push ændringer til GitHub
  • Den anden kloner projektet til sin computer

2. git guidelines

Gode arbejdsvaner:

  1. git pull før du starter på en ny opgave, hvor du skal ændre koden. Altid!
  2. Undgå såvidt muligt at arbejde i de samme filer samtidig på hver sin computer.
  3. commit ofte for at minimere merge konflikter. Commit efter hver lille arbejdsopgave og push ændringer til GitHub.
  4. git status for at checke status på dit lokale repository før du committer ændringer. Du får vist ændrede filer, nye filer (inkl. dem som er “untracked”) og slettede filer.
  5. Arbejd i branches for at holde jeres arbejde adskilt, så I kan arbejde parallelt. Men hold branches tidsmæssigt korte for at undgå merge konflikter.

3. Branches og Pull Requests

Opret hver jeres branch med navnet: feature-<Your Name>

Derefter:

  • Lav ændring i Main-klassen
  • Commit og push jeres branches til GitHub
  • Opret en Pull Request for jeres egen branch og merge den til main
  • Løs eventuelle merge konflikter
  • Pull ændringer fra GitHub til din computer

4. Reviewing Commit History

Vis commit-historikken:

git log --graph --all --decorate --oneline

Undersøg historikken:

  • Identificér commit hashes, authors og commit messages
  • Diskutér formålet med hver commit

Lav derefter flere commits:

  • Lav flere ændringer i Main-klassen
  • Lav flere commits med gode og beskrivende commit-beskeder
  • Slet Main-klassen og commit ændringen

Find nu en tidligere version:

  • Brug git log til at finde den commit, der indeholder den bedste version af Main
  • Opret en ny branch fra denne commit kaldet featureMainClass.

Hvis hash f.eks. er f42ac91, så skriv:

git branch featureMainClass f42ac91
  • Checkout denne branch
  • Lav ændringer i Main og commit dem
  • Cherry-pick commiten der slettede Main og læg den ovenpå featureMainClass:
git cherry-pick <hash>

Vis derefter en mere avanceret log:

git log --graph --all --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit

Hvad er der sket med din Main?

Hvad har du lært af øvelsen?

  1. Læse historik til at forstå projektets udvikling
  2. Genbruge commits.
  3. Gå tilbage til tidligere version ved at oprette branch fra tidligere commit uden at ødelægge main branch.
  4. Tage en commit fra andet sted i historikken (cherry-pick) og anvende i din nuværende branch.
  5. At Git ikke altid kan afgøre merge-konflikter, men du selv skal tage stilling.

5. Undoing Changes

Pull de seneste ændringer fra GitHub

Lav derefter følgende:

  1. Tilføj en ny metode i Main:

     public static void printNumbers(int start, int end)
    

    Metoden skal udskrive tallene fra start til end.

  2. Brug git stash til at stash’e dine ændringer

  3. Opret og checkout en ny branch kaldet featurePrintNumbers

  4. Tilføj stash til denne branch

  5. Commit ændringerne

  6. Merge branchen ind i main

Hvad har du lært af øvelsen?

Det er en red dig selv øvelse. En typisk situation indtil man får styr på at arbejde med branches: “Ups, jeg er på main – jeg burde være på en feature branch!”:

  1. Gem midlertidige ændringer uden commit
  2. Og dermed rydde workspace før branch-skift

Her til sidst

Diskutér - stadig parvis - og forklar for hinanden, hvor branches og pull requests er en god idé.

Se evt lidt gode argumenter her