(✿◡‿◡)

Git

Jeg har jo et monorepo med ett backend-prosjekt som server n frontend-prosjekter. Så en vanlig workflow for meg er å kjøre backendprosjektet på localhost samtidig som jeg kjører ett av frontendprosjektene på localhost.

Samtidig er backenden deployet på Payload Cloud med bygg-trigger på innsjekk til en egen branch payload-cms, og frontendene deployet på Vercel med bygg-trigger på deres respektive branches. Men,

• Det er klønete å jobbe mot to deploy-branches i ett repo fordi alle endringer må sjekkes inn til riktig branch hele tiden, hvis jeg sjekker inn endringer på prosjekt A til prosjekt B sin branch går As deploy glipp av dem og man må merge branchene manuelt.
• Fordi branchene typisk ikke er i sync med hverandre kan jeg ikke ha branch A sjekket ut lokalt og kjøre branch B sin app i siste versjon. Jeg gidder ikke å merge branchene med hverandre (og med main) kontinuerlig.
• Jeg kan ikke åpne repoet to ganger i VS Code; git endrer jo selve filsystemet etter utsjekket branch, så hvis jeg bytter branch i den ene instansen av VS Code så reflekteres det bare i den andre instansen.
• Jeg kan ikke droppe branches og jobbe mot kun main, for da trigger jeg bygg på alle prosjektene hver gang jeg sjekker inn.
• Jeg kan klone repoet to ganger og sjekke ut en branch i hver, men det fins bedre måter.

Arbeidsflyt med working trees

Man kan sjekke ut egne working trees fra repoet, ett for branch A og ett for branch B: https://andrewlock.net/working-on-two-git-branches-at-once-with-git-worktree/

Working trees er bare kopier av hele repoet, så det er som å ha klonet det to ganger, men i stedet for egne git-mapper har du en git-fil som peker på et rot-repo, så working-trærne jobber mot ett og samme filsystem; egne kloner er egne filsystemer.

Man kan da ta opp hver branch i egen instans av VS Code og kjøre appene i nyeste versjon der. Hvert innsjekk vil trigge bygg.

Kommando for å ta ut nytt working tree project-a fra branch-a:

git worktree add ../project-a branch-a

Trunk-based arbeidsflyt

Et annet alternativ er å jobbe rett på main. Ingen av prosjektene trigger der, så jeg kan sjekke inn kode fortløpende og merge til de respektive branchene når de er klare. Jeg trenger ikke tenke på at endringer i A må sjekkes inn ett sted og B et annet sted.

Ved større endringer kan jeg ta ut en arbeidsbranch, gjøre endringene der, merge til main og merge til trigger-branchen når alt er klart. Hvis flere utviklere skal jobbe mot samme repo kan main (og trigger-branchene) beskyttes med PR.

main er alltid nyest, så prosjektene kan kjøre parallelt på localhost i siste versjon. Pluss branchene blir alltid merget med siste nytt fra alle andre branches – som ikke har noen praktisk betydning, tror jeg, men jeg foretrekker det.

Jeg kan derfor jobbe mot alle prosjektene i samme instans av VS Code. Ved store endringer der jeg foretrekker å ha A og B i egne instanser av VS Code kan jeg lage en ny klon av repoet. Eventuelt holde meg i samme klon med egen arbeidsbranch i eget working tree. Det går ikke å ta ut samme branch to ganger i parallelle working trees, derav behovet for egen arbeidsbranch i så fall.

Kommando for å merge nyeste lokale commit (HEAD) med branch-a (husk å stå i main):

git push origin HEAD:branch-a