Git
Analyse van soorten workflows

Opmerkingen

Gitflow-workflow

Oorspronkelijk voorgesteld door Vincent Driessen , is Gitflow een ontwikkelworkflow met git en verschillende vooraf gedefinieerde branches. Dit kan worden gezien als een speciaal geval van de Feature Branch Workflow .

Het idee hiervan is om afzonderlijke filialen gereserveerd te hebben voor specifieke delen in ontwikkeling:

• master branch is altijd de meest recente productiecode . Experimentele code hoort hier niet thuis.
• develop branch bevat de nieuwste ontwikkeling . Deze ontwikkelingswijzigingen kunnen vrijwel alles zijn, maar grotere functies zijn gereserveerd voor hun eigen filialen. Code hier wordt altijd aan gewerkt en samengevoegd tot release vóór release / implementatie.
• hotfix branches zijn voor kleine bugfixes, die niet kunnen wachten tot de volgende release. hotfix filialen komen van master en worden samengevoegd in master en develop .
• release takken worden gebruikt om nieuwe ontwikkeling te bevrijden van develop tot master . Eventuele wijzigingen op het laatste moment, zoals versienummer van de bump, worden doorgevoerd in de releasetak en vervolgens weer samengevoegd tot master en develop . Wanneer een nieuwe versie wordt master moet de master worden getagd met het huidige versienummer (bijvoorbeeld het gebruik van semantische versiebeheer ) voor toekomstige referentie en eenvoudig terugdraaien.
• feature zijn gereserveerd voor grotere kenmerken. Deze zijn specifiek ontwikkeld in aangewezen takken en geïntegreerd met develop wanneer ze klaar zijn. Speciale feature helpen de ontwikkeling te scheiden en om gedane functies onafhankelijk van elkaar te kunnen implementeren.

Een visuele weergave van dit model:

De originele weergave van dit model:

Forking Workflow

Dit type workflow is fundamenteel anders dan de andere die in dit onderwerp worden genoemd. In plaats van één gecentraliseerde repo waartoe alle ontwikkelaars toegang hebben, heeft elke ontwikkelaar zijn / haar eigen repo die is gesplitst van de hoofdrepo. Het voordeel hiervan is dat ontwikkelaars naar hun eigen repo's kunnen posten in plaats van naar een gedeelde repo en een beheerder kan de wijzigingen van de gevorkte repo's indien nodig in het origineel integreren.

Een visuele weergave van deze workflow is als volgt:

Gecentraliseerde workflow

Met dit fundamentele workflowmodel bevat een master branch alle actieve ontwikkeling. Medewerkers moeten er vooral zeker van zijn dat ze de laatste wijzigingen doorvoeren voordat ze de ontwikkeling voortzetten, want deze branche zal snel veranderen. Iedereen heeft toegang tot deze repo en kan wijzigingen doorvoeren in de master branch.

Visuele weergave van dit model:

Dit is het klassieke paradigma voor versiebeheer, waarop oudere systemen zoals Subversion en CVS zijn gebouwd. Softwares die op deze manier werken worden gecentraliseerde versiebeheersystemen of CVCS's genoemd. Hoewel Git op deze manier kan werken, zijn er opmerkelijke nadelen, zoals vereist zijn om elke pull vooraf te laten gaan door een samenvoeging. Het is heel goed mogelijk voor een team om op deze manier te werken, maar de constante oplossing van conflictconflicten kan veel waardevolle tijd opslokken.

Dit is de reden waarom Linus Torvalds Git niet als een CVCS heeft gemaakt, maar eerder als een DVCS of gedistribueerd versiecontrolesysteem , vergelijkbaar met Mercurial. Het voordeel van deze nieuwe manier van doen is de flexibiliteit die in de andere voorbeelden op deze pagina wordt aangetoond.

Feature Branch Workflow

Het kernidee achter de Feature Branch Workflow is dat alle functieontwikkeling plaats moet vinden in een speciale branch in plaats van de master branch. Deze inkapseling maakt het gemakkelijk voor meerdere ontwikkelaars om aan een bepaalde functie te werken zonder de hoofdcodebasis te verstoren. Het betekent ook dat de master branch nooit gebroken code zal bevatten, wat een enorm voordeel is voor omgevingen met continue integratie.

Het inkapselen van functie-ontwikkeling maakt het ook mogelijk om pull-aanvragen te gebruiken, wat een manier is om discussies rond een filiaal te initiëren. Ze geven andere ontwikkelaars de mogelijkheid om zich af te melden voor een functie voordat deze wordt geïntegreerd in het officiële project. Of, als u vastloopt in het midden van een functie, kunt u een pull-aanvraag openen waarin u om suggesties van uw collega's vraagt. Het punt is dat pull-aanvragen het voor uw team ongelooflijk eenvoudig maken om op elkaars werk te reageren.

gebaseerd op Atlassian Tutorials .

GitHub Flow

Populair binnen veel open source-projecten, maar niet alleen.

Master tak van een specifieke locatie (Github, Gitlab, BitBucket, lokale server) bevat de meest recente verzendbare versie. Voor elke nieuwe functie / bugfix / architecturale wijziging maakt elke ontwikkelaar een filiaal.

Wijzigingen vinden plaats in die branch en kunnen worden besproken in een pull-aanvraag, code review, etc. Na acceptatie worden ze samengevoegd met de master branch.

Full flow van Scott Chacon:

• Alles in de master branch is inzetbaar
• Als u aan iets nieuws wilt werken, maakt u een tak met een beschrijvende naam off van master (bijvoorbeeld: new-oauth2-scopes)
• Commiteer lokaal naar die branch en push je werk regelmatig naar dezelfde branch op de server
• Als je feedback of hulp nodig hebt, of als je denkt dat de branch klaar is om samen te voegen, open dan een pull-aanvraag
• Nadat iemand anders de functie heeft beoordeeld en afgemeld, kunt u deze samenvoegen tot master
• Zodra het is samengevoegd en naar 'master' is geduwd, kunt en moet u het onmiddellijk implementeren

Oorspronkelijk gepresenteerd op de persoonlijke website van Scott Chacon .

Afbeelding afkomstig van de GitHub Flow-referentie