Leer de basis van Git in minder dan 10 minuten
door Gowtham Venkatesan
Ja, de titel is een clickbait. Het is onmogelijk dat je de basis van de git-technologie in slechts 10 minuten kunt begrijpen. Maar in ongeveer 25 minuten kom je al aardig in de buurt. En dat is het doel van dit artikel.
Als je aan de slag wilt met het leren over Git technologie, dan ben je hier op de juiste plek. Dit is een uitgebreide beginnershandleiding voor Git. Er zijn veel clients voor Git. De technologie is allemaal hetzelfde, ongeacht de client. Maar in deze gids zullen we GitHub gebruiken om Git te begrijpen.
Laten we beginnen!
Wat is Versie Controle?
Versie controle is een systeem dat veranderingen aan een bestand of een set bestanden in de tijd vastlegt, zodat je later specifieke versies kunt terughalen. In het ideale geval kunnen we dus elk bestand in de computer op versiebeheer plaatsen.
Umm… Oké… Maar waarom dan?
Hierom:
Een versiebeheersysteem (VCS) stelt je in staat om bestanden terug te draaien naar een eerdere staat, het hele project terug te draaien naar een eerdere staat, wijzigingen die in de loop van de tijd zijn aangebracht te bekijken, te zien wie als laatste iets heeft gewijzigd dat een probleem zou kunnen veroorzaken, wie een probleem heeft geïntroduceerd en wanneer, en nog veel meer. Het gebruik van een VCS betekent ook dat als je dingen verknoeit of bestanden verliest, je ze over het algemeen gemakkelijk kunt herstellen. En soms wil je gewoon weten “wie deze rotzooi geschreven heeft”, en dan is toegang tot die informatie de moeite waard.
Dus wat is Git?
Git is een versiebeheersysteem voor het bijhouden van wijzigingen in computerbestanden en het coördineren van werk aan die bestanden tussen meerdere mensen. Git is een gedistribueerd versiebeheersysteem. Dus Git vertrouwt niet noodzakelijkerwijs op een centrale server om alle versies van de bestanden van een project op te slaan. In plaats daarvan “kloont” iedere gebruiker een kopie van een repository (een verzameling bestanden) en heeft de volledige geschiedenis van het project op zijn eigen harde schijf. Deze kloon heeft alle metadata van het origineel, terwijl het origineel zelf is opgeslagen op een zelf gehoste server of een hosting service van een derde partij zoals GitHub.
Git helpt je om bij te houden welke veranderingen je in je code aanbrengt. Het is eigenlijk de geschiedenis tab van je code editor (Zonder incognito mode?). Als je op een gegeven moment tijdens het coderen op een fatale fout stuit en niet weet wat de oorzaak is, kun je altijd teruggaan naar de stabiele staat. Het is dus zeer nuttig voor debugging. Of u kunt gewoon zien welke wijzigingen u in de loop der tijd in uw code hebt aangebracht.
In het bovenstaande voorbeeld staan alle drie de kaarten voor verschillende versies van hetzelfde bestand. We kunnen op elk moment kiezen welke versie van het bestand we willen gebruiken. Dus ik kan heen en weer springen naar elke versie van het bestand in het git-tijd continuüm.
Git helpt je ook om code tussen meerdere mensen te synchroniseren. Dus stel je voor dat jij en je vriend samen aan een project werken. Jullie werken allebei aan dezelfde project bestanden. Nu neemt Git de wijzigingen die jij en je vriend onafhankelijk van elkaar hebben gemaakt en voegt ze samen in een enkele “Master” repository. Dus door Git te gebruiken kun je er zeker van zijn dat jullie beiden aan de meest recente versie van de repository werken. Dus je hoeft je geen zorgen te maken over het mailen van je bestanden naar elkaar en het werken met een belachelijk aantal kopieën van het originele bestand. En samenwerken op lange afstand wordt net zo makkelijk als HTML ?.
Git Workflow:
Voordat we met Git commando’s aan de slag gaan, is het noodzakelijk dat je begrijpt waar het voor staat.
Wat is een Repository ?
Een repository a.k.a. repo is niets anders dan een verzameling broncode.
Er zijn vier fundamentele elementen in de Git Workflow.
Working Directory, Staging Area, Local Repository en Remote Repository.
Als je een bestand in je Working Directory bekijkt, kan het in drie mogelijke statussen zijn.
- Het kan ge-staged zijn. Dat betekent dat de bestanden met de bijgewerkte wijzigingen gemarkeerd zijn om gecommit te worden in het lokale archief, maar nog niet gecommit zijn.
- Het kan gewijzigd zijn. Dat betekent dat de bestanden met de bijgewerkte wijzigingen nog niet in het lokale archief zijn opgeslagen.
- Het kan worden vastgelegd. Dat betekent dat de wijzigingen die je in het bestand hebt aangebracht veilig in het lokale archief zijn opgeslagen.
-
git add
is een commando dat wordt gebruikt om een bestand dat in de werkdirectory staat aan het staging gebied toe te voegen. -
git commit
is een commando dat gebruikt wordt om alle bestanden die in de staging staan toe te voegen aan de lokale repository. -
git push
is een commando dat gebruikt wordt om alle gecommitteerde bestanden in de lokale repository toe te voegen aan de remote repository. Dus in de remote repository zullen alle bestanden en wijzigingen zichtbaar zijn voor iedereen met toegang tot de remote repository. -
git fetch
is een commando dat gebruikt wordt om bestanden uit de remote repository naar de local repository te halen, maar niet in de werkdirectory. -
git merge
is een commando dat wordt gebruikt om de bestanden van het lokale archief in de werkmap te krijgen. -
git pull
is een commando dat wordt gebruikt om de bestanden van het externe archief direct in de werkmap te krijgen. Het is gelijkwaardig aan eengit fetch
en eengit merge
.
Nu we weten wat Git is en de basis terminologieën, laten we eens kijken hoe we een bestand onder git kunnen plaatsen. We gaan het op de goede manier doen en op de moeilijke manier. Zonder GUI applicaties.
Ik ga er vanuit dat je al een bestand hebt dat je onder versie beheer wilt plaatsen. Zo niet, maak dan een voorbeeld map aan genaamd ‘MuskCult’ en plaats daar wat voorbeeld code bestanden in.
Stap 0: Maak een GitHub Account. Duh.
Als je er nog geen hebt, kun je er hier een maken.
Stap 1: Zorg ervoor dat je Git op je machine hebt geïnstalleerd.
Als je op een Mac zit, start dan de terminal en voer het volgende commando in:
$ git --version
Dit zal vragen om een installer te openen als je git nog niet hebt. Dus installeer het met de installer. Als je git al hebt, zal het je alleen laten zien welke versie van git je geïnstalleerd hebt.
Als je Linux(deb) draait, voer dan het volgende in de terminal in:
$ sudo apt install git-all
Als je op Windows draait:
$ get a mac
Een grapje… Relax… Het aantal mensen dat ik getriggerd heb… Phew…
Ga naar deze link of deze link voor meer info over hoe je het kunt krijgen.
Stap 2: Vertel Git wie je bent.
Stel jezelf voor. Schuif in. Serieus, noem je Git gebruikersnaam en email adres, want elke Git commit zal deze informatie gebruiken om jou als de auteur te identificeren.
$ git config --global user.name "YOUR_USERNAME"
$ git config --global user.email "[email protected]"
$ git config --global --list # To check the info you just provided
Stap 3: Genereer/check je machine voor bestaande SSH keys. (Optioneel)
Waarom vraagt u dat? Met het SSH-protocol kunt u verbinding maken met en u authenticeren bij externe servers en services. Met SSH sleutels, kun je verbinding maken met GitHub zonder bij ieder bezoek je gebruikersnaam of wachtwoord op te geven.
Volg deze link om meer te leren over SSH.
Ga hierheen om te controleren of je een bestaande SSH sleutel hebt.
Ga hierheen om een SSH sleutel te genereren.
Ga hierheen om de SSH sleutel aan je GitHub account toe te voegen.
En tot slot, ga hierheen om de verbinding te testen.
Als je SSH hebt ingesteld, vervang je elk git commando dat een link heeft door:
Instead of : https://github.com/username/reponame
You use : [email protected]/username/reponame.git
Note : You can use both ways alternatively
Ik zal het SSH protocol gebruiken in deze tutorial.
Stap 4: Laten we Git
Maak een nieuwe repository aan op GitHub. Volg deze link.
Nu, lokaliseer naar de map die je onder git wilt plaatsen in je terminal.
$ cd Desktop/MuskCult
Initialiseer Git:
En om het onder git te plaatsen, voer in:
$ touch README.md # To create a README file for the repository$ git init # Initiates an empty git repository
Nu ga je het README.md bestand om informatie over de repository te geven.
Bestanden toevoegen aan het Staging Gebied voor commit:
Nu de bestanden toevoegen aan de git repository voor commit:
$ git add . # Adds all the files in the local repository and stages them for commit
OR if you want to add a specific file
$ git add README.md # To add a specific file
Voordat we gaan committen, laten we eens kijken welke bestanden er ge-staged zijn:
$ git status # Lists all new or modified files to be committed
Commit Wijzigingen die je in je Git Repo hebt aangebracht:
Nu de bestanden die je aan je git repo hebt toegevoegd committen:
$ git commit -m "First commit"# The message in the " " is given so that the other users can read the message and see what changes you made
Uncommit Wijzigingen die je net aan je Git Repo hebt toegevoegd:
Voor het geval dat je net een fout in je code hebt gemaakt of een ongewenst bestand in de repository hebt geplaatst, kun je de bestanden die je net hebt toegevoegd uncommitten door gebruik te maken van:
$ git reset HEAD~1# Remove the most recent commit# Commit again!
Voeg een externe oorsprong toe en Push:
Nu zal elke keer dat je wijzigingen in je bestanden aanbrengt en ze opslaat, het niet automatisch op GitHub worden geüpdatet. Alle wijzigingen die we in het bestand hebben gemaakt, worden bijgewerkt in de lokale repository. Om nu de wijzigingen in de master te updaten:
$ git remote add origin remote_repository_URL# sets the new remote
Het git remote commando laat je verbindingen met andere repositories maken, bekijken en verwijderen.
$ git remote -v# List the remote connections you have to other repositories.
Het git remote -v commando toont de URL’s van de remote verbindingen die je hebt met andere repositories.
$ git push -u origin master # pushes changes to origin
Nu pusht het git push commando de veranderingen in je lokale repository naar de remote repository die je als bron hebt opgegeven.
En als we nu naar onze repository pagina op GitHub gaan en deze bekijken, zou het er ongeveer zo uit moeten zien:
En dat is het. Je hebt zojuist de bestanden toegevoegd aan de repository die je zojuist op GitHub hebt aangemaakt.
De veranderingen zien die je in je bestand hebt aangebracht:
Als je eenmaal begint met het aanbrengen van veranderingen in je bestanden en je slaat ze op, zal het bestand niet meer overeenkomen met de laatste versie die op git is gecommit. Om de wijzigingen te zien die je net hebt gemaakt:
$ git diff # To show the files changes not yet staged
Terug naar de laatst gecommitteerde versie op de Git Repo:
Nu kun je ervoor kiezen om terug te gaan naar de laatst gecommitteerde versie door in te voeren:
$ git checkout .
OR for a specific file
$ git checkout -- <filename>
Bekijk Commit Geschiedenis:
Je kunt het git log commando gebruiken om de geschiedenis te zien van de commit die je in je bestanden hebt gedaan:
$ git log
Elke keer dat je veranderingen maakt die je op GitHub terug wilt zien, zijn de volgende de meest voorkomende stroom van commando’s:
$ git add .$ git status # Lists all new or modified files to be committed$ git commit -m "Second commit"$ git push -u origin master
Als we nu onze repo gaan bekijken, kunnen we vaststellen of de commit succesvol was door naar de commit boodschap voor elk bestand te kijken.
Stap 5 : Dat is allemaal goed en wel… Maar hoe download ik en werk ik aan andere repositories op GitHub?
Het klonen van een Git Repo:
Locate naar de directory waar je de repo wilt klonen. Kopieer de link van de repository die je wilt en voer het volgende in:
$ git clone remote_repository_URL
Voel je vrij om door te gaan en de repo te clonen die ik hierboven heb gemaakt met: https://github.com/Gothamv/MuskCult
Wijzigingen naar de Git Repo pushen:
Nu kun je aan de bestanden werken die je wilt en de wijzigingen lokaal committen. Als je wijzigingen naar die repository wilt pushen, moet je of toegevoegd worden als een medewerker voor de repository of je moet iets maken dat bekend staat als pull request. Kijk hier hoe je dat doet en geef me een pull request met je codebestand.
Samenwerken:
Stel je voor dat jij en je vriend aan een project werken. Jullie werken allebei aan dezelfde projectbestanden. Elke keer als jij wat verandert en het naar de master repo pushed, moet je vriend de veranderingen die jij naar de git repo hebt gepushed ook weer terughalen. Dus om er zeker van te zijn dat je op de laatste versie van de git repo werkt, elke keer als je begint te werken, is een git pull commando de manier om te gebruiken.
Nu volgt een voorbeeld van een project waar mijn vriend en ik aan werken:
Om er zeker van te zijn dat die wijzigingen ook op mijn lokale kopie van de repo worden weergegeven:
$ git pull origin master
Hier zijn nog twee handige git commando’s:
$ git fetch AND$ git merge
In de eenvoudigste termen, git fetch
gevolgd door een git merge
komt overeen met een git pull
. Maar waarom bestaan deze dan?
Als je git pull
gebruikt, probeert Git automatisch je werk voor je te doen. Het is context gevoelig, dus Git zal alle pulled commits samenvoegen in de branch waar je op dat moment in werkt. git pull
voegt de commits automatisch samen zonder je ze eerst te laten reviewen.
Als je git fetch
, verzamelt Git alle commits van de doel branch die nog niet in je huidige branch bestaan en slaat ze op in je lokale repository. Maar, het voegt ze niet samen met je huidige branch. Dit is vooral handig als je je repository up to date moet houden, maar aan iets werkt dat zou kunnen breken als je je bestanden update. Om de commits in je master branch te integreren, gebruik je git merge
.
One More Thing:
.gitignore
Wat is het?
.gitignore
vertelt git welke bestanden (of patronen) het moet negeren. Het wordt meestal gebruikt om te voorkomen dat voorbijgaande bestanden uit je werkdirectory committen, die niet nuttig zijn voor andere medewerkers, zoals compilatieproducten, tijdelijke bestanden die IDE’s maken, etc.
Dus in bovenstaand voorbeeld worden bestanden als __pycache__, .DS_Store door het systeem gebruikt om informatie op te slaan voor snellere toegang. Dit is niet nuttig voor andere medewerkers. Dus kunnen we Git vertellen om ze te negeren door een .gitignore
bestand toe te voegen.
Gebruik het touch commando om het .gitignore
bestand te maken:
$ touch .gitignore
En je kunt de volgende patronen toevoegen om Git te vertellen om zulke bestanden te negeren.
/*.cmake/*.DS_Store/.user/buildetc. depending upon the files you want git to untrack
En dat is het zo’n beetje voor de basis. Blijf kijken voor deel 2, waarin we ons zullen richten op Branch, Merge, Stash, Rebase etc.
Als je dit artikel leuk vond, vergeet dan niet op de Clap-knop te drukken en zorg ervoor dat je me volgt voor deel 2.
Referenties :
Een bestaand project aan GitHub toevoegen met behulp van de commandoregel – Gebruikersdocumentatie
Door je bestaande werk op GitHub te zetten, kun je op veel geweldige manieren delen en samenwerken. Als je je…help.github.comHoe maak je (bijna) alles ongedaan met Git
Een van de handigste functies van elk versiebeheersysteem is de mogelijkheid om je fouten “ongedaan” te maken. In Git is “ongedaan maken”…blog.github.comGit op de commandline – Wees niet bang om te committen 0.3 documentatie
Er zijn andere manieren om Git te installeren; je kunt zelfs een grafische Git applicatie krijgen, die de commandline…dont-be-afraid-to-commit.readthedocs.ioStart met Git op de commandline | GitLab
Documentatie voor GitLab Community Editie, GitLab Enterprise Editie, Omnibus GitLab, en GitLab Runner.docs.gitlab.comWat is het verschil tussen ‘git pull’ en ‘git fetch’?
Moderator Opmerking: Aangezien er al zevenenzestig antwoorden op deze vraag zijn geplaatst (waarvan sommige zijn verwijderd)…stackoverflow.com