Sammenligning af Subtree og Submodule

Velkommen til den sidste lektion i vores minikursus om Git Subtree! Vi har undersøgt, hvad Git Subtree er, og hvordan du bruger det. Nu er det tid til at sammenligne det med Git-undermoduler.

Begge værktøjer hjælper med at administrere eksterne afhængigheder i et hovedprojekt, men de gør det på grundlæggende forskellige måder. Det er vigtigt at forstå disse forskelle, når du skal vælge den rigtige strategi til dit projekt.

Husk, at Git-undermoduler giver dig mulighed for at indlejre ét Git-projekt i et andet som en undermappe. Hovedprojektet gemmer en reference til en specifik commit i undermodulets projekt.

• Separate historikker: Hvert undermodul vedligeholder sin egen uafhængige Git-historik.
• Referencer, ikke kopier: Det overordnede projekt gemmer kun en reference til undermodulets commit, ikke det faktiske indhold.
• Decentraliseret udvikling: Ideelt, når du har brug for at bidrage direkte til den upstream-afhængighed.

Undermoduler har tydelige fordele, især i bestemte situationer:

• Tydelig adskillelse: Afhængighedens historik er fuldstændig adskilt fra hovedprojektets historik.
• Bidrag upstream: Det er nemt at foretage ændringer i undermodulet og pushe dem direkte til dets oprindelige upstream-projekt.
• Versionsfastlåsning: Du kan fastlåse et undermodul til en bestemt commit, så du sikrer stabilitet.
• Distribueret ejerskab: Nyttigt, når forskellige teams administrerer forskellige dele af et større system.

Trods deres fordele medfører undermoduler en række kompleksiteter, som især kan være vanskelige for begyndere:

• Kompleks kloning: Kræver ekstra trin (git submodule init, git submodule update) efter kloning.
• Frakoblet HEAD: Sætter dig ofte i tilstanden »detached HEAD«, når du arbejder inde i et undermodul, hvilket kan være forvirrende.
• Håndtering af historik: Opdatering af undermoduler betyder, at du skal committe en ny reference i det overordnede projekt, hvilket kan føre til hyppige opdateringer.
• Problemer med grene: Når du skifter gren i det overordnede projekt, kan det kræve manuelle opdateringer af undermoduler.

Git Subtree fungerer derimod anderledes. Det kopierer i praksis det eksterne repositories indhold ind i en undermappe i dit hovedprojekt.

• Integreret historik: Afhængighedens historik flettes direkte ind i historikken for dit hovedrepository.
• Ingen separate repositories: Det er blot en undermappe, ikke et separat Git-repository i dit repository.
• Forenklet arbejdsgang: Det fremstår som en almindelig del af dit projekt, hvilket gør det lettere for nye bidragydere.

Subtree er særligt nyttigt, når enkelhed og oplevelsen af ét enkelt repository er prioriteter:

• Lettere kloning: Der kræves ingen særlige kommandoer; en simpel git clone henter alt.
• Ét repository: Al kode ligger i ét repository, hvilket forenkler CI/CD og adgangstilladelser.
• Ingen detached HEAD: Du er altid på en branch i hovedrepositoryet.
• Enklere for brugere: Udviklere behøver ikke lære branchespecifikke kommandoer.
• Lettere refaktorering: Det er som at flytte enhver anden fil i dit repository, når du flytter filer i subtree'et.

Selvom Git Subtree er enklere på nogle områder, har det også sine egne ulemper:

• Rodet historik: Afhængighedens historik flettes ind i dit hovedprojekt, hvilket potentielt gør din git log længere og sværere at læse.
• Komplekse opdateringer: Det kræver specifikke git subtree pull-kommandoer at hente opdateringer fra det upstream-subtree, hvilket kan være mindre intuitivt end en simpel git pull.
• Push af ændringer upstream: Det kræver også en specifik git subtree push-kommando at sende ændringer, der er foretaget i subtree'et, tilbage til det oprindelige repository, og processen kan være mere omfattende.
• Duplikering: Afhængighedens kode kopieres fysisk ind i dit repository, så det bliver større.

Den mest grundlæggende forskel ligger i, hvordan de håndterer historik:

• Submodules: Opretholder en klar adskillelse. Dit hovedrepository registrerer kun en reference til en bestemt commit i submodulets uafhængige historik.
• Subtree: Integrerer afhængighedens historik direkte i historikken for dit hovedprojekt. Det er, som om du selv havde kopieret og committet alle disse ændringer.

Denne forskel påvirker alt fra kloning til opdatering og samarbejde om afhængigheden.

Overvej udviklernes daglige arbejdsgang:

• Submodules: Mere eksplicit. Udviklerne skal være opmærksomme på, at de arbejder med et separat Git-repository. Kommandoer som git submodule update er nødvendige.
• Subtree: Mere problemfri. Når subtree'et er tilføjet, opfører det sig som enhver anden mappe i hovedrepositoryet. Grundlæggende Git-kommandoer (add, commit, pull, push) fungerer normalt uden særlige hensyn til selve subtree'et.

Subtree gør det generelt lettere for teammedlemmer at komme i gang, hvis de blot skal bruge afhængigheden.

Så hvilket skal du vælge?

• Brug Submodules når:
  - Du ofte skal bidrage til afhængighedens upstream.
  - Afhængigheden er et særskilt projekt, der udvikles aktivt.
  - Du foretrækker streng versionsfastlåsning og adskilte historikker.
  - Dit team er fortroligt med Git-submodule-arbejdsgange.
• Brug Subtree når:
  - Du ønsker en enklere arbejdsgang for dem, der bruger afhængigheden.
  - Du sjældent har brug for at sende ændringer tilbage til upstream-afhængigheden.
  - Afhængigheden er intern, eller du blot vil inkludere koden i dit projekt.
  - En samlet historik i ét repository foretrækkes af hensyn til enkelheden.

I denne lektion gennemgik vi de grundlæggende forskelle mellem Git Submodules og Git Subtree.

• Submodules opretholder separate historikker og kræver eksplicitte kommandoer, hvilket giver stærk isolering og gør det nemt at bidrage upstream.
• Subtree integrerer historikken, forenkler kloning og giver en samlet repository-oplevelse, men kan gøre opdateringer og push upstream mere komplekse.

Dit valg afhænger af dit projekts behov, teamets fortrolighed og dine afhængigheders karakter. Begge er stærke værktøjer, når de bruges i den rette sammenhæng!