Hvert Git-depot inneholder fire komponenter:
Alt fra innspilling forplikter seg til distribuert samarbeid dreier seg om disse kjerneobjektene.
Arbeidsoversikten er hvor du faktisk redigerer filer, kompilerer kode og ellers utvikler prosjektet. For all hensikt kan du behandle arbeidskatalogen som en vanlig mappe. Bortsett fra, har du nå tilgang til alle slags kommandoer som kan registrere, endre og overføre innholdet i den mappen.
Staging-området er en mellommann mellom arbeidskatalogen og prosjekthistorikken. I stedet for å tvinge deg til å begå alle endringene dine samtidig, lar Git deg gruppere dem i relaterte endringsinnstillinger. Behandlede endringer er ikke en del av prosjekthistorikken.
Når du har konfigurert endringene i oppføringsområdet, kan du forplikte det til prosjektloggen, der det vil forbli som en "sikker" revisjon. Forpliktelser er "trygge" i den forstand at Git aldri vil forandre dem selv, selv om det er mulig for du å skrive om prosjekthistorikk manuelt.
Så langt kan vi fremdeles bare lage en lineær prosjekthistorikk, legge til en forpliktelse på toppen av en annen. Grener gjør det mulig å utvikle flere ikke-relaterte funksjoner parallelt ved å forkaste prosjekthistorikken.
Git-grener er ikke som grener av sentraliserte versjonskontrollsystemer. De er billige å lage, enkle å slå sammen og enkelt å dele, så Git-baserte utviklere bruker grener til alt-fra langvarige funksjoner med flere bidragsytere til 5-minutters reparasjoner. Mange utviklere bare jobber i dedikert emne grener, forlater hovedgrenen historie for offentliggjøring.
Denne leksjonen representerer et kapittel fra Git Succinctly, en gratis eBok fra teamet på Syncfusion.