Hvad er egentlig en pull-anmodning?

Udtrykket “pull anmodning” kommer fra git, hvor git pull -kommandoen bruges til at flette et andet lager til dit lokale. Så hvis en anden har en kopi af dit git lager, og foretager ændringer i det, så de gerne vil have dig for at inkorporere kan de bede dig om at pull ændringerne fra deres arkiv; de “re beder om en pull, deraf udtrykket” pull anmodning “.

I dag er det for de fleste brugere, at dette er skjult bag en grafisk grænseflade af en slags, på Github eller Bitbucket eller via Gerrit for eksempel; men princippet forbliver det samme: nogen kopierer dit arkiv, foretager ændringer og anmoder dem om at blive flettet i din egen kopi, sandsynligvis efter at du har gennemgået dem.

Kommentarer

• Git har også en git request-pull kommando. Dette giver en skriftlig besked, som du kan sende til en anden, der opfordrer dem til at bruge git pull til at inkorporere dit arbejde i deres kopi af softwaren.
• Kan ikke forklares tydeligere for begyndere.

Hvis du har distribuerede versionskontrol -systemer, hver udvikler har en kopi af det fulde lager. Hvis du ændrer noget til softwaren, forpligter du dine ændringer til dit lokale lager. Hvis forskellige arkiver skulle have disse ændringer, kan du skubbe ændringerne (flytning af ændringer til et andet lager, du har ret at skrive til) eller trække ændringerne (kopiere revision frem m andre opbevaringssteder til dine egne). Da mange projekter har et hovedlager, er en pull-anmodning den anmodning, som vedligeholderen trækker dine ændringer.

Læsning af lidt på det , det ser ud til, at udtrykket også bruges på ikke-distribueret versionskontrol, hvis en bruger beder om medtagelse af sine programrettelser i hovedgrenen af projektet. En anden læser især til github: https://help.github.com/articles/using-pull-requests/

En pull-anmodning er relateret til versionskontrolsystemer. Du kan have flere sæt brugere:

• Administratorer / ejere
• Bidragydere
• Testere

Du vil have hver af disse mennesker for at kunne gøre forskellige ting:

• Administratorer / ejere
  Disse mennesker kan man stole på. De har muligvis fuld adgang til det aktuelle arkiv, herunder fulde rettigheder til at begå, hvad de vil, når de vil.
• Bidragere
  Disse kan være tilfældige mennesker fra Internettet; de kan være mindre mennesker i en virksomhed. Uanset hvad, vil du sandsynligvis ikke have dem til at kunne forpligte sig direkte til kodebasen – du vil først gennemgå deres ændringer.

Det er her pull-anmodninger kommer ind. I stedet for at tillade lige ændringer til kodebasen fra dine bidragsydere, vil de i stedet forkaste lageret, skabe en kopi på deres lokale maskine og udvikle det. Når de er færdige, kan de oprette en pull-anmodning, der indeholder deres opdaterede kode. En person i den højere gruppe kan derefter gennemgå deres ændringer for at være korrekte og overholde standarder og flette deres ændringer, hvis de overholder.

Kommentarer

• Lidt væk fra emnet, men selv de mennesker, der kan direkte fusionere deres egne ændringer, skal indsende PRer, som deres jævnaldrende kan gennemgå. Forudsat at du ' arbejder på et team, der er. Hvis du ' ikke er, antager jeg at ' er hvad CodeReview er til.
• OK. Så trinene er: du forkaster hovedreposen, trækker den til din pc, ændrer den, forpligter dig og skubber til din forgrenede gren og derefter beder administratoren om at trække og flette fra din forgrenede gren til hovedvagten? ul>

En pull-anmodning (PR) er en metode til at indsende bidrag til et åbent udviklingsprojekt. Det sker, når en udvikler beder om ændringer, der er forpligtet til et eksternt lager, der skal overvejes at blive inkluderet i et projekts hovedlager efter peer review.

^{Kilde: Hvad er en pullanmodning? på OSS Watch}

Enkelt eksempel er når du kloner / forkæler open source-arkivet, foretager nogle ændringer / forpligter sig, og for at flette ændringerne i hovedlageret skal du sende pull-anmodningen, som består af alle dine forpligtelser grupperet i et logisk stykke, så det kan gennemgået af andre udviklere.

Dette har nogle fordele i forhold til standardforpligtelser og skubber, da du har nogle ekstra par øjne til at kontrollere og undgår almindelige / skjulte problemer / fejl inden de faktiske ændringer.

Se få PR-eksempler:

• GitHub her eller her
• Chromium Code Reviews (svarer til pull-anmodning)