Git vs GitHub - Hvad er versionskontrol, og hvordan fungerer det?

Har du nogensinde været forvirret af, hvordan Git og GitHub fungerer? Vær ikke bekymret - du er ikke alene. Git og GitHub kan være vanskelige nogle gange, men i slutningen af ​​dette indlæg vil du have en god forståelse af de to.

I starten kan det være fristende at tro, at Git og GitHub er den samme ting. Men i virkeligheden er de ikke. Det er faktisk muligt at bruge Git uden GitHub! Og i sidste ende eksisterer de to til forskellige formål.

Dette indlæg begynder med at se godt på formålene med Git og GitHub. Derefter lærer vi om de største forskelle mellem disse to vitale teknologier.

Uden yderligere ado, lad os komme i gang med Git.

Hvad er Git?

Git er et distribueret versionskontrolsystem (DVCS), der bruges til at gemme forskellige versioner af en fil (eller et sæt filer), så enhver version kan hentes efter ønske.

Git gør det også nemt at registrere og sammenligne forskellige filversioner. Dette betyder, at detaljerne om, hvad der ændrede sig, hvem der ændrede hvad, eller hvem der startede et problem, kan gennemgås når som helst.

Men hvis Git er et distribueret versionskontrolsystem, hvad betyder disse udtryk præcist?

Hvad betyder "distribueret"?

Udtrykket "distribueret" betyder, at når du instruerer Git om at dele et projekts katalog, deler Git ikke kun den nyeste filversion. I stedet distribuerer den hver version, den har optaget til det projekt.

Dette "distribuerede" system er i skarp kontrast til andre versionskontrolsystemer. De deler kun hvilken enkelt version en bruger eksplicit har tjekket ud fra den centrale / lokale database.

Okay, så "distribueret" betyder distribuere alle - ikke kun udvalgte få - versioner af et projekts filer, som Git har optaget. Men hvad er et versionskontrolsystem præcist?

Hvad er et versionskontrolsystem?

Et versionskontrolsystem (VCS) henviser til den metode, der bruges til at gemme en fils versioner til fremtidig reference.

Intuitivt mange mennesker allerede versionsstyring deres projekter ved at omdøbe forskellige versioner af den samme fil på forskellige måder som blogScript.js, blogScript_v2.js, blogScript_v3.js, blogScript_final.js, blogScript_definite_final.js, og så videre. Men denne tilgang er fejlbehæftet og ineffektiv for teamprojekter.

Sporing af, hvad der ændrede sig, hvem der ændrede det, og hvorfor det blev ændret, er en kedelig indsats med denne traditionelle tilgang. Dette belyser vigtigheden af ​​et pålideligt og samarbejde versionskontrolsystem som Git.

For at få det bedste ud af Git er det dog vigtigt at forstå, hvordan Git håndterer dine filer.

Files hedder i Git

I Git er der tre primære tilstande (betingelser), hvor en fil kan være: modificeret tilstand , iscenesat tilstand eller forpligtet tilstand .

Ændret tilstand

En fil i ændret tilstand er en revideret - men uforpligtende (ikke registreret) - fil.

Med andre ord, filer i den modificerede tilstand er filer, du har ændret, men har ikke eksplicit instrueret Git om at overvåge.

Iscenesat tilstand

Filer i den iscenesatte tilstand er modificerede filer, der er valgt - i deres nuværende tilstand (version) - og forberedes på at blive gemt (begået) i .gitlageret under det næste snapshot.

Når en fil er iscenesat, betyder det, at du eksplicit har godkendt Git til at overvåge filens version.

Forpligtet stat

Filer i den forpligtede tilstand er filer, der er gemt i .gitarkivet.

En forpligtet fil er således en fil, hvor du har optaget den iscenesatte version i Git-biblioteket (mappen).

Bemærk: Filens tilstand bestemmer placeringen, hvor Git vil placere den.

Filplaceringer

Der er tre nøgleplaceringer, der kan have versioner af en fil, mens versionen styrer med Git: arbejdsmappen , mellemstationer eller Git-biblioteket .

Arbejdsmappe

Arbejdsmappen er en lokal mappe til et projekts filer. Dette betyder, at enhver mappe oprettet hvor som helst på et system er en fungerende mappe.

Bemærk:

  • Filer i den ændrede tilstand findes i arbejdsmappen.
  • Arbejdsmappen er forskellig fra .gitkataloget. Det vil sige, du opretter en arbejdsmappe, mens Git opretter en .gitmappe.
  • Tjek denne sammenligningsartikel for flere forskelle mellem de to arkiver.

Iscenesættelsesområde

Iscenesættelsesområdet - teknisk kaldet "indeks" i Git-sprog - er en fil, der normalt er placeret i .gitbiblioteket, der gemmer oplysninger om filer, der er næste i linjen, der skal bruges i .gitbiblioteket.

Bemærk:

  • Filer i iscenesat tilstand findes i iscenesættelsesområdet.

Git-bibliotek

Den .gitmappe er den mappe (også kaldet ”repository”), der Git skaber inde arbejdsmappen, du har instrueret den til at spore.

Også den .gitmappe er der, hvor Git gemmer objekt databaser og metadata af fil (er) du har instrueret det at overvåge.

Bemærk:

  • Den .gitmappe er livet for Git - det er det element kopieres, når du klone et opbevaringssted fra en anden computer (eller fra en online platform som GitHub).
  • Filer i den forpligtede tilstand findes i Git-biblioteket.

Den grundlæggende Git-arbejdsgang

Arbejde med Git Version Control System ser sådan ud:

Git grundlæggende arbejdsflowdiagram
  1. Rediger filer i arbejdskataloget.

    Bemærk, at enhver fil, du ændrer, bliver en fil i den ændrede tilstand .

  2. Indsæt selektivt de filer, du vil forpligte dig til .gitbiblioteket.

    Bemærk, at enhver fil, du indsætter (tilføjer) i mellemstationer, bliver en fil i iscenesat tilstand .

    Vær også opmærksom på, at iscenesatte filer endnu ikke er i .gitdatabasen.

    Staging betyder, at oplysninger om den iscenesatte fil bliver inkluderet i en fil (kaldet "indeks") i .gitlageret.

  3. Forpligt filerne, du har iscenesat, i .gitbiblioteket. Det vil sige gemme et øjebliksbillede af de iscenesatte filer permanent i .gitdatabasen.

    Bemærk, at enhver filversion, du forpligter dig til .gitbiblioteket, bliver en fil i den forpligtede tilstand .

Kernen indtil videre

Den lange og korte diskussion hidtil er, at Git er et strålende versionskontrolsystem til kompetent versionering, styring og distribution af filer. Tjek denne enkle guide for at lære, hvordan du bruger Git effektivt.

Men hæng et øjeblik, hvis Git hjælper med effektivt at administrere og distribuere forskellige versioner af et projekts fil, hvad er GitHubs formål?

GitHub afmystificeret

GitHub er en webbaseret platform, hvor brugere kan være vært for Git-arkiver. Det hjælper dig med at lette nem deling og samarbejde om projekter med enhver til enhver tid.

GitHub tilskynder også til bredere deltagelse i open source-projekter ved at give en sikker måde at redigere filer i en anden brugers lager.

Følg nedenstående trin for at være vært (eller dele) et Git-arkiv på GitHub:

Trin 1: Tilmeld dig en GitHub-konto

Det første skridt til at begynde at hoste på GitHub er at oprette en personlig konto. Besøg den officielle registreringsside for at tilmelde dig.

Trin 2: Opret et eksternt lager i GitHub

Efter tilmelding til en konto skal du oprette et hjem (et lager) i GitHub til det Git-lager, du vil dele.

Trin 3: Tilslut projektets Git-bibliotek til det eksterne lager

Når du har oprettet et fjernlager til dit projekt, skal du linke projektets .gitbibliotek - placeret lokalt på dit system - med fjernlageret på GitHub.

For at oprette forbindelse til det eksterne lager, skal du gå ind i rodmappen på det projekt, du vil dele via din lokale terminal, og køre:

git remote add origin //github.com/yourusername/yourreponame.git

Bemærk:

  • Udskift yourusernamei koden ovenfor med dit GitHub-brugernavn.

    Udskift ligeledes yourreponamemed navnet på det eksterne lager, du vil oprette forbindelse til.

  • Kommandoen ovenfor indebærer, at git skal tilføje den angivne URL til det lokale projekt som en fjernreference, som den lokale .gitbibliotek kan interagere med.
  • Den originmulighed i kommandoen over er standard navn (en kort navn) Git giver til server hosting din fjernbetjening repository.

    I stedet for serverens URL bruger Git det korte navn origin.

  • Det er ikke obligatorisk at holde fast ved serverens standardnavn. Hvis du foretrækker et andet navn i stedet for origin, skal du blot erstatte originnavnet i git remote addkommandoen ovenfor med ethvert navn, du foretrækker.
  • Husk altid, at en servers korte navn (for eksempel   origin) ikke er noget specielt! Den findes kun - lokalt - for at hjælpe dig med nemt at henvise til serverens URL. Så føl det at ændre det til et kort navn, som du nemt kan henvise til.
  • For at omdøbe en eksisterende ekstern URL skal du bruge git remote renamekommandoen således:
git remote rename theCurrentURLName yourNewURLName
  • Når du kloner (downloader) enhver ekstern repo, navngiver Git automatisk denne repos URL origin. Du kan dog angive et andet navn med git clone -o yourPreferredNamekommandoen.
  • For at se den nøjagtige URL, der er gemt for kaldenavne origin, skal du køre git remote -vkommando.

Trin 4: Bekræft forbindelsen

Når du har tilsluttet dit Git-bibliotek til det eksterne lager, skal du kontrollere, om forbindelsen var vellykket ved at køre git remote -vpå kommandolinjen.

Derefter skal du kontrollere output for at bekræfte, at den viste URL er den samme som den eksterne URL, du har til hensigt at oprette forbindelse til.

Bemærk:

  • Se artiklen "Opretter forbindelse med SSH", hvis du ønsker at oprette forbindelse ved hjælp af SSH-URL i stedet for HTTPS-URL.
  • Hvis du ikke er sikker på, hvilken fjernwebadresse du skal bruge, skal du tjekke "Hvilken fjernwebadresse skal jeg bruge?" artikel.
  • Ønsker du at ændre din eksterne URL? Ændring af en fjernbetjenings URL er en fremragende guide.

Trin 5: Skub en lokal Git-repo til den eksterne repo

Efter at have tilsluttet din lokale mappe til det eksterne lager, kan du derefter begynde at skubbe (uploade) dit lokale projekt opstrøms.

Når du er klar til at dele dit projekt andetsteds, på en hvilken som helst ekstern repo, skal du blot bede Git om at skubbe alle dine forpligtelser, grene og filer i din lokale .gitmappe til fjernlageret.

Kodesyntaxen, der bruges til at uploade (skubbe) en lokal Git-mappe til et eksternt lager er git push -u remoteName branchName.

Det vil sige at .gitkøre: for at skubbe til din lokale mappe, og forudsat at fjernadressens korte navn er "oprindelse":

git push -u origin master

Bemærk:

  • Kommandoen ovenfor indebærer, at git skal skubbe din lokale masterfilial til den eksterne masterfilial, der findes på den URL, der hedder oprindelse .
  • Teknisk set kan du erstatte originindstillingen med fjernopbevaringsadressens URL. Husk, at originindstillingen kun er et kaldenavn på den URL, du har registreret i dit lokale .gitbibliotek.
  • Den -uflag (opstrøms / sporing henvisning flag) forbinder automatisk .gitmappes lokale afdeling med fjernbetjeningen gren. Dette giver dig mulighed for at bruge git pulluden argumenter.

Trin 6: Bekræft upload

Til sidst skal du gå tilbage til din GitHub-arkivside for at bekræfte, at Git med succes har skubbet dit lokale Git-bibliotek til det eksterne lager.

Bemærk:

  • Det kan være nødvendigt at opdatere siden til det eksterne arkiv, så ændringerne afspejles.
  • GitHub har også en gratis valgfri facilitet til at konvertere dit fjernlager til et funktionelt websted. Lad os se "hvordan" nedenfor.

Udgiv dit websted med GitHub-sider

Når du har skubbet dit projekt til dit fjernlager, kan du nemt offentliggøre det på nettet sådan:

  1. Sørg for, at navnet på den vigtigste HTML-fil for dit projekt er index.html.
  2. På GitHubs webstedsplatform skal du gå ind i arkivet for det projekt, du vil offentliggøre, og klikke på arkivets fane for indstillinger .
  3. Rul ned til GitHub Sider sektionen og ændre Kilde gren fra ingen til mester .
  4. Derefter vises en meddelelse, der siger, "Dit websted er offentliggjort på //dit-navn.github.io/dit-github-repo-navn/ ".
  5. Nu kan du se - og offentliggøre - dit projekt på den angivne URL.

Dette afsnit har kun ridset overfladen af ​​at offentliggøre dit projekt med GitHub. For at lære mere om GitHub-sider, se denne dokumentation "Arbejde med GitHub-sider".

Kort sagt

GitHub er en online platform til hosting (eller deling) af Git-arkiver. Det hjælper dig med at skabe en mulighed for nemt at samarbejde om projekter med hvem som helst, hvor som helst og når som helst.

Stadig i tvivl?

Er du stadig forvirret over den fine linje mellem Git og GitHub? Bare rolig - jeg har dig dækket. Nedenfor er fem nøgleforskelle mellem Git og GitHub.

Forskel 1: Git vs. GitHub - Primær funktion

Git er et distribueret versionskontrolsystem, der registrerer forskellige versioner af en fil (eller et sæt filer). Det giver brugerne adgang til, sammenlignet, opdateret og distribueret hvilken som helst af de optagede version (er) til enhver tid.

Men GitHub er primært en hosting platform for hosting Git repositories online. Det giver brugerne mulighed for at holde deres eksterne lager private eller åbne for samarbejdsindsats.

Forskel 2: Git vs. GitHub - Driftsplatform

Brugere installerer og betjener Git på deres lokale maskiner. Dette betyder, at de fleste af Gits operationer kan opnås uden internettet.

GitHub er dog en webbaseret tjeneste, der kun fungerer online. Dette betyder, at du har brug for internettet til at gøre noget på GitHub.

Forskel 3: Git vs. GitHub - opfindere

Linus Torvalds begyndte udviklingen af ​​Git i april 2005.

Chris Wanstrath, PJ Hyett, Tom Preston-Werner og Scott Chacon grundlagde GitHub.com i februar 2008.

Forskel 4: Git vs. GitHub - Vedligeholdere

I juli 2005 overgav Linus Torvalds Gits vedligeholdelse til Junio ​​C. Hamano - som har været hovedvedligeholder siden da.

Og Microsoft købte GitHub i oktober 2018.

Forskel 5: Git vs. GitHub - Konkurrenter

Populære alternativer til Git er Mercurial, Team Foundation Version Control (TFVC), Perforce Helix Core, Apache Subversion og IBM Rational ClearCase.

GitHubs nærmeste konkurrenter er GitLab, Bitbucket, SourceForge, Cloud Source Repositories og AWS CodeCommit.

Alt i alt

Git og GitHub er to forskellige enheder, der hjælper dig med at administrere og hoste filer. Med andre ord tjener Git til at kontrollere filversioner, mens GitHub er en platform til hosting af Git-arkiver.

Nyttig ressource

  • Sådan bruges Git - En fantastisk guide med fantastiske tip