Featurebranch-werkstroom verkennen
Het kernidee achter de Feature Branch Workflow is dat alle functieontwikkeling moet plaatsvinden in een aparte branch in plaats van de main branch.
Dankzij de inkapseling kunnen meerdere ontwikkelaars eenvoudig aan een bepaalde functie werken zonder de hoofdcodebasis te storen. Dit betekent ook dat de hoofdbranch nooit verbroken code bevat, een enorm voordeel voor continue integratieomgevingen.
Door feature-ontwikkeling in te kapselen, wordt het ook mogelijk om pull requests te gebruiken, wat een manier is om discussies rond een branch te starten. Ze stellen andere ontwikkelaars in staat zich af te melden bij een functie voordat deze in het officiële project wordt geïntegreerd. Of als u vastloopt in het midden van een functie, kunt u een pull-aanvraag openen waarin wordt gevraagd om suggesties van uw collega's.
Pull-aanvragen maken het voor uw team ongelooflijk eenvoudig om elkaars werk te becommentariëren. Daarnaast kunnen en moeten feature branches naar de centrale opslagplaats worden gepusht. Hiermee kunt u een functie delen met andere ontwikkelaars zonder dat er officiële code wordt aangeraakt.
Omdat de hoofdbranch de enige 'speciale' vertakking is, vormt het opslaan van verschillende functiebranches in de centrale opslagplaats geen problemen. Het is ook een handige manier om een back-up te maken van ieders lokale commits.
Werkstroom voor vertakking vrijgeven
Naast de Functievertakkingswerkstroom is een andere veelgebruikte strategie in Git-vertakkingswerkstromen de Release Branch-strategie. Deze strategie omvat het maken van speciale vertakkingen specifiek voor het voorbereiden van releases. De releasebranch wordt doorgaans gemaakt op basis van een stabiele functiebranch, zodat deze alleen grondig geteste en gevalideerde code bevat. Zodra de releasebranch is gemaakt, ondergaat de releasebranch aanvullende tests, bugfixes en stabilisatie-inspanningen om de codebasis voor te bereiden voor implementatie. De releasebranch maakt isolatie mogelijk van releasegerelateerde activiteiten van doorlopende functieontwikkeling, waardoor een gecontroleerde omgeving wordt geboden voor het voltooien en opspokken van de aanstaande release. Nadat alle benodigde aanpassingen en verificaties zijn aangebracht in de releasebranch, wordt deze vervolgens samengevoegd in de hoofdbranch of rechtstreeks in productie geïmplementeerd, afhankelijk van het releaseproces van het team. De Release Branch-strategie helpt teams bij het beheren van de complexiteit van het coördineren van releaseactiviteiten en het onderhouden van een stabiele hoofdvertakking voor continue ontwikkeling.
Ontwikkelwerkstroom op basis van Trunk
De ontwikkelwerkstroom op basis van trunk gaat uit van een centrale opslagplaats en de hoofdmap vertegenwoordigt de officiële projectgeschiedenis. In plaats van rechtstreeks door te gaan naar hun lokale hoofdbranch, maken ontwikkelaars een nieuwe vertakking wanneer ze aan een nieuwe functie gaan werken. Feature branches moeten beschrijvende namen hebben, zoals new-banner-images of bug-91. Het idee is om iedere afdeling een duidelijk, zeer gericht doel te geven.
Git maakt geen technisch onderscheid tussen de hoofd- en functiebranches, zodat ontwikkelaars wijzigingen in een functiebranch kunnen bewerken, faseren en doorvoeren.
Een branch aanmaken
Wanneer u aan een project werkt, hebt u op elk gewenst moment veel verschillende functies of ideeën die worden uitgevoerd, waarvan sommige klaar zijn om te gaan en anderen die dat niet zijn. Vertakkingen bestaan om u te helpen deze workflow te beheren. Wanneer u een vertakking in uw project maakt, maakt u een omgeving waarin u nieuwe ideeën kunt uitproberen.
Naast het maken van vertakkingen voor nieuwe functies of oplossingen, maken teams die een releasebranchwerkstroom volgen ook speciale vertakkingen speciaal voor het voorbereiden van releases. Deze release-vertakkingen zijn doorgaans afgeleid van stabiele functietakken om ervoor te zorgen dat ze grondig geteste en gevalideerde code bevatten. Zodra de releasebranch is gemaakt, ondergaat de releasebranch aanvullende tests, bugfixes en stabilisatie-inspanningen om de codebasis voor te bereiden voor implementatie.
Commits toevoegen
Zodra uw branch is gemaakt, is het tijd om wijzigingen aan te brengen. Wanneer u een bestand toevoegt, bewerkt of verwijdert, maakt u een commit en voegt u deze toe aan uw vertakking.
Door commits toe te voegen, wordt je voortgang bijgehouden terwijl je aan een featurebranch werkt.
Commits maken ook een transparante geschiedenis van uw werk die anderen kunnen volgen om uw acties en de redenen daarvoor te begrijpen.
Elke doorvoering heeft een gekoppeld doorvoerbericht waarin wordt uitgelegd waarom een bepaalde wijziging is aangebracht.
Bovendien wordt elke commit beschouwd als een afzonderlijke eenheid van verandering. Hiermee kunt u wijzigingen terugdraaien als er een fout wordt gevonden of als u besluit om in een andere richting te gaan.
Doorvoerberichten zijn essentieel, met name omdat Git uw wijzigingen bijhoudt en deze weergeeft als doorvoeringen nadat ze naar de server zijn gepusht.
Door duidelijke doorvoerberichten te schrijven, kunt u het voor anderen gemakkelijker maken om mee te doen en feedback te geven.
Een pull-aanvraag openen
De Pull Requests starten een discussie over uw commits. Omdat ze nauw zijn geïntegreerd met de onderliggende Git-opslagplaats, kan iedereen precies zien welke wijzigingen zouden worden samengevoegd als ze uw aanvraag accepteren.
U kunt een pull-aanvraag op elk gewenst moment openen tijdens het ontwikkelingsproces wanneer:
- U hebt weinig of geen code, maar u wilt schermopnamen of algemene ideeën delen.
- Je zit vast en je hebt hulp of advies nodig.
- U bent klaar voor iemand die uw werk controleert.
Met behulp van het @mention-systeem in je pull-verzoekbericht kun je feedback vragen aan specifieke personen of teams, of ze zich nou aan het eind van de gang bevinden of in een andere tijdzone.
Met pull-aanvragen kunt u bijdragen aan projecten en voor het beheren van wijzigingen in gedeelde opslagplaatsen.
Als u een Fork-& pull-model gebruikt, bieden pull-aanvragen een manier om projectonderhouders op de hoogte te stellen van de wijzigingen die u wilt overwegen.
Als u een model voor een gedeelde opslagplaats gebruikt, helpen pull-aanvragen bij het beoordelen van code en het gesprek over voorgestelde wijzigingen voordat ze worden samengevoegd in de hoofdvertakking.
Uw code bespreken en controleren
Zodra een pull-aanvraag is geopend, kan de persoon of het team die uw wijzigingen bekijkt vragen of opmerkingen hebben.
Misschien komt de coderingsstijl niet overeen met projectrichtlijnen, ontbreekt de wijziging in eenheidstests, ziet alles er uitstekend uit en zijn de props in orde.
Pull-aanvragen zijn ontworpen om dit type gesprek aan te moedigen en vast te leggen.
U kunt ook verdergaan met pushen naar uw branch, rekening houdend met discussie en feedback over uw doorvoeringen.
Stel dat iemand opmerkt dat u iets bent vergeten of als er een fout in de code zit, dan kunt u dit in uw vertakking oplossen en de wijziging uploaden.
Git toont je nieuwe commits en eventuele feedback die je kunt ontvangen in de uniforme Pull Request-weergave.
Opmerkingen bij pull-aanvragen worden geschreven in Markdown, zodat u afbeeldingen en emoji's kunt insluiten, vooraf opgemaakte tekstblokken en andere lichtgewicht opmaak kunt gebruiken.
Implementeren
Met Git kunt u uitrollen vanaf een branch voor definitieve tests in een omgeving voordat u samenvoegt naar de main.
Nadat uw pull request is gecontroleerd en de vertakking de tests heeft doorstaan, kunt u uw wijzigingen uitrollen om deze te verifiëren. U kunt deze terugdraaien als uw vertakking problemen veroorzaakt door de bestaande hoofdvertakking te implementeren.
Samenvoegen
Zodra uw wijzigingen zijn geverifieerd, is het tijd om uw code samen te voegen in de hoofdbranch.
Na het samenvoegen behouden pull-aanvragen een record van de historische wijzigingen in uw code. Omdat ze doorzoekbaar zijn, laten ze iedereen terug in de tijd gaan om te begrijpen waarom en hoe er een beslissing is genomen.
U kunt problemen met code koppelen door specifieke trefwoorden op te nemen in de tekst van uw pull-aanvraag. Wanneer uw pull-aanvraag wordt samengevoegd, kunnen de gerelateerde problemen ook worden gesloten.
Dit werkproces helpt bij het organiseren en bijhouden van takken die zijn gericht op bedrijfsdomein-functiesets.
Andere Git-workflows, zoals de Git Forking Workflow en de Gitflow Workflow, zijn gericht op repositories en kunnen de Git Feature Branch Workflow gebruiken om hun vertakkingsmodellen te beheren.