Nederlands
Menu

Wat is Git?

Een gedistribueerd versiebeheersysteem dat de geschiedenis van wijzigingen in bestanden vastlegt en beheert. Wijzigingen die in de werkdirectory zijn aangebracht, worden met git add in de staging area geregistreerd, met git commit in de lokale repository vastgelegd en met git push naar een remote repository zoals GitHub gestuurd. Met branches kan parallel worden ontwikkeld, en ze worden samengevoegd met git merge. Naast broncode wordt Git ook gebruikt om RTL, testbenches voor verificatie, scripts en dergelijke te beheren.

Japanse benaming: Git

“Git” komt voor in 5 oefenvragen uit 2 onderwerpen, bijv. Basis van Linux en de opdrachtregel, Softwareontwikkeling en projectmanagement.

Vakgebied: Basis van Linux en de opdrachtregel

De drie plaatsen

Git onderscheidt de werkdirectory waarin bestanden worden bewerkt, de staging area (index) met de wijzigingen voor de volgende commit, en de repository (de directory .git) waarin de geschiedenis van de commits wordt bewaard. git status toont de verschillen tussen deze drie; git diff toont het verschil tussen de werkdirectory en de staging area, en git diff --staged dat tussen de staging area en de laatste commit.

Branches en remotes

Een branch is een naam voor een vertakking in de geschiedenis van de commits, waarmee nieuwe functies of correcties kunnen worden ontwikkeld zonder de hoofdbranch te beïnvloeden. git clone kopieert een remote repository naar de eigen computer, git pull haalt nieuwe commits van de remote binnen, en git push stuurt de eigen commits. Wanneer branches worden samengevoegd die dezelfde plaats elk anders hebben gewijzigd, ontstaat een conflict dat een mens moet oplossen.

Wat je niet volgt

Bestanden die door builds en simulaties worden gegenereerd, logs, grote golfvormgegevens en dergelijke worden in .gitignore gezet om ze buiten het volgen te houden. Een bestand dat al eens is gecommit, blijft gevolgd, ook als het in .gitignore staat, dus het wordt met git rm --cached uit het volgen gehaald. Een wachtwoord of sleutel die per ongeluk is gecommit, blijft in de geschiedenis staan; daarom is het belangrijk er een gewoonte van te maken de inhoud vóór het committen te controleren met git status en git diff.

Nu oefenen: vragen over Git

Na het bewerken van main.c, een bestand dat met Git wordt beheerd, werd alleen „git commit -m "fix"” uitgevoerd; „no changes added to commit” werd getoond en er werd niets gecommit. Wat is de reden?

  1. AVóór het committen moeten de wijzigingen met git push naar de gedeelde repository worden gestuurd
  2. BWijzigingen die in een commit moeten komen, moeten eerst met git add in de staging area worden geregistreerd
  3. CGit commit automatisch wanneer een bestand wordt opgeslagen, dus git commit hoeft niet te worden uitgevoerd
Antwoord en toelichting tonen

Antwoord: B. Wijzigingen die in een commit moeten komen, moeten eerst met git add in de staging area worden geregistreerd

In Git worden van de wijzigingen die in de werkdirectory zijn aangebracht alleen die welke met git add in de staging area (de index) zijn geregistreerd, vastgelegd door de volgende git commit. Dankzij dit mechanisme in twee stappen kun je uit verschillende bewerkingen alleen de samenhangende wijzigingen kiezen en er één commit van maken. git status toont welke wijzigingen gestaged zijn. Er bestaat ook git commit -a, dat alle wijzigingen in gevolgde bestanden in één keer registreert en commit.

Je hebt in Git git commit uitgevoerd, maar de commit verschijnt nog niet in de GitHub-repository die het team deelt. Wat is de reden?

  1. Agit commit registreert wijzigingen alleen in de staging area, en om ze vast te leggen is git add nodig
  2. BOm gecommitte wijzigingen naar de gedeelde repository te sturen, moet git pull worden uitgevoerd
  3. Cgit commit legt vast in de lokale repository, en om naar de remote te sturen is git push nodig
Antwoord en toelichting tonen

Antwoord: C. git commit legt vast in de lokale repository, en om naar de remote te sturen is git push nodig

Git is een gedistribueerd versiebeheersysteem waarin elke ontwikkelaar de hele repository lokaal heeft, en git commit legt wijzigingen vast in die lokale repository. Om ze naar een remote repository zoals GitHub te sturen, wordt git push uitgevoerd; omgekeerd haalt git pull (of git fetch en git merge) nieuwe commits van de remote binnen in de lokale repository. Daarom kun je ook zonder netwerkverbinding committen en later alles in één keer pushen. Als iemand anders eerder heeft gepusht, kan je worden gevraagd eerst diens wijzigingen binnen te halen.

Veelgestelde vragen

Wat is het verschil tussen Git en GitHub?

Git is de versiebeheersoftware zelf, die op je eigen computer draait. GitHub is een webdienst die Git-repository's host en functies toevoegt zoals reviews via pull requests en het beheer van issues. Er zijn vergelijkbare diensten zoals GitLab, en servers die binnen het bedrijf staan, en Git zelf kan met elk daarvan worden gebruikt.

Hoe maak ik de laatste commit ongedaan?

Als de commit nog niet is gepusht, kan git commit --amend de laatste commit aanpassen en git reset hem ongedaan maken. Voor een commit die al is gepusht en gedeeld, is het veiliger git revert te gebruiken, dat de ongedaanmaking als een nieuwe commit toevoegt, zodat die niet botst met de geschiedenis van anderen.

“Git” in de toelichting

Vragen met “Git” (5)

  1. Na het bewerken van main.c, een bestand dat met Git wordt beheerd, werd alleen „git commit -m "fix"” uitgevoerd; „no changes added to commit” werd getoond en er werd niets gecommit. Wat is de reden?
  2. Je hebt in Git git commit uitgevoerd, maar de commit verschijnt nog niet in de GitHub-repository die het team deelt. Wat is de reden?
  3. In het .gitignore-bestand van een project dat met Git wordt beheerd, is „build/” geschreven, maar wijzigingen in build/out.log, dat eerder is gecommit, blijven in git status verschijnen. Wat is de reden?
  4. In Git hebben twee ontwikkelaars dezelfde regel van hetzelfde bestand in verschillende branches gewijzigd, waarna de ene branch in de andere is gemerged. Wat gebeurt er?
  5. Na een firmwareversie waarvan bekend is dat ze correct werkt, volgen 1000 commits, en de laatste commit bevat een bug. De bug is door één commit geïntroduceerd en treedt op in elke commit daarna. Hoe vaak moet de firmware maximaal worden gebouwd en getest als de schuldige commit met binair zoeken wordt opgespoord, zoals met git bisect?

Verwante termen

Binair zoeken (binary search) Bestandsrechten (permissies) cron grep Harde link (hard link) inode Omgevingsvariabele (environment variable) Omleiding van invoer en uitvoer (I/O redirection) Pipe (|) Reguliere expressie (regex)

Naar de woordenlijst