Een inleiding voor ontwikkelaars van GitHub

Wilt u JavaScript leren? Ontvang mijn gratis ebook op jshandbook.com

GitHub is een website die miljarden regels code host en waar miljoenen ontwikkelaars elke dag samenkomen om samen te werken en problemen met open source software te melden.

Kortom, het is een platform voor softwareontwikkelaars en het is gebouwd rond Git.

TIP: als je nog niet weet over Git, bekijk dan mijn Git-gids.

Als ontwikkelaar kun je niet voorkomen dat je GitHub of een andere op Git gebaseerde tool dagelijks gebruikt als onderdeel van je werk. Het wordt gebruikt om uw code te hosten of om samen te werken aan de code van anderen. In dit artikel worden enkele sleutelconcepten van GitHub uitgelegd en worden enkele van de functies ervan gebruikt om uw workflow te verbeteren.

Waarom GitHub?

Nu je weet wat GitHub is, kun je je afvragen waarom je het zou moeten gebruiken.

GitHub wordt tenslotte beheerd door een privébedrijf, dat profiteert van het hosten van de code van mensen. Dus waarom zou je dat gebruiken in plaats van vergelijkbare platforms zoals BitBucket of GitLab?

Naast persoonlijke voorkeuren en technische redenen is er een grote reden: iedereen gebruikt GitHub, dus het netwerkeffect is enorm.

Belangrijke codebases zijn in de loop van de tijd gemigreerd van andere versiebeheersystemen naar Git vanwege het gemak, en GitHub is historisch goed gepositioneerd en heeft veel moeite gedaan om aan de behoeften van de Open Source-gemeenschap te voldoen.

Dus vandaag, wanneer je een bibliotheek opzoekt, zul je deze voor 99% van de tijd op GitHub vinden.

Naast Open Source-code hosten veel ontwikkelaars ook privérepository's op GitHub vanwege het gemak van het platform.

Laten we nu beginnen met de belangrijke Git-specifieke concepten die een ontwikkelaar moet kennen.

GitHub-problemen

GitHub-problemen zijn een van de populairste bug-trackers ter wereld.

Ze bieden de eigenaren van een repository de mogelijkheid om problemen te organiseren, te taggen en te koppelen aan mijlpalen.

Als u een probleem opent met een project dat door iemand anders wordt beheerd, blijft het open totdat u het sluit (bijvoorbeeld als u erachter komt welk probleem u had) of de repo-eigenaar het sluit.

Soms krijg je een definitief antwoord, en op andere momenten blijft het probleem open en wordt het gelabeld met wat informatie die het categoriseert. Vervolgens kan de ontwikkelaar hiernaar teruggaan om het probleem op te lossen of de codebasis te verbeteren met uw feedback.

De meeste ontwikkelaars worden niet betaald om hun code te ondersteunen die op GitHub is vrijgegeven, dus je kunt geen snelle antwoorden verwachten. Maar sommige open source-opslagplaatsen worden uitgegeven door bedrijven die diensten rond die code aanbieden, commerciële aanbiedingen hebben voor versies met meer functies of een op plug-ins gebaseerde architectuur gebruiken. En dus hebben ze ontwikkelaars betaald die aan het open source project werken.

Sociale codering

Afbeelding tegoed: https://octodex.github.com

Een paar jaar geleden bevatte het GitHub-logo de slogan 'sociale codering'.

Wat betekende dit en is dat nog steeds relevant? Dat is het zeker.

Volgen

Met GitHub kun je een ontwikkelaar of repository volgen door naar het profiel van de gebruiker te gaan en op "volgen" te klikken of door op de knop "kijken" te klikken in een repo.

In beide gevallen wordt de activiteit weergegeven in uw dashboard. Het volgen van een gebruiker of repository is anders dan Twitter, waar u ziet wat mensen zeggen - in plaats daarvan ziet u wat mensen doen.

Stars

Een groot kenmerk van GitHub is de mogelijkheid om een ​​repository een ster te geven. Met deze actie wordt deze opgenomen in uw lijst met sterrepository's, waarmee u projecten kunt volgen die u interessant vindt en vergelijkbare projecten kunt ontdekken.

Het is ook een van de belangrijkste beoordelingsmechanismen, want hoe meer sterren een repo heeft, hoe populairder en over het algemeen het is. Dit resulteert in een prominentere weergave in zoekresultaten.

Grote projecten kunnen tienduizenden sterren hebben.

GitHub heeft ook een trendingpagina met de repository's die de meeste sterren binnen een bepaalde periode krijgen (bijvoorbeeld vandaag of deze week of deze maand).

Als u zich op deze populaire lijsten begeeft, kan dit andere netwerkeffecten veroorzaken, zoals te zien zijn op andere sites, alleen omdat u meer zichtbaarheid hebt.

Vork

De laatste belangrijke netwerkindicator van een project is het aantal vorken.

Dit is de sleutel tot hoe GitHub werkt, omdat een vork de basis is van een Pull Request (PR), wat een wijzigingsvoorstel is. Een persoon kan je repository forceren, enkele wijzigingen aanbrengen en vervolgens een pull-verzoek maken om je te vragen die wijzigingen samen te voegen.

Soms vraagt ​​de persoon die een repository afsplitst je nooit om iets samen te voegen. Ze kunnen je repository forceren omdat ze je code leuk vonden en besloten er iets aan toe te voegen dat ze niet opnieuw in de oorspronkelijke repository willen samenvoegen. Een gebruiker kan ook een fout oplossen die specifiek voor hem was.

Populair = beter

Al met al zijn dat allemaal belangrijke indicatoren voor de populariteit van een project. Afgezien van de bovenstaande indicatoren, zijn de datum van de laatste vastlegging en de betrokkenheid van de auteur bij de issue-tracker nuttige aanwijzingen of u al dan niet op een bibliotheek of software moet vertrouwen.

Trek verzoeken

In de vorige sectie heb ik geïntroduceerd wat een Pull Request (PR) is. Om te herhalen, kan een persoon je repository forceren, enkele wijzigingen aanbrengen en vervolgens een pull-verzoek maken om je te vragen die wijzigingen samen te voegen.

Een project kan honderden PR's hebben, en het is over het algemeen het geval dat hoe populairder een project is, hoe meer PR's het heeft, zoals het React-project:

Zodra een persoon een pull-aanvraag indient, moet deze worden beoordeeld door de kernbeheerders van het project.

Afhankelijk van de reikwijdte van uw pull-verzoek (het aantal wijzigingen, het aantal dingen dat wordt beïnvloed door uw wijziging of de complexiteit van de aangeraakte code) heeft de beheerder mogelijk meer of minder tijd nodig om ervoor te zorgen dat uw wijzigingen compatibel zijn met het project.

Een project heeft mogelijk een duidelijke tijdlijn met wijzigingen die ze willen aanbrengen. De beheerder wil het misschien eenvoudig houden terwijl u een complexe architectuur in een pull-aanvraag introduceert.

Dit wil zeggen dat een pull-aanvraag niet altijd snel wordt geaccepteerd en er is geen garantie dat de pull-aanvraag ooit wordt geaccepteerd.

In het voorbeeld dat ik hierboven heb gepost, is er een pull-verzoek in de repo dat dateert van 1,5 jaar geleden. En dit gebeurt in alle projecten - het is heel normaal en kan te wijten zijn aan de redenen die ik hierboven heb genoemd.

Project management

Naast problemen, waar ontwikkelaars feedback van gebruikers krijgen, biedt de GitHub-interface andere functies die erop gericht zijn enkele projectbeheerfuncties te bieden.

Een daarvan is Projects. Het is erg nieuw in het ecosysteem en zeer zelden gebruikt, maar het is een Kanban-bord dat helpt bij het organiseren van problemen en werk dat moet worden gedaan.

De Wiki is bedoeld als documentatie voor gebruikers. Een van de meest indrukwekkende toepassingen van de Wiki die ik tot nu toe heb gezien, is de Go Programming Language GitHub Wiki.

Een ander populair hulpmiddel voor projectmanagement zijn mijlpalen. Het maakt deel uit van de problemenpagina en u kunt problemen toewijzen aan specifieke mijlpalen, dit kunnen releasetargets zijn.

Over releases gesproken, GitHub verbeterde de Git-tagfunctionaliteit door releases te introduceren.

Een Git-tag is een pointer naar een specifieke commit, en indien consistent gedaan, helpt het je terug te keren naar de vorige versie van je code zonder te verwijzen naar specifieke commits.

Een GitHub-release is gebaseerd op Git-tags en vertegenwoordigt een volledige release van uw code, samen met Zip-bestanden, release-opmerkingen en binaire activa die mogelijk een volledig werkende versie van het eindproduct van uw code vertegenwoordigen.

Hoewel een Git-tag programmatisch kan worden gemaakt (bijvoorbeeld met behulp van het opdrachtregel git-programma), is het maken van een GitHub-release een handmatig proces dat gebeurt via de GitHub UI. Je vertelt GitHub in feite om een ​​nieuwe release te maken en hen te vertellen op welke tag je die release wilt toepassen.

Commits vergelijken

GitHub biedt veel tools om met uw code te werken.

Een van de belangrijkste dingen die u misschien wilt doen, is de ene tak met de andere vergelijken. Of misschien wil je de nieuwste commit vergelijken met de versie die je momenteel gebruikt om te zien welke wijzigingen in de loop van de tijd zijn aangebracht.

Met GitHub kun je dit doen met de vergelijkingsweergave: voeg gewoon toe / vergelijk aan het einde van de reponaam.

Bijvoorbeeld https://github.com/facebook/react/compare

In de onderstaande afbeelding vergelijk ik de nieuwste React v15.x met de nieuwste versie v16.0.0-rc die op het moment van dit schrijven beschikbaar was om te zien wat er is gewijzigd.

Deze weergave toont de commits die zijn aangebracht tussen twee releases (of tags of commitsreferenties) die zijn gewijzigd, en de feitelijke diff, als het aantal wijzigingen lager is dan een redelijk bedrag.

Webhooks en services

GitHub biedt vele functies die de workflow van ontwikkelaars helpen, zoals webhooks en services.

webhooks

Met Webhooks kunnen externe services worden gepingd wanneer bepaalde gebeurtenissen in de repository plaatsvinden, bijvoorbeeld wanneer code wordt gepusht, een vork wordt gemaakt of een tag wordt gemaakt of verwijderd.

Wanneer een gebeurtenis plaatsvindt, verzendt GitHub een POST-verzoek naar de URL waarvan we zeggen dat deze moet worden gebruikt.

Een veelgebruikt gebruik van deze functie is om een ​​externe server te pingen om de nieuwste code van GitHub op te halen wanneer we een update van onze lokale computer pushen.

We pushen naar GitHub, GitHub vertelt de server die we gepusht hebben en de server haalt uit GitHub.

Diensten

GitHub-services en de nieuwe GitHub-apps zijn integraties van derden die de ontwikkelaarservaring verbeteren of u een service bieden.

U kunt bijvoorbeeld een testloper instellen om de tests automatisch uit te voeren telkens wanneer u enkele nieuwe commits pusht, met behulp van TravisCI.

U kunt Continuous Integration instellen met CircleCI.

U kunt een Codeclimate-integratie maken die de code analyseert en een rapport van 'Technische schuld' en testdekking biedt.

Laatste woorden

GitHub is een geweldige tool en service om van te profiteren, een echt pareltje in de huidige toolset voor ontwikkelaars. Deze zelfstudie helpt je op weg, maar de echte ervaring met werken aan open source (of closed source) -projecten van GitHub is iets dat je niet mag missen.

Wilt u JavaScript leren? Ontvang mijn gratis ebook op jshandbook.com