Worktrees og større prosjekter

Den interaktive leksjonen trenger JavaScript. Teksten under er hele leksjonen.

Etter leksjonen kan du

• jobbe på to brancher samtidig med git worktree add, og rydde opp etterpå med git worktree remove eller git worktree prune anvende
• skrive mønstre i .gitignore og slette usporede filer trygt med git clean -n før git clean -f anvende
• forklare hva Git LFS og hooks løser, og hva de ikke garanterer forstå

Forstå: Flere mapper, og ting som ikke hører hjemme i Git

En arbeidsmappe viser én branch om gangen. git worktree add lager en ekstra arbeidsmappe til det samme repositoryet, her med en ny branch, hotfix. Den har sin egen HEAD, sitt eget staging-område og sine egne filer, men commits og brancher er felles.

En commit i den ene mappen er straks synlig i den andre, fordi det er samme repository. Her får hotfix commiten H.

I større prosjekter dukker det opp filer som aldri skal i Git, som logger og byggeresultater. Mønstre i .gitignore gjør at Git slutter å vise dem som usporede. Det gjelder bare filer som ikke allerede er sporet, så .gitignore fjerner ingenting fra historikken.

git clean sletter usporede filer, og Git har ingen kopi å gjenopprette dem fra. Kjør derfor alltid git clean -n først, som bare viser hva som ville blitt slettet. Usporede mapper krever -d, og ignorerte filer blir stående med mindre du legger til -x.

Store binærfiler, som video eller datasett, passer dårlig i Git. Hver versjon blir liggende i historikken, og en vanlig klone laster ned alle. Git LFS er et eget tillegg som lagrer en liten peker i Git og selve filen på en egen server.

Hooks er skript Git kjører ved hendelser, for eksempel før en commit eller en push. De ligger i din lokale .git-mappe, blir ikke klonet og kan hoppes over. Regler teamet må kunne stole på, hører hjemme i CI eller på serveren.

Se demo: En hastesak i en egen mappe

Vi står på feature midt i arbeidet med en søkefunksjon. search.txt er endret og ikke committet. Så kommer en hastesak som skal rettes fra main.

$ git status --short

I stedet for å stashe lager vi en ny arbeidsmappe ved siden av denne, ../hotfix. Med -b får den en ny branch, hotfix, som starter på main. Hva skjer med den uferdige endringen?

$ git worktree add -b hotfix ../hotfix main

git worktree list viser begge mappene, hvilken commit de står på og hvilken branch de har sjekket ut. Det er fortsatt bare ett repository.

$ git worktree list

Vi går inn i den nye mappen. Grafen og filpanelet viser fortsatt den første mappen, men det er det samme repositoryet.

$ cd /course/hotfix

Her gjør vi rettelsen og committer den. Se på grafen: hotfix får en ny commit, selv om vi committet i en annen mappe.

$ echo "Contact: support@example.com" >> README.md && git commit -am "Add support contact"

Så går vi tilbake til den første mappen.

$ cd /course/you

Det uferdige arbeidet ligger der det lå. Vi har verken stashet, committet eller byttet branch her.

$ git status --short

Rettelsen er committet på hotfix, så mappen trengs ikke lenger. git worktree remove sletter mappen, men branchen og commiten blir igjen. Etterpå merger du hotfix inn i main som vanlig.

$ git worktree remove ../hotfix

Oppgaver

1. Se hvilke filer som har uferdige endringer.
2. Lag en ekstra arbeidsmappe ../hotfix med en ny branch hotfix som starter på main.
3. List arbeidsmappene til repositoryet.
4. Gjør rettelsen i hotfix-mappen: legg til en linje i README.md og commit den på hotfix.
5. Fjern den ekstra arbeidsmappen, men behold branchen.

Se demo: Ignorer og rydd trygt

Et prosjekt samler fort rot: en byggemappe, en loggfil og et kladdenotat. Ingen av dem skal i Git.

$ mkdir -p build && echo "binary" > build/app.bin && echo "debug output" > debug.log && echo "draft idea" > scratch.txt

Git viser alle tre som usporede. Med mange slike filer drukner de viktige endringene i støy.

$ git status --short

Vi skriver to mønstre i .gitignore. Det første tar alle filer som slutter på punktum log. Det andre tar hele build-mappen.

$ printf '*.log\nbuild/\n' > .gitignore

.gitignore er en vanlig fil. Vi committer den, så hele teamet får de samme reglene. Nå er bare kladden igjen som usporet.

$ git add .gitignore && git commit -m "Ignore logs and build output"

Før vi sletter noe, spør vi hva som ville forsvunnet. -n betyr prøvekjøring. Hva tror du står på lista?

$ git clean -n

Lista så riktig ut, så vi sletter med -f. Kladden er borte for godt, mens loggen og byggemappen står igjen.

$ git clean -f

Oppgaver

1. Få Git til å ignorere alle loggfiler og hele build-mappen.
2. Commit ignoreringsreglene.
3. Se hva Git ville slettet, uten å slette noe.
4. Slett den usporede kladden, men la de ignorerte filene stå.

Øv: Overfør: en gjennomgang og en opprydding

Du står på main med en uferdig endring i README.md. Branchen docs finnes allerede. I mappen ligger også to usporede filer, og forrige uke slettet du en gammel worktree-mappe, ../old-review, for hånd. Ingen demo denne gangen.

Oppgaver

1. Git husker fortsatt den gamle mappen ../old-review, selv om den er borte. Rydd opp i Gits oversikt over arbeidsmapper.
2. En kollega ber deg rette guiden på branchen docs nå. Sjekk ut den eksisterende branchen docs i en egen mappe ../docs, uten å røre README-endringen din.
3. I docs-mappen: legg til en linje i guide.txt og commit den. Fjern så den ekstra mappen. Commiten skal ligge igjen på docs.
4. Rydd i hovedmappen. Få Git til å ignorere alle filer som slutter på .tmp, og commit regelen. Slett så de andre usporede filene. README-endringen din skal fortsatt være der.

Sjekk deg selv: Hent det fram igjen

Branchen hotfix er sjekket ut i ../hotfix. I hovedmappen skriver du git switch hotfix. Hva skjer?

• Git bytter, og begge mappene viser nå hotfix
• Git nekter, fordi branchen allerede er sjekket ut i en annen worktree
• Git flytter mappen ../hotfix hit

secret.env ble committet forrige uke. I dag legger du secret.env inn i .gitignore og committer. Er hemmeligheten trygg nå?

• Ja, ignorerte filer blir ikke lenger pushet
• Nei. Filen er fortsatt sporet, og de gamle commitene inneholder hemmeligheten
• Ja, etter at git clean -fX har fjernet den

Prosjektet skal ha store videofiler som endres ofte. Hva passer?

• Commit dem som vanlige filer, Git komprimerer dem uansett
• Git LFS, som lagrer en peker i Git og innholdet på en egen server
• Legg dem i .gitignore, så tar de ikke plass

Teamet vil sikre at kode som ikke kompilerer, aldri havner på main. Holder det med en pre-push-hook?

• Ja, hooks følger med til alle som kloner
• Nei, hooks er lokale og kan hoppes over. Regelen må håndheves på serveren, med påkrevde CI-sjekker og beskyttet main
• Ja, hvis hooken committes i en hooks/-mappe i repositoryet

Repetisjon fra «Fetch, pull og push»: Ada lager en commit i sin egen klone og pusher den til main. Når ser du den i ditt repository?

• Med en gang, akkurat som i en worktree
• Så snart hun pusher, uten at du gjør noe
• Når du kjører git fetch, og da som origin/main

Vanlige misforståelser

• «En worktree er en ny klone.» Alle worktrees deler det samme repositoryet, med de samme commitene og branchene.
• «git clean kan angres.» Git har ingen lagret kopi av det usporede filer inneholder nå. Det som slettes, er borte.
• «.gitignore skjuler hemmeligheter.» Den gjelder bare usporede filer. Det som allerede er committet, ligger fortsatt i historikken.

$ git worktree list
/course/you    78e95ce [main]
/course/hotfix 78e95ce [hotfix]
/course/review 78e95ce [docs] prunable
$ git worktree prune --dry-run --verbose
Removing worktrees/review: gitdir file points to non-existent location
$ git worktree prune

$ git check-ignore -v build/output.log
.gitignore:2:build/ build/output.log

$ printf '* text=auto\n*.sh text eol=lf\n*.png binary\n' > .gitattributes
$ git check-attr -a -- src/app.sh
src/app.sh: text: set
src/app.sh: eol: lf

$ git submodule add https://example.com/lib.git vendor/lib
$ git ls-files --stage vendor/lib
160000 2ac14ea53dae7e4f874f013b705d31dc30124a99 0   vendor/lib

$ git bundle create ../backup.bundle --all
$ git bundle verify ../backup.bundle
...
../backup.bundle is okay