Workflow voor vertakking
De vertakkingsworkflow is fundamenteel anders dan andere populaire Git-workflows. Forking (vertakken) geeft elke ontwikkelaar een repository aan de serverkant in plaats van een eigen repository aan de serverkant als de 'centrale' codebase. Elke medewerker heeft dus niet één, maar twee Git-repository's: een lokale (privé) en een aan een openbare serverkant. De vertakkingsworkflow wordt het meest gebruikt in openbare open-sourceprojecten.
Het belangrijkste voordeel van de vertakkingsworkflow is dat bijdragen kunnen worden geïntegreerd zonder dat iedereen naar één centrale repository hoeft te pushen. Ontwikkelaars pushen naar hun eigen repository's op de server, en alleen de projectbeheerder kan naar de officiële repository pushen. Hierdoor kan de onderhouder commits van elke ontwikkelaar accepteren zonder hem schrijftoegang tot de officiële codebase te geven.
De branching-workflow volgt doorgaans een branching-model dat is gebaseerd op de Gitflow-workflow. Dit betekent dat complete functie-branches worden bestemd voor samenvoeging in de oorspronkelijke repository van de projectbeheerder. Het resultaat is een gedistribueerde workflow die grote, organische teams (waaronder niet-vertrouwde externe partijen) een flexibele manier biedt om veilig samen te werken. Hierdoor is dit ook een ideale workflow voor open-sourceprojecten.
Hoe het werkt
Net als in de andere Git-workflows begint de vertakkingsworkflow met een officiële openbare repository die is opgeslagen op een server. Als een nieuwe ontwikkelaar aan het project wil beginnen, kloont deze echter niet rechtstreeks de officiële repository.
In plaats daarvan maakt hij een vertakking van de officiële repository om er een kopie van te maken op de server. Dit nieuwe exemplaar dient als hun persoonlijke openbare repository. Andere ontwikkelaars mogen er niet naartoe pushen, maar kunnen er wel veranderingen uit ophalen (we zullen zo meteen zien waarom dit belangrijk is). Nadat hij een kopie aan de serverzijde heeft aangemaakt, voert de ontwikkelaar een git clone uit om een kopie ervan op de lokale computer te krijgen. Deze dient als hun persoonlijke ontwikkelomgeving, net als in de andere workflows.
Als men klaar is om een lokale commit te publiceren, wordt de commit naar de eigen openbare repository gepusht – dus niet naar de officiële. Vervolgens wordt een pull-aanvraag ingediend bij de hoofdrepository, zodat de projectbeheerder weet dat er een update klaar staat om te worden geïntegreerd. De pull-aanvraag is ook een handig gespreksonderwerp als er problemen zijn met de ingebrachte code. Hieronder volgt een stapsgewijs voorbeeld van deze workflow.
gerelateerd materiaal
Uitgebreid Git log
Oplossing bekijken
Git leren met Bitbucket Cloud
1. Een ontwikkelaar 'vertakt' een 'officiële' repository aan de serverzijde. Hierdoor ontstaat een eigen kopie aan de serverzijde.
2. De nieuwe kopie aan de serverzijde wordt naar het lokale systeem gekloond.
3. Er wordt een extern Git-pad voor de 'officiële' repository aan de lokale kloon toegevoegd.
4. Er wordt een nieuwe lokale functie-branch aangemaakt.
5. De ontwikkelaar brengt veranderingen aan in de nieuwe branch.
6. Er worden nieuwe commits aangemaakt voor de veranderingen.
7. De branch wordt naar het eigen exemplaar aan de serverzijde van de ontwikkelaar gestuurd.
8. De ontwikkelaar opent een pull request op basis van de nieuwe branch naar de 'officiële' repository.
9. De pull request wordt goedgekeurd voor samenvoeging en wordt samengevoegd in de oorspronkelijke repository aan de serverzijde
Om de functie in de officiële codebase te integreren, haalt de onderhouder de wijzigingen van de bijdrager op naar zijn lokale repository, controleert of ze het project niet nadelig beïnvloeden, voegt ze samen met zijn lokale main-branch en pusht de main-branch vervolgens naar de officiële repository op de server. De bijdrage maakt nu deel uit van het project. Andere ontwikkelaars moeten een pull uitvoeren op de officiële repository om hun lokale repository's te synchroniseren.
Het is belangrijk om te begrijpen dat het begrip 'officiële' repository in de vertakkingsworkflow slechts een conventie is. In feite wordt de officiële repository alleen officieel doordat deze de openbare repository is van de projectbeheerder.
Vertakken versus klonen
Het is belangrijk op te merken dat 'vertakte' repository's en 'vertakkingen' geen speciale bewerkingen zijn. Vertakte repository's worden aangemaakt met de standaard git clone-opdracht. Vertakte repository's zijn over het algemeen 'klonen aan serverzijde' en worden meestal beheerd en gehost door een externe Git-service zoals Bitbucket. Er is geen unieke Git-opdracht om vertakte repository's te maken. Een kloonbewerking is in wezen een kopie van een repository en de geschiedenis ervan.
Branches in de vertakkingsworkflow
Al deze persoonlijke openbare repository's zijn eigenlijk gewoon een handige manier om branches te delen met andere ontwikkelaars. Iedereen zou nog steeds branches moeten gebruiken om individuele functies te isoleren, net zoals in de workflow voor functie-branches en de Gitflow-workflow. Het enige verschil is hoe die branches worden verdeeld. In de vertakkingsworkflow worden ze naar de lokale repository van een andere ontwikkelaar opgehaald, terwijl ze in de functie-branch- en Gitflow-workflows naar de officiële repository worden gepusht.
Een repository vertakken
Alle nieuwe ontwikkelaars in een project met vertakkingsworkflow moeten de officiële repository vertakken. Zoals eerder vermeld, is vertakken gewoon een standaard git clone-bewerking. Dit kan door via SSH naar de server te gaan en git clone uit te voeren om de branch naar een andere locatie op de server te kopiëren. Populaire Git-hostingservices, zoals Bitbucket, bieden functies voor vertakking van repo's waarmee deze stap wordt geautomatiseerd.
Je vertakking klonen
Alle nieuwe ontwikkelaars in een project met vertakkingsworkflow moeten de officiële repository vertakken. Zoals eerder vermeld, is vertakken gewoon een standaard git clone-bewerking. Dit kan door via SSH naar de server te gaan en git clone uit te voeren om de branch naar een andere locatie op de server te kopiëren. Populaire Git-hostingservices, zoals Bitbucket, bieden functies voor vertakking van repo's waarmee deze stap wordt geautomatiseerd.
Ervan uitgaande dat Bitbucket wordt gebruikt om deze repository's te hosten: ontwikkelaars moeten binnen een project hun eigen Bitbucket-account hebben en hun vertakte kopie van de repository klonen met:
git clone https://user@bitbucket.org/user/repo.gitEen externe locatie toevoegen
Waar andere Git-workflows gebruikmaken van één enkele oorsprongslocatie die naar de centrale repository verwijst, heeft de vertakkingsworkflow twee externe locaties nodig: één voor de officiële repository en één voor de persoonlijke repository van de ontwikkelaar op de server. Je kunt deze externe locaties noemen zoals je wilt, maar het is gebruikelijk om 'origin' te gebruiken voor de externe locatie voor je vertakte repository (deze wordt automatisch aangemaakt als je git clone gebruikt) en 'upstream' voor de officiële repository.
git remote add upstream https://bitbucket.org/maintainer/repoJe moet de upstream externe locatie zelf aanmaken met de bovenstaande opdracht. Zo kun je gemakkelijk je lokale repository up-to-date houden naarmate het officiële project vordert. Let op: als authenticatie in je upstream repository is ingeschakeld (dat wil zeggen: deze is niet open source), moet je een gebruikersnaam opgeven zoals:
git remote add upstream https://user@bitbucket.org/maintainer/repo.gitHiervoor moeten gebruikers een geldig wachtwoord opgeven voordat ze kunnen klonen of een pull-bewerking op de officiële codebase kunnen uitvoeren.
Werken in een branch: wijzigingen aanbrengen en pushen
Ontwikkelaars kunnen in de lokale versie van de vertakte repository code bewerken, wijzigingen committen en branches aanmaken, net als in andere Git-workflows:
git checkout -b some-feature # Edit some code git commit -a -m "Add first draft of some feature"Al hun wijzigingen zijn volledig privé totdat ze deze naar hun openbare repository pushen. En als het officiële project vooruitgang heeft geboekt, hebben ze toegang tot nieuwe commits met git pull:
git pull upstream mainOmdat ontwikkelaars in een speciale functie-branch zouden moeten werken, zou dit over het algemeen moeten resulteren in een snelle merge.
Een pull-aanvraag doen
Zodra ontwikkelaars klaar zijn om de nieuwe functie te delen, moeten zij twee dingen doen. Ten eerste moeten ze hun bijdrage toegankelijk maken voor andere ontwikkelaars door deze naar hun openbare repository te pushen. Hun externe 'origin'-branch zou al ingesteld moeten zijn, dus hoeven ze alleen nog het volgende te doen:
git push origin feature-branchDit wijkt af van de andere workflows omdat de externe 'origin' naar de persoonlijke repository van de ontwikkelaar op de server verwijst, en niet naar de main-codebase.
Ten tweede moeten ze de projectbeheerder informeren dat ze hun functie willen samenvoegen in de officiële codebase. Bitbucket bevat een knop 'pull-aanvraag'. Deze leidt naar een formulier waarin je wordt gevraagd aan te geven welke branch je wilt samenvoegen in de officiële repository. Meestal wil je je functie-branch integreren in de externe upstream main-branch.
Samenvatting
Samenvattend: de vertakkingsworkflow wordt vaak gebruikt in openbare open-sourceprojecten. Vertakken is een git clone-bewerking die wordt uitgevoerd op een serverkopie van een projectrepo. Een vertakkingsworkflow wordt vaak gebruikt in combinatie met een Git-hostingservice zoals Bitbucket. Een globaal voorbeeld van een vertakkingsworkflow is:
1. Je wilt bijdragen aan een open-sourcebibliotheek die wordt gehost op Bitbucket.org/userA/open-project
2. Je maakt met behulp van Bitbucket een vertakking van de repo naar BitBucket.org/YourName/open-project
3. Je voert op je lokale systeem git clone uit op https://bitbucket.org/YourName/open-project om een lokale kopie van de repo te krijgen
4. Je maakt een nieuwe functie-branch aan in je lokale repo
5. De nieuwe functie wordt voltooid, waarna git commit wordt uitgevoerd om de veranderingen op te slaan
6. Vervolgens verplaats je de nieuwe functie-branch naar je externe vertakte repo
7. Je opent met Bitbucket een pull request voor de nieuwe branch naar de oorspronkelijke repo op bitbucket.org/userA/open-project
De vertakkingsworkflow helpt een onderhouder van een project om de repository open te stellen voor bijdragen van welke ontwikkelaar dan ook zonder dat hij de autorisatie-instellingen voor elke individuele bijdrager handmatig hoeft te beheren. Hierdoor beschikt de onderhouder meer over een 'pull'-workflow. De vertakkingsworkflow wordt meestal gebruikt in open-sourceprojecten en kan ook worden toegepast op workflows van particuliere bedrijven, zodat zij meer gezaghebbende controle hebben over wat er in een release wordt samengevoegd. Dit kan handig zijn in teams met implementatiebeheerders of met strikte releasecycli.
Weet je niet zeker welke workflow geschikt is voor jou? Bekijk onze uitgebreide vergelijkingspagina voor Git-workflows.
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.
Bitbucket-blog
DevOps-leertraject
