Share
Bij het ontwikkelen van software maakt bronbeheer ons leven zoveel gemakkelijker. Van het volgen van onze wijzigingen tot het introduceren van codesamenwerking, het helpt onze productiviteit te verhogen. Bovendien, het feit dat er een aantal verschillende tools beschikbaar zijn - Subversion, Perforce, Mercurial, enzovoort - maakt het nog beter door ons de opties te bieden waaruit we kunnen kiezen.
In deze serie kijken we specifiek naar Git en het gebruik van Bitbucket en hoe ze ons kunnen helpen bij ons dagelijks werk. In dit artikel gaan we specifiek focussen op het gebruik van Bitbucket voor functiediscussie, bug-tracking, release-tagging en meer.
Een van de belangrijkste kenmerken van Git - en dus ook van Bitbucket - is het idee van pull-aanvragen. In dit artikel gaan we kijken naar pull-aanvragen en hoe ze ons niet alleen voordeel opleveren vanuit het oogpunt van bronbeheer, maar ook vanuit het oogpunt van peerreview.
Wanneer iemand een pull-aanvraag indient voor uw project, betekent dit dat ze vragen om hun code samen te voegen met de codebase. Dat wil zeggen, ze vragen dat je hun code in het project invoert.
Maar wij, als beheerders, hebben de mogelijkheid om de wijzigingen die door het verzoek zijn geïntroduceerd te herzien, te testen en samen te voegen. Vergis je niet: we spelen een zeer belangrijke rol bij het beslissen of het specifieke verzoek voldoet aan zowel de normen als de doelen van onze software.
Als een afwijking wordt gevonden, kunnen we de bijdrager vragen het pull-verzoek bij te werken door de code op te ruimen, openstaande problemen op te lossen of de algemene kwaliteit van de code te verbeteren. Aan de andere kant kunnen we ook het pull-verzoek afwijzen als we besluiten dat het niet voldoet aan de criteria die we voor het project nodig achten.
Om een pull-aanvraag uit te kunnen vaardigen, moet een persoon eerst de codebase van het initiële project invullen. Dit betekent dat ze een momentopname maken van de codebase in de huidige staat, een reeks wijzigingen maken en vervolgens de wijzigingen in hun persoonlijke kopie van de code vastleggen. Van daaruit vraagt de ontwikkelaar vervolgens om de wijziging in de eerste repository te plaatsen.
Zoals eerder vermeld, kunnen trekkingsverzoeken uit een aantal dingen bestaan:
Gebruikt door teams van elke omvang - zowel intern als gedistribueerd - broncontrolebeheer is een waardevol onderdeel van het ontwikkelen van software. Het gaat erom dat gebruikers bij het werken met broncontrolesystemen verschillende rechtenrollen hebben.
Dat wil zeggen dat als het gaat om het onderhouden van een repository, sommige ontwikkelaars alleen-lezen toegang hebben terwijl anderen zowel lees- als schrijftoegang hebben. En degenen met schrijftoegang zijn degenen die verantwoordelijk zijn voor het handhaven van pull-aanvragen.
In deze reeks artikelen bekijken we hoe Bitbucket de werkstroom van uw team kan verbeteren als het gaat om het ontwikkelen van software. Net zoals we eerder hebben besproken, stelt Bitbucket mensen in staat om aan het project deel te nemen, zowel door code ernaar toe te schrijven, door pull-aanvragen te bekijken en door samenvoegingen van genoemde verzoeken te maken.
Een van de leukste functies van Bitbucket is dat u meerdere beoordelaars kunt toevoegen aan een pull-aanvraag die vervolgens het verzoek kan goedkeuren (of weigeren). Dit geeft op zijn beurt degenen die de repository onderhouden de mogelijkheid om de kwaliteit van de code te controleren die is opgegeven in het pull-verzoek.
Misschien verwelkomen ze de aanvullingen op het project, misschien niet. Hoe het ook zij, Bitbucket biedt onderhoudspersoneel de tools die nodig zijn om feedback te geven over een bepaald verzoek om uitbetaling.
Ten slotte ondersteunt Bitbucket inline commentaar op elk pull-verzoek, waardoor het veel gemakkelijker wordt om een specifieke regel, blok of module met code te bespreken.
Al met al maakt deze benadering het veel gemakkelijker om te bepalen of een pull-verzoek al dan niet moet worden samengevoegd, als het moet worden afgewezen, of welke gebieden van de could moeten worden gewijzigd voordat het verzoek wordt samengevoegd.
Ga om te beginnen naar het dashboard van een project in uw webbrowser en klik vervolgens op Vork om de repository te splits.
Vervolgens krijgt u een formulier te zien waarin u een aangepaste naam en een aangepaste beschrijving kunt opgeven. U hebt ook de mogelijkheid om de zichtbaarheid en machtigingen van de repository tussen andere functies in te stellen.
Als u verantwoordelijk bent voor de code die wordt geschreven en toegang wilt tot aanvullende hulpmiddelen om het gemakkelijker te maken om met een team rond de codebase te werken, selecteert u de Project management optie uit het bijbehorende interface-element.
Na klikken op de Vorkrepository knop, je pakt de nieuwste versie van de codebase van het project en hebt deze beschikbaar in een repository die helemaal van jou is. Om de code van uw lokale computer te bekijken, kunt u een Git-client zoals SourceTree gebruiken, of u kunt dit doen vanaf de opdrachtregel door de volgende opdrachten uit te voeren in de lokale map waar uw project is opgeslagen:
$ git clone https: //[email protected]/uwgebruikersnaam/reponame.git
Merk op dat de URL die we hierboven hebben opgegeven zichtbaar is in het dashboard van je repository in het dashboard van Bitbucket.
Nadat u de code hebt uitgecheckt, kunt u aan het project werken op uw lokale computer. Terwijl u wijzigingen introduceert, moet u dit toewijzen aan de repository. Om dit te doen, moet je eerst je werk in scène zetten en vervolgens je werk aan de repository toewijzen.
Op dit moment zijn we klaar om daadwerkelijk aan het werk te gaan. Wat dit betekent, hangt af van de aard van je project: misschien werk je eraan een bug te sluiten, misschien ben je een functie aan het herzien, of misschien voeg je een functie toe.
Hoe dan ook, nadat de wijzigingen zijn doorgevoerd, kunt u een commit aan de repository toewijzen. Dit betekent dat je de bestanden neemt waaraan je hebt gewerkt en ze combineert in een enkele verzameling wijzigingen die een changeset wordt genoemd. Veranderingen worden meestal vergezeld door een kort bericht waarin wordt uitgelegd wat er is gewijzigd en waarom.
Wanneer je code schrijft, in het begin, duw je eigenlijk niets naar de repository. Met andere woorden, als dit je eerste commit is, wordt je code niet online opgeslagen in Bitbucket. In plaats daarvan bestaan de wijzigingen alleen op uw lokale computer. Zodra je je eerste push hebt uitgevoerd, bestaat de code dan in de repository.
Uiteindelijk biedt bronbeheer een manier om een schone geschiedenis van uw wijzigingen te behouden, evenals een eenvoudige manier om terug te gaan naar een bepaald punt in de tijd.
Nadat u een wijziging in de externe repository hebt doorgevoerd (via een client of via de opdrachtregel), kunt u een pull-aanvraag initialiseren. Dit betekent dat je klaar bent om code te gebruiken die je in je voorvork van de codebasis hebt geduwd en de oorspronkelijke beheerders vraagt of ze de code in hun project zullen samenvoegen.
Dit doen binnen de Bitbucket-applicatie is eenvoudig. Ga gewoon naar het dashboard van de gevorkte repository en klik vervolgens op Maak een pull-aanvraag.
Vervolgens krijg je een interface te zien waarmee je je pull-verzoek kunt maken. Het verzoek omvat uw repository, de originele repository en een titel en beschrijving.
Hier selecteert u uw repository als de bronrepository en de repository van de originele codebase als de doelrepository. Mogelijk moet u deze binnen het dashboard wijzigen, afhankelijk van uw vereisten.
Als u bijvoorbeeld uw exemplaar van de code "ontwikkelen" hebt genoemd bij het eerder geven van de opdracht "git add remote", maar de originele codebase gebruikt het woord "master", dan moet u ervoor zorgen dat u hebt geselecteerd de juiste waarden.
Ten slotte kunt u hier Bitters toevoegen aan een pull-aanvraag. Zoals eerder vermeld, maakt dit het veel gemakkelijker om de aandacht van projectbeheerders te trekken, zodat ze uw werk kunnen beoordelen, eventuele opmerkingen kunnen maken en uw verzoek kunnen samenvoegen (of weigeren).
Bitbucket werkt je pull-aanvraag automatisch bij wanneer je code naar de brondirectory pusht, zodat de projectreviewer altijd de nieuwste code te zien krijgt die ze kunnen ophalen.
Wanneer de recensent om een specifieke wijziging vraagt, kan hij de gevraagde wijzigingen eenvoudig in uw kopie van de repository pushen - dat wil zeggen, de gevorkte repository.
Als u een repository bijhoudt die pull-aanvragen van anderen ontvangt, zult u waarschijnlijk merken dat uw repository zowel een kennisgeving in het Bitbucket-toepassingsdashboard als in uw e-mail ontvangt.
Als u een revisor bent, ontvangt u ook een melding en een e-mail. Om alle inkomende pull-aanvragen te beheren, klikt u op de link "Pull requests" en selecteert u de pull-aanvraag waarmee u wilt werken.
Zoals u kunt zien, biedt Bitbucket een schone interface waar u pull-aanvragen kunt bespreken en bekijken. Zowel beheerders als kijkers kunnen weigeren, samenvoegen of vragen om extra werk te verrichten voor een bepaald pull-verzoek.
Ervan uitgaande dat u een verzoek hebt dat klaar is om te worden samengevoegd, klikt u op de specifieke optie om precies dat te doen. Als je toevallig met meerdere beoordelaars werkt, maakt Bitbucket ook duidelijk wie de aanvraag heeft goedgekeurd door een vinkje in hun avatar aan te brengen. Het is duidelijk dat hoe meer cheques er in de revisoren voorkomen, hoe groter de kans is dat het verzoek kan worden samengevoegd.
Maar wat gebeurt er als fusie van het pull-verzoek mislukt? Op dit punt moet handmatig worden samengevoegd (wat een veelvoorkomend onderdeel is van broncodebeheer, maar buiten het bereik van dit artikel), waarna de code wordt toegewezen aan de repository.
Het is duidelijk dat bronbeheer veel voordelen biedt voor teams; Trekaanvragen zijn echter een krachtige functie die het gemakkelijk maken om bij te dragen aan een project en anderen uw code laten beoordelen, er commentaar op geven en deze verbeteren voordat ze worden samengevoegd in de codebase.
Alleen dit kan iemand helpen om een veel betere ontwikkelaar te worden, terwijl je leert van de ervaring van andere ontwikkelaars die het grotere project onderhouden. Gebruik pull-verzoeken in uw werkstroom om uw code te verbeteren en feedback van anderen te verzamelen als u dat nog niet bent.
.
Accentsconagua