Close

Een repository opzetten

Deze tutorial biedt een overzicht van de manier waarop je een repository (repo) instelt onder Git versiebeheer. Deze hulpbron helpt je bij het initialiseren van een Git-repository voor een nieuw of bestaand project. Hieronder vind je workflowvoorbeelden van repository's die zowel lokaal zijn aangemaakt als zijn gekloond uit externe repository's. In deze handleiding wordt ervan uitgegaan dat je basiskennis hebt van een opdrachtregelinterface.

De belangrijkste punten in deze gids zijn:

  • Een nieuwe Git-repo initialiseren
  • Een bestaande Git-repo klonen
  • Een gewijzigde versie van een bestand opslaan in de repo
  • Een Git-repo configureren voor samenwerking op afstand
  • Algemene opdrachten voor Git-versiebeheer

Aan het einde van deze module zou je in staat moeten zijn om een Git-repo aan te maken, veelgebruikte Git-opdrachten te gebruiken, een aangepast bestand toe te voegen, de geschiedenis van je project te bekijken en een verbinding met een Git-hostingservice (Bitbucket) te configureren.


Wat is een Git-repository?


Een Git-repository is een virtuele opslag van je project. Hiermee kun je versies van je code opslaan, die je kunt openen als dat nodig is.

Een nieuwe repository initialiseren: git init


Om een nieuwe repo te maken, gebruik je de opdracht git init. git init is een eenmalige opdracht die je gebruikt tijdens de eerste installatie van een nieuwe repo. Als je deze opdracht uitvoert, wordt er een nieuwe submap .git. in je huidige werkmap aangemaakt. Hiermee wordt ook een nieuwe main-branch gemaakt.

Versiebeheer van een bestaand project met een nieuwe git-repository

In dit voorbeeld wordt ervan uitgegaan dat je al een bestaande projectmap hebt waarin je een repo wilt aanmaken. Je gaat eerst met cd naar de hoofdmap van het project en voert dan de opdracht git init uit.

Git-branch
gerelateerd materiaal

Git-branch

Logo Bitbucket
Oplossing bekijken

Git leren met Bitbucket Cloud

cd /path/to/your/existing/code 
git init

Door git init naar een bestaande projectmap te verwijzen, wordt dezelfde initialisatiesetup uitgevoerd als hierboven vermeld, maar dan binnen de scope van die projectmap.

git init <project directory>

Ga naar de pagina git init voor een meer gedetailleerde informatie over git init.

Een bestaande repository klonen: git clone


Als een project al in een centrale repository is opgezet, is de opdracht clone de meest gebruikelijke manier om een lokale ontwikkelingskloon te verkrijgen. Net als git init is klonen over het algemeen een eenmalige bewerking. Zodra een ontwikkelaar een werkkopie heeft verkregen, worden alle bewerkingen voor versiebeheer beheerd via de lokale repository.

git clone <repo url>

git clone wordt gebruikt om een kopie of kloon van externe repository's te maken. Je geeft git clone een URL van de repository. Git ondersteunt een aantal verschillende netwerkprotocollen en bijbehorende URL-indelingen. In dit voorbeeld gebruiken we het Git SSH-protocol. Git SSH-URL's volgen een sjabloon van: git@HOSTNAME:USERNAME/REPONAME.git

Een voorbeeld van Git SSH-URL is: git@bitbucket.org:rhyolight/javascript-data-store.git waarbij de waarden van de sjabloon overeenkomen met:

  • HOSTNAME: bitbucket.org
  • USERNAME: rhyolight
  • REPONAME: javascript-data-store

Wanneer ze worden uitgevoerd, wordt de laatste versie van de externe repo-bestanden in de main-branch opgehaald en aan een nieuwe map toegevoegd. De nieuwe map krijgt de naam van REPONAME, in dit geval de javascript-data-store. De map zal de volledige geschiedenis van de externe repository en een nieuw aangemaakte main-branch bevatten.

Ga voor meer documentatie over het gebruik van git clone en de ondersteunde Git-URL-indelingen naar de pagina git clone.

Wijzigingen opslaan in de repository: git add en git commit


Nu je een repository hebt gekloond of geïnitialiseerd, kun je wijzigingen in de bestandsversie doorvoeren. In het volgende voorbeeld wordt ervan uitgegaan dat je een project hebt opgezet op /path/to/project. In dit voorbeeld worden de volgende stappen genomen:

  • Mappen wijzigen naar /path/to/project
  • Een nieuw bestand CommitTest.txt aanmaken met de inhoud ~"test content for git tutorial"~
  • Met git CommitTest.txt toevoegen aan het staginggebied van de repository
  • Een nieuwe commit aanmaken met een bericht waarin wordt beschreven welk werk er in de commit is gedaan
cd /path/to/project 
echo "test content for git tutorial" >> CommitTest.txt 
git add CommitTest.txt 
git commit -m "added CommitTest.txt to the repo"

Nadat je dit voorbeeld hebt uitgevoerd, wordt CommitTest.txt nu toegevoegd aan de geschiedenis van je repo en worden toekomstige updates van het bestand bijgehouden.

In dit voorbeeld zijn twee extra git-opdrachten geïntroduceerd: add en commit. Dit was een zeer beperkt voorbeeld, maar beide opdrachten worden uitgebreider behandeld op de pagina's git add en git commit. Een ander veelgebruikt scenario voor git add is de optie --all. Als git add --all wordt uitgevoerd, worden alle gewijzigde en niet-traceerde bestanden in de repo meegenomen, worden ze toegevoegd aan de repo en wordt de werkstructuur van de repo bijgewerkt.

Repo-to-repo-samenwerking: git push


Het is belangrijk om te begrijpen dat Gits opvatting van een 'werkkopie' heel anders is dan de werkkopie die je krijgt door broncode uit een SVN-repository uit te checken. Git maakt, in tegenstelling tot SVN, geen onderscheid tussen de werkkopieën en de centrale repository — het zijn allemaal volwaardige Git-repository's.

Dit maakt de samenwerking met Git fundamenteel anders dan met SVN. SVN is afhankelijk van de relatie tussen de centrale repository en de werkkopie, maar het samenwerkingsmodel van Git is gebaseerd op interactie tussen repository's. In plaats van een werkkopie te controleren in de centrale repository van SVN, push of pull je commits van de ene repository naar de andere.

Natuurlijk weerhoudt niets je ervan om bepaalde Git-repo's een speciale betekenis te geven. Door bijvoorbeeld simpelweg één Git-repo aan te wijzen als de 'centrale' repository kun je een gecentraliseerde workflow repliceren met behulp van Git. Dit wordt bereikt door middel van conventies in plaats van echte programmering in de VCS zelf.

Kale versus gekloonde repository's

Als je git clone hebt gebruikt in het vorige gedeelte 'Een nieuwe repository initialiseren' om je lokale repository te configureren, dan is je repository al geconfigureerd voor samenwerking op afstand. git clone zal automatisch je repo configureren met een verwijzing op afstand naar de Git-URL van waaruit je deze hebt gekloond. Dit betekent dat als je eenmaal wijzigingen hebt aangebracht in een bestand en ze commit, je deze wijzigingen met git push naar de repository op afstand kunt pushen.

Als je git init hebt gebruikt om een nieuwe repo te maken, heb je geen externe repo om wijzigingen naar te pushen. Een veelvoorkomend patroon bij het initialiseren van een nieuwe repo is om naar een gehoste Git-service zoals Bitbucket te gaan en daar een repo aan te maken. De service biedt een Git-URL die je vervolgens kunt toevoegen aan je lokale Git-repository en met git push naar de gehoste repo kunt pushen. Als je eenmaal een repo op afstand hebt aangemaakt met de service van je keuze, moet je je lokale repo updaten met een toewijzing. We bespreken dit proces in de onderstaande handleiding Configuratie en setup.

Als je liever je eigen repo op afstand host, moet je een 'Bare Repository' opzetten. Zowel git init als git clone accepteren een --bare argumen t. Het meest gebruikelijke scenario voor bare repo is het aanmaken van een centrale Git-repository op afstand.

Configuration en setup: git config


Zodra je een externe repo hebt opgezet, moet je een URL voor de repo op afstand toevoegen aan je lokale git con en een upstream-branch instellen voor je lokale branches. Dat kan met de opdracht git remote.

git remote add <remote_name> <remote_repo_url>

Deze opdracht wijst de repository op afstand op <remote_repo_url> toe aan een referentie in je lokale repo onder <remote_name>. Als je eenmaal de repo op afstand in kaart hebt gebracht, kun je er lokale branches naartoe pushen.

git push -u <remote_name> <local_branch_name>

Met deze opdracht push je de lokale repo-branch onder naar de repo op afstand .

Voor een uitgebreidere kijk op git remote, zie de pagina Git remote.

Naast het configureren van een URL voor de repo of afstand moet je mogelijk ook globale Git-configuratieopties instellen, zoals een gebruikersnaam of e-mailadres. Met de opdracht git config kun je je Git-installatie (of een individuele repository) configureren vanaf de opdrachtregel. Met deze opdracht kun je van alles definiëren, van gebruikersinformatie en voorkeuren tot het gedrag van een repository. Hieronder staan verschillende veelgebruikte configuratieopties vermeld.

Git slaat configuratieopties op in drie afzonderlijke bestanden, zodat je scope opties kunt gebruiken voor afzonderlijke repository's (lokaal), voor gebruikers (wereldwijd) of voor het hele systeem (systeem):

  • Lokaal: /.git/config — Specifieke instellingen voor de repository.
  • Globaal: /.gitconfig — gebruikersspecifieke instellingen. Hier worden de opties opgeslagen die zijn ingesteld met de vlag --global.
  • Systeem: $(prefix)/etc/gitconfig — Instellingen voor het hele systeem.

Definieer de auteursnaam die moet worden gebruikt voor alle commits in de huidige repository. Meestal moet je de vlag --global gebruiken om configuratieopties in te stellen voor de huidige gebruiker.

git config --global user.name <name>

Definieer de auteursnaam die door de huidige gebruiker moet worden gebruikt voor alle commits.

Door de optie --local toe te voegen of helemaal geen optie op configuratieniveau door te geven, wordt de user.name ingesteld voor de huidige lokale repository.

git config --local user.email <email>

Definieer het e-mailadres van de auteur dat door de huidige gebruiker moet worden gebruikt voor alle commits.

git config --global alias.<alias-name> <git-command>

Maak een sneltoets voor een Git-opdracht. Dit is een krachtig hulpprogramma om aangepaste sneltoetsen te maken voor veelgebruikte git-opdrachten. Een simplistisch voorbeeld zou het volgende zijn:

git config --global alias.ci commit

Hiermee wordt een ci-opdracht aangemaakt die je kunt uitvoeren als sneltoets naar git commit. Ga voor meer informatie over git-aliassen naar de pagina git-configuratie.

it config --system core.editor <editor>

Definieer de teksteditor die wordt gebruikt voor opdrachten zoals git commit voor alle gebruikers op de huidige machine. Het> argument moet de opdracht zijn waarmee de gewenste editor wordt gestart (bijv. vi). In dit voorbeeld wordt de optie --system geïntroduceerd. De optie --system stelt de configuratie in voor het hele systeem, dat wil zeggen voor alle gebruikers en repo's op een machine. Ga voor meer gedetailleerde informatie over configuratieniveaus naar de pagina git config.

git config --global --edit

Open het globale configuratiebestand in een teksteditor voor handmatige bewerking. Een uitgebreide handleiding over het configureren van een teksteditor voor het gebruik van git vind je op de pagina git config.

Bespreking

Alle configuratieopties worden opgeslagen in bestanden met gewone tekst, dus de opdracht git config is eigenlijk gewoon een handige opdrachtregelinterface. Meestal hoef je alleen een Git-installatie te configureren wanneer je voor het eerst op een nieuwe ontwikkelingsmachine gaat werken, en in vrijwel alle gevallen zul je de vlag --global willen gebruiken. Een belangrijke uitzondering is om het e-mailadres van de auteur te negeren. Misschien wil je je persoonlijke e-mailadres instellen voor persoonlijke en open source repository's, en je professionele e-mailadres voor werkgerelateerde repository's.

Git slaat configuratieopties op in drie afzonderlijke bestanden, zodat scope de opties kunt bekijken voor afzonderlijke repository's, gebruikers of het hele systeem:

  • /.git/config — Repository-specifieke instellingen.
  • ~/.gitconfig — Gebruikersspecifieke instellingen. Hier worden de opties opgeslagen die zijn ingesteld met de vlag --global.
  • $(prefix)/etc/gitconfig — Instellingen voor het hele systeem.

Wanneer opties in deze bestanden conflicteren, hebben lokale instellingen voorrang op de gebruikersinstellingen, die voorrang hebben op het hele systeem. Als je een van deze bestanden opent, zie je zoiets als het volgende:

[user] name = John Smith email = john@example.com [alias] st = status co = checkout br = branch up = rebase ci = commit [core] editor = vim

Je kunt deze waarden handmatig bewerken met exact hetzelfde effect als git config.

Voorbeeld

Het eerste wat je moet doen nadat je Git hebt geïnstalleerd, is het je naam/e-mailadres geven en enkele standaardinstellingen aanpassen. Een normale eerste configuratie zou er ongeveer als volgt uit kunnen zien:

Vertel Git wie je bent, git config

git --global user.name "John Smith" git config --global user.email john@example.com

Selecteer je favoriete teksteditor

git config --global core.editor vim

Voeg enkele SVN-achtige aliassen toe

git config --global alias.st status 
git config --global alias.co checkout 
git config --global alias.br branch 
git config --global alias.up rebase 
git config --global alias.ci commit

Dit levert het ~ /.gitconfig bestand van het vorige gedeelte op. Kijk eens wat dieper naar git config op de pagina git config.

Samenvatting


Hier hebben we op twee manieren laten zien hoe je een git-repository aanmaakt: git init en git clone. Deze handleiding kan worden toegepast om de broncode van de software of ander materiaal te beheren waarvoor een versie moet worden gemaakt. Git add, git commit, git push en git remote zijn ook op hoog niveau geïntroduceerd en gebruikt.

Lees onze handleiding om te weten welk repositorysysteem voor codes geschikt is voor jouw team!


Deel dit artikel
Volgend onderwerp

Aanbevolen artikelen

Bookmark deze resources voor meer informatie over soorten DevOps-teams of voor voortdurende updates over DevOps bij Atlassian.

Mensen die samenwerken met een muur vol tools

Bitbucket-blog

Toelichting DevOps

DevOps-leertraject

Demo Den Feature-demo's met Atlassian-experts

Hoe Bitbucket Cloud werkt met Atlassian Open DevOps

Meld je aan voor onze DevOps-nieuwsbrief

Thank you for signing up