Enkel opplæring for å lage din første PR (Pull Request)

Vel, denne hvis jeg tror det blir en ganske kort opplæring og forhåpentligvis didaktisk;). Jeg skal gjøre et lite arkiv tilgjengelig for deg på githuben min, slik at du kan sende PR-ene dine og samtidig slik at du kan øve deg på hvordan du gjør alle trinnene jeg skal la nedenfor. Her er lenken for å gjøre testen PR:

https://github.com/CodeLabora/TuPrimerPR

Vel, la oss raskt liste opp trinnene som er nødvendige for å sende en PR:

1. Gaffel
2. Clone
3. Remote
4. Branch
5. endringer
6. Legg til
7. Forplikte
8. Skyv
9. PR

Jeg legger dem på engelsk slik at de finner sine respektive alternativer på git-kommandolinjen.

Gaffel

En gaffel er din egen versjon av et Github-arkiv. Dette lar deg klone arbeidet til et annet prosjekt og ha det på kontoen din slik at du kan endre ting uten å bekymre deg for å miste endringene. For å lage en gaffel er det bare nødvendig å gå til siden og klikke på gaffelknappen øverst til høyre.

Når gaffelen er ferdig, vil du se at depotet vises i kontoen din.

Clone

Nå som vi har et depot, skal vi klone det til teamet vårt. (Jeg antar at folk som bruker Linux følger meg, men for brukere av andre systemer er det også versjoner av git som du kan laste ned på den offisielle siden.

Og med terminalen vår gjør vi følgende.

Med dette vil vi ha en ny mappe kalt TuPrimerPR der Github-prosjektet vårt vil være. Vi går inn i mappen med kommandoen «cd TuPrimerPR» og vi vil se at innsiden er filene som er i gaffelen vår.

(Merk at antall filer kan variere avhengig av hva de finner i depotet mitt når de forkaster)

Remote

Dette er et valgfritt trinn, men det unngår mange problemer når du jobber kontinuerlig med et prosjekt. Gaffel oppretter som standard en nøyaktig kopi av depotet, men akkurat på tidspunktet for opprettelsen. Dette betyr at hvis prosjektet fortsetter å gå videre, vil depotet ditt ligge bak med løpet av dager eller timer. "Git remote" lar oss spesifisere et annet nedlastingspunkt (det opprinnelige prosjektet) og dermed være i stand til å oppdatere prosjektet vårt hver gang vi ser at det overordnede prosjektet blir oppdatert.

For å finne foreldreprosjektet ditt, trenger du bare å bruke lenken som er rett under navnet på depotet ditt. (Sjekk det andre bildet av gaffeldelen). Vi kommer til å legge til denne informasjonen nedenfor:

Dette er det opprinnelige prosjektet (vi vil kalle det oppstrøms for å holde tritt med mange prosjekter).

Som du kan se, har jeg lagt til fjernkontrollen med »git remote add »

Med dette vil vi kunne oppdatere prosjektet når det er nødvendig, men vi vil ikke bruke det nå fordi det ikke er nødvendig. (Jeg vil forklare det senere, eller i et annet innlegg, avhengig av behovet)

Branch

Grenene (eller grenene) lar deg lage kodeseksjoner som du kan jobbe i et isolert miljø. Dette betyr at det du gjør i en gren ikke nødvendigvis påvirker den opprinnelige koden før en »git merge« er brukt. Det er også en ekstra funksjonalitet som Github tillater deg, hver gang du oppretter en filial, genererer Github automatisk kilden til Pull Request når det er nødvendig.

Nå som vi er i vår spesielle gren, kan vi jobbe med vårt bidrag.

endringer

Jeg skal legge til et par filer slik at du kan se hvordan det gjøres.

"Touch" lar oss lage en tom fil (hvis den ikke eksisterer). med dette kan vi gå videre til neste trinn.

Legg til

»Git add» lar oss legge til filer i vår forpliktelse (jeg forklarer senere). For å se hvilke filer du kan legge til, kan du bruke kommandoen »git status»

Med dette har vi alt klart for vår forpliktelse

Forplikte

Forpliktelser er merker (eller milepæler) i tide. de definerer en tilstand for alle filer i prosjektet og samler de endringene som er nødvendige for å komme fra begynnelsen av prosjektet til den nåværende tilstanden. Det høres litt komplekst ut, men det er ganske enkelt, bare husk at de er trappene til prosjektet ditt. Vi skriver »git commit», og vi får et vindu til å skrive kommittmeldingen.

Og når vi fullfører og lagrer teksten, ser vi noe sånt som:

Hvor det vises et sammendrag av hva forpliktelsen gjør.

Skyv

Med push laster vi opp til Github-kontoen vår alle forpliktelsene vi har på datamaskinen som ikke er i vårt lager på internett. Dette vil tillate Github å generere den nye PR automatisk.

Legg merke til at vi bruker navnet på grenen vår og at den ber oss om brukernavn og passord. På slutten viser det oss at myImprove-grenen er opprettet i Github-kontoen vår. La oss se hva vi har oppnådd i nettleseren. 😉

PR

Som du ser er det opprettet en ny linje som sier "Sammenlign og trekk forespørsel". Denne Github-funksjonaliteten lar oss lage PR på en enkel måte, vi skal klikke for å se hva som skjer.

Github er ganske smart. Som du kan se, legges deler av forpliktelsen til skjemaet for innlevering. Det er bare nødvendig å klikke på knappen og voila 🙂 Enkelt.

ekstra

Dette er bak kulissene til prosjektene, PR vises og lederen bestemmer om han vil godta eller ikke, eller om han vil skrive flere meldinger. I mitt tilfelle vil jeg godta det umiddelbart.

Når sammenslåingen er gjort, vil de kunne se prosjektets forpliktelseslogg og se navnet sitt i den.

Men nå har vi et problem. Den forpliktelsen vises ikke i vår depot, bare i prosjektet. Husker du fjernkontrollen vår? Nå er det når det lønner seg 🙂

Vi går tilbake til mastergrenen vår og gjør følgende:

Med dette har vi lastet ned all informasjonen til det opprinnelige prosjektet til teamet vårt. Som du kan se, vises vår forpliktelse der. Nå skal vi lagre alt dette arbeidet i Github-arkivet vårt for å kunne slette grenen som har innspillene som de allerede har lagt til i prosjektet.

Nå som vi har vårt oppdaterte Github-arkiv, skal vi slette grenen vår, men først sørger vi for at den er inne i hovedgrenen (master)

Som du ser, hadde jeg en liten feil, dette var fordi jeg var i min myImprovement-gren da jeg ønsket å slette. Dette løses ved å gå tilbake til mastergrenen.

Konklusjon

Ferdig 🙂 så enkelt som det. Nå som du har mestret de mørke hemmelighetene til Github for å sende PR, ser jeg frem til å se dine bidrag til forskjellige prosjekter. Og hvis du vil, kan du legge igjen din første PR i depotet mitt 😉 for minnet.

Jeg har ikke rørt tusen og en Git-fordeler (EYE, ikke Github), og som du forventer av utviklere som er knyttet til kjernefellesskapet, er Git et ekstremt kraftig verktøy med hundrevis av funksjoner.

For å få en bedre ide om hva den gjør og all kraften til Git, anbefaler jeg dette bok. Jeg er sikker på at det vil hjelpe deg mye med å forbedre håndteringen av git.

Hilsen og jeg håper det hjelper deg 😉