GitHub-bijdrageworkflow voor grote wijzigingen

Overzicht

Deze workflow is geschikt voor een medewerker die een grote wijziging moet aanbrengen of die regelmatig een bijdrage levert aan een opslagplaats. De frequente contribuanten hebben typisch aan de gang zijnde (lang lopende) veranderingen, die door veelvoudige bouwstijl/bevestiging/het opvoeren cycli gaan of veelvoudige dagen overspannen alvorens trekverzoek aftekenen en samenvoegen.

Terminologie

Alvorens u begint, herzien sommige termijnen Git/GitHub die in dit werkschema worden gebruikt.

Naam
Beschrijving
vork
Normaal gebruikt als naamwoord, wanneer het verwijzen naar een exemplaar van een belangrijkste bewaarplaats GitHub. In de praktijk is een vork gewoon een andere opslagplaats. Maar het is speciaal in die zin dat GitHub een verbinding in twee richtingen terug naar de hoofd/ouderbewaarplaats handhaaft. Het wordt soms gebruikt als werkwoord, zoals in "U moet eerst de gegevensopslagplaats vorken."
extern
Een benoemde verbinding met een externe opslagplaats, zoals de "oorspronkelijke" of "upstream" externe opslagplaats. Git verwijst hiernaar als externe bestanden omdat deze worden gebruikt om te verwijzen naar een opslagplaats die op een andere computer wordt gehost. In dit werkschema, is ver altijd een bewaarplaats GitHub.
oorsprong
De naam die is toegewezen aan de verbinding tussen uw lokale opslagplaats en de opslagplaats waaruit deze is gekloond. In deze workflow staat de oorsprong voor de verbinding met uw vork. Het wordt soms gebruikt als een moniker voor de oorspronkelijke repository zelf, zoals in "Herinner me om uw veranderingen in oorsprong te duwen."
upstream
Net als de oorspronkelijke externe server is upstream een benoemde verbinding met een andere repository. In deze workflow vertegenwoordigt upstream de verbinding tussen uw lokale opslagplaats en de hoofdopslagplaats, waaruit uw vork is gemaakt. Het wordt soms gebruikt als moniker voor de stroomopwaartse bewaarplaats zelf, zoals in "Herinner me om de veranderingen van upstream terug te trekken."

Als u met de concepten Git en GitHub zoals een bewaarplaats of een tak onbekend bent, gelieve eerst te herzien Git en de fundamentele waarden van GitHub.

Workflow

IMPORTANT
Als u niet reeds hebt, moet u de stappen in de sectie van de Opstellingvoltooien.

In deze workflow worden wijzigingen doorgevoerd in een herhalingscyclus. Beginnend van de lokale bewaarplaats van uw apparaat, stromen zij terug naar uw vork GitHub, in de belangrijkste bewaarplaats GitHub, en terug plaatselijk terug aangezien u veranderingen van andere contribuanten opneemt.

GitHub-stroom gebruiken

Rappel van fundamentele waarden van Git en van GitHubdat een bewaarplaats van de Git een belangrijkste tak, plus om het even welke extra werk-in-vooruitgang takken bevat die niet in hoofd zijn geïntegreerd. Wanneer u een reeks logisch gezien verwante veranderingen introduceert, is het een beste praktijk om a werkende tak tot stand te brengen om uw veranderingen door het werkschema te beheren. Wij verwijzen hier naar het als werkende tak omdat het een werkruimte is om veranderingen te herhalen/te verfijnen, tot zij terug in de belangrijkste tak kunnen worden geïntegreerd.

Door gerelateerde wijzigingen in een specifieke vertakking te isoleren, kunt u deze wijzigingen onafhankelijk beheren en introduceren en kunt u ze op een specifieke releasetijd in de publicatiecyclus toepassen. Afhankelijk van het type werk dat u doet, kunt u in feite eenvoudig met verschillende werkvertakkingen in uw opslagplaats belanden. Het is niet ongebruikelijk om aan veelvoudige takken tezelfdertijd te werken, elk die een verschillend project vertegenwoordigen.

NOTE
Het maken van uw veranderingen in de belangrijkste tak is geen goede praktijk. Veronderstel dat u de belangrijkste tak gebruikt om een reeks veranderingen voor een vastgestelde eigenschapversie voor te stellen. U voltooit de wijzigingen en wacht op de release ervan. Ondertussen hebt u een dringend verzoek om iets te repareren, dus brengt u de wijziging aan in een bestand in de hoofdvertakking en publiceert u de wijziging. In dit voorbeeld, publiceert u per ongeluk zowel de moeilijke situatie als de veranderingen die u voor versie op een specifieke datum hield.

De volgende stap bestaat uit het maken van een nieuwe werkende vertakking in uw lokale opslagplaats om de voorgestelde wijzigingen vast te leggen. Elke client is anders, dus raadpleeg de Help voor uw voorkeursclient. U kunt een overzicht van het proces in de GitHub Gids op GitHub stroomzien.

Verwerking van aanvraag volledig uitvoeren

U kunt voorgestelde wijzigingen verzenden door deze te bundelen in een nieuw pull-verzoek (PR) dat wordt toegevoegd aan de PR-wachtrij van de doelopslagplaats. Een trektrekkingsverzoek laat het samenwerkingsmodel van GitHub toe, door te vragen om de veranderingen van uw werkende tak worden getrokken en in een andere tak worden samengevoegd. In de meeste gevallen is die andere vertakking de standaard/hoofdvertakking in de hoofdopslagplaats.

Validatie

Alvorens uw trekkingsverzoek in zijn bestemmingstak kan worden samengevoegd, zou het door één of meerdere processen van de PR bevestiging kunnen moeten overgaan. Validatieprocessen kunnen variëren afhankelijk van het bereik van voorgestelde wijzigingen en de regels van de gegevensopslagruimte van bestemming. Nadat uw pull-verzoek is verzonden, kunt u verwachten dat de inhoud wordt gecontroleerd en, indien van toepassing, wordt samengevoegd in de hoofdopslagplaats.

Reviseren en aftekenen

Nadat alle PR-verwerking is voltooid, moet u de resultaten controleren (PR-opmerkingen, voorbeeld-URL's, enz.) om te bepalen of extra veranderingen in zijn dossiers worden vereist alvorens u voor het samenvoegen ondertekent. Als een PR-controleur uw intrekkingsverzoek heeft beoordeeld, kunnen deze ook feedback geven via opmerkingen als er nog onopgeloste problemen/vragen zijn die moeten worden opgelost voordat ze worden samengevoegd.

Wanneer de trekkingsaanvraag emissievrij is en afgemeld, worden uw wijzigingen weer samengevoegd in de bovenliggende vertakking en wordt de trekkingsaanvraag gesloten.

Publiceren

Vergeet niet dat uw pull-verzoek moet worden samengevoegd met een PR-controleur voordat de wijzigingen kunnen worden opgenomen in de volgende geplande publicatiereeks. Een volledige aanvraag wordt doorgaans in de volgorde van indiening beoordeeld of samengevoegd. Als voor uw pull-verzoek samenvoeging voor een specifieke publicatiereeks is vereist, moet u vooraf met uw PR-controleur werken om ervoor te zorgen dat samenvoegen plaatsvindt voordat de publicatie wordt uitgevoerd.

recommendation-more-help
f0a0e44c-5d56-45af-ac98-47677caca18f