En udviklers introduktion til GitHub

Er du interesseret i at lære JavaScript? Få min gratis e-bog på jshandbook.com

GitHub er et websted, der er vært for milliarder af kodelinjer, og det er her, millioner af udviklere samles hver dag for at samarbejde om og rapportere problemer med open source-software.

Kort sagt, det er en platform for softwareudviklere, og den er bygget op omkring Git.

TIP: Hvis du endnu ikke ved noget om Git, skal du tjekke min Git-guide.

Som udvikler kan du ikke undgå at bruge GitHub eller et andet Git-baseret værktøj dagligt som en del af dit arbejde. Den bruges til enten at være vært for din kode eller til at samarbejde om andre menneskers kode. Denne artikel forklarer nogle nøglekoncepter i GitHub, og hvordan du bruger nogle af dens funktioner til at forbedre din arbejdsgang.

Hvorfor GitHub?

Nu hvor du ved, hvad GitHub er, kan du spørge, hvorfor du skal bruge det.

GitHub administreres trods alt af en privat virksomhed, der drager fordel af at være vært for folks kode. Så hvorfor skal du bruge det i stedet for lignende platforme som BitBucket eller GitLab?

Ud over personlige præferencer og tekniske grunde er der en stor grund: alle bruger GitHub, så netværkseffekten er enorm.

Store kodebaser er over tid migreret fra andre versionskontrolsystemer til Git på grund af dens bekvemmelighed, og GitHub har historisk set været godt positioneret og lagt en stor indsats for at imødekomme Open Source-samfundets behov.

Så i dag, hver gang du finder et bibliotek op, vil du 99% af tiden finde det på GitHub.

Bortset fra Open Source-kode, er mange udviklere også vært for private opbevaringssteder på GitHub på grund af platformens bekvemmelighed.

Lad os nu komme i gang med de vigtige Git-specifikke koncepter, som en udvikler har brug for at vide.

GitHub-problemer

GitHub-emner er en af ​​de mest populære bug trackere i verden.

De giver ejerne af et lager mulighed for at organisere, tagge og knytte spørgsmål til milepæle.

Hvis du åbner et problem på et projekt, der administreres af en anden, forbliver det åbent, indtil enten du lukker det (for eksempel hvis du finder ud af det problem, du havde), eller repo-ejeren lukker det.

Nogle gange får du et endeligt svar, og andre gange vil problemet blive åbent og tagget med nogle oplysninger, der kategoriserer det. Derefter kan udvikleren komme tilbage til det for at løse problemet eller forbedre kodebasen med din feedback.

De fleste udviklere får ikke betalt for at støtte deres kode frigivet på GitHub, så du kan ikke forvente hurtige svar. Men nogle open source-lagre offentliggøres af virksomheder, der leverer tjenester omkring denne kode, har kommercielle tilbud til versioner med flere funktioner eller bruger en plugin-baseret arkitektur. Og så har de betalt udviklere, der arbejder på open source-projektet.

Social kodning

Billedkredit: https://octodex.github.com

For et par år siden indeholdt GitHub-logoet tagline "social coding".

Hvad betød dette, og er det stadig relevant? Det er det bestemt.

Følge efter

Med GitHub kan du følge en udvikler eller et lager ved at gå til brugerens profil og klikke på "følg" eller ved at klikke på "ur" -knappen på en repo.

I begge tilfælde vises aktiviteten på dit betjeningspanel. At følge en bruger eller et lager er i modsætning til Twitter, hvor du ser hvad folk siger - i stedet ser du hvad folk gør.

stjerner

Én stor funktion ved GitHub er evnen til at spille et depot. Denne handling vil inkludere den på din liste over "stjernemarkerede lagre", som giver dig mulighed for at holde styr på projekter, som du finder interessante og opdage lignende projekter.

Det er også en af ​​de vigtigste klassificeringsmekanismer, da jo flere stjerner en repo har, jo mere populær og vigtig er den generelt. Dette resulterer i, at det vises mere prominent i søgeresultaterne.

Store projekter kan have titusinder af stjerner.

GitHub har også en trendside, hvor den indeholder de depoter, der får flest stjerner i et bestemt tidsrum (for eksempel i dag eller denne uge eller denne måned).

At komme ind på disse trendlister kan forårsage andre netværkseffekter som at blive vist på andre sider, bare fordi du har mere synlighed.

Gaffel

Den sidste vigtige netværksindikator for et projekt er antallet af gafler.

Dette er nøglen til, hvordan GitHub fungerer, da en gaffel er basen i en Pull Request (PR), som er et ændringsforslag. En person kan gaffel dit lager, foretage nogle ændringer og derefter oprette en pull-anmodning for at bede dig om at flette disse ændringer.

Nogle gange beder den, der gaffler et lager, aldrig dig om at flette noget. De vil muligvis gaffel dit depot, bare fordi de kunne lide din kode og besluttede at tilføje noget oven på det, som de ikke ønsker at flette tilbage i det originale arkiv. En bruger kan også løse en fejl, de oplevede, og som var specifik for dem.

Populær = bedre

Alt i alt er det alle nøgleindikatorer for populariteten af ​​et projekt. Bortset fra de ovennævnte indikatorer er datoen for det seneste engagement og forfatterens inddragelse i udgaver trackeren nyttige indikationer om, hvorvidt du skal stole på et bibliotek eller software.

Træk anmodninger

I det foregående afsnit introducerede jeg, hvad en Pull Request (PR) er. For at gentage kan en person gaffel dit depot, foretage nogle ændringer og derefter oprette en pull-anmodning for at bede dig om at flette disse ændringer.

Et projekt kan have hundreder af PR'er, og det er generelt tilfældet, at jo mere populært et projekt, desto flere PR'er har det, ligesom React-projektet:

Når en person har indsendt en pull-anmodning, skal den gennemgås af projektets kerneholdere.

Afhængigt af omfanget af din pull-anmodning (antallet af ændringer, antallet af ting, der er påvirket af din ændring, eller kompleksiteten af ​​den berørte kode), kan vedligeholderen have brug for mere eller mindre tid for at sikre dig, at dine ændringer er kompatible med projektet.

Et projekt kan have en klar tidslinje for ændringer, de vil introducere. Vedligeholderen kan lide at holde tingene enkle, mens du introducerer en kompleks arkitektur i en pull-anmodning.

Det vil sige, at en pull-anmodning ikke altid accepteres hurtigt, og der er ingen garanti for, at pull-anmodningen nogensinde vil blive accepteret.

I det eksempel, jeg har sendt herover, er der en anmodning om træk i repoen, der stammer fra for 1,5 år siden. Og dette sker i alle projekter - det er helt normalt og kan skyldes de grunde, jeg nævnte ovenfor.

Projektledelse

Sammen med problemer, som er de steder, hvor udviklere får feedback fra brugere, tilbyder GitHub-grænsefladen andre funktioner, der sigter mod at give et par projektstyringsfunktioner.

Et af disse er projekter. Det er meget nyt i økosystemet og meget sjældent brugt, men det er et Kanban-bord, der hjælper med at organisere problemer og arbejde, der skal gøres.

Wiki er beregnet til at blive brugt som en dokumentation for brugere. En af de mest imponerende anvendelser af den Wiki, jeg har set indtil nu, er Go Programming Language GitHub Wiki.

En anden populær støtte til projektstyring er milepæle. Det er en del af emnesiden, og du kan tildele emner til specifikke milepæle, som kunne være frigivelsesmål.

Apropos udgivelser forbedrede GitHub Git-tagfunktionaliteten ved at introducere udgivelser.

Et Git-tag er en markør til et specifikt engagement, og hvis det gøres konsekvent, hjælper det dig med at rulle tilbage til den tidligere version af din kode uden at henvise til specifikke forpligtelser.

En GitHub-udgivelse bygger på toppen af ​​Git-tags og repræsenterer en komplet frigivelse af din kode sammen med Zip-filer, udgivelsesnotater og binære aktiver, der muligvis repræsenterer en fuldt ud fungerende version af din kodes slutprodukt.

Mens et Git-tag kan oprettes programmatisk (for eksempel ved hjælp af kommandolinjegit-programmet), er det at oprette en GitHub-udgivelse en manuel proces, der sker gennem GitHub-brugergrænsefladen. Du fortæller dybest set GitHub at oprette en ny udgivelse og fortælle dem, hvilket tag du vil anvende denne udgivelse på.

Sammenligning af forpligtelser

GitHub tilbyder mange værktøjer til at arbejde med din kode.

En af de vigtigste ting, du måske ønsker at gøre, er at sammenligne en gren med en anden. Eller måske vil du sammenligne de seneste engagementer med den version, du i øjeblikket bruger, for at se, hvilke ændringer der blev foretaget over tid.

GitHub giver dig mulighed for at gøre dette med sammenligningsvisningen: bare tilføj / sammenligne til slutningen af ​​repo-navnet.

For eksempel https://github.com/facebook/react/compare

I figuren nedenfor sammenligner jeg den nyeste React v15.x med den seneste v16.0.0-rc-version, der var tilgængelig på dette tidspunkt for at se, hvad der er ændret.

Denne visning viser de forpligtelser, der er foretaget mellem to udgivelser (eller tags eller forpligtelser referencer), der blev ændret, og den faktiske diff, hvis antallet af ændringer er lavere end et rimeligt beløb.

Webhooks og services

GitHub tilbyder mange funktioner, der hjælper udviklerens arbejdsgang, såsom webhooks og tjenester.

Webhooks

Webhooks tillader, at eksterne tjenester pinges, når visse hændelser sker i depotet, for eksempel når kode skubbes, en gaffel oprettes, eller et tag oprettes eller slettes.

Når en begivenhed sker, sender GitHub en POST-anmodning til den URL, vi fortæller den skal bruge.

En almindelig anvendelse af denne funktion er at pinge en ekstern server for at hente den nyeste kode fra GitHub, når vi skubber en opdatering fra vores lokale computer.

Vi skubber til GitHub, GitHub fortæller den server, vi skubbede, og serveren trækker fra GitHub.

Services

GitHub-tjenester og de nye GitHub-apps er tredjepartsintegrationer, der forbedrer udvikleroplevelsen eller leverer en service til dig.

For eksempel kan du indstille en testløber til at køre testene automatisk, hver gang du skubber på nogle nye forpligtelser ved hjælp af TravisCI.

Du kan konfigurere kontinuerlig integration vha. CircleCI.

Du kan oprette en Codeclimate-integration, der analyserer koden og giver en rapport om "Teknisk gæld" og testdækning.

Afsluttende ord

GitHub er et fantastisk værktøj og service at drage fordel af, en rigtig perle i dagens udviklingsværktøjssæt. Denne tutorial hjælper dig med at komme i gang, men den virkelige oplevelse af at arbejde på GitHub open source (eller closed source) projekter er noget man ikke må gå glip af.

Er du interesseret i at lære JavaScript? Få min gratis e-bog på jshandbook.com