Share
Als je dat nog niet weet, is GitHub een ongelooflijk effectieve manier om samen te werken aan ontwikkelingsprojecten. Een plek bieden voor iedereen met een internetverbinding om een weg te vinden waar ze gratis code met de wereld kunnen delen (om nog te zwijgen over de robuuste ondersteunende hulpmiddelen voor broninspectie en het gemakkelijk bekijken van commit-geschiedenissen). GitHub is door veel grote open-sourceprojecten aangenomen als hun primaire thuis voor samenwerking en bijdrage.
Maar hoe doe je mee en draag je bij aan een project? Natuurlijk weet u hoe u Git moet gebruiken om wijzigingen in bestanden bij te houden en die bestanden naar een server te pushen. Maar er zijn grote voordelen verbonden aan grotere open-sourceprojecten en GitHub is waarschijnlijk de beste plaats om te beginnen. Vandaag bespreken we enkele regels van de weg om samen te werken aan open source-projecten en geven we je de kennis en intuïtie die je nodig hebt om mee te doen.
Wees niet bang om klein te beginnen
Een van de belangrijkste dingen om te begrijpen wanneer u aan de slag gaat met samenwerking bij open-sourceprojecten, is uw rol te herkennen. Vaak zijn er tal van dingen die je als ontwikkelaar kunt doen die geen extreem slimme programmeur hoeft te zijn. In feite is angst om een ontoereikende programmeur te zijn vaak een reden waarom mensen niet in eerste instantie betrokken worden bij open source-projecten. Wees niet bang om klein te beginnen: in plaats van een grote bug te repareren of een hele module te herschrijven, probeer dan dingen te vinden zoals documentatie-tekortkomingen of testen en patching over verschillende apparaten, of zelfs eenvoudige syntaxisfouten en grammatica-problemen (zoals deze van GitHub-gebruiker mzgol).
Dit soort taken zijn een goede manier om je voet tussen de deur te krijgen als een bijdrager aan het project zonder dat je probeert meer te doen dan je aankan. Meld je aan voor CodeTriage om geautomatiseerde GitHub-problemen te ontvangen die naar je inbox zijn verzonden. Als je in je inbox komt, voel je je zelfverzekerd, neem je het op, werk je eraan en stuur je een pull-aanvraag. (We zullen het hebben over hoe je dat wat verder in de post kunt doen.)
Bij elke samenwerkingsinspanning is waarschijnlijk een reeks conventies aangenomen. Dit kan een vocabulaire omvatten, een manier om commit-berichten bij te dragen en te formatteren, een bepaald ritme van samenwerken waar de contribuanten mee hebben ingestemd, of zelfs syntactische standaarden die zijn vastgesteld. Voordat je met een project begint te werken, lees alle documenten met betrekking tot deze dingen. GitHub heeft bijvoorbeeld een a gestandaardiseerd CONTRIBUTING.md bestand (bekijk de richtlijnen voor betrokkenheid bij jQuery voor een goed voorbeeld). Deze gidsen worden onderhouden door de mensen die ook de codebase en de hoofdtak.
Een andere manier om het ecosysteem van een project te begrijpen, is door simpelweg te kijken naar de bestaande codebase en de git log. Het lezen van de commit-berichten en het doorlezen van de codestijl kan u veel vertellen over een project. Lees de documentatie van het project door en gebruik het gebruikte vocabulaire zodat uw bijdragen de continuïteit behouden en een vergelijkbare stem uitbeelden.
Als je eenmaal deel uitmaakt van het culturele ecosysteem van het project, hoe doe je dat dan eigenlijk? code toevoegen?
De workflow voor het leveren van code kan in eerste instantie ontmoedigend lijken.
De workflow voor het leveren van code kan in eerste instantie ontmoedigend lijken. Het belangrijkste om te onthouden is om de patronen en standaarden te volgen die worden geschetst door het project waaraan u werkt (zoals we al hebben besproken). De algemene workflow die GitHub ondersteunt, is vrij eenvoudig.
Binnen deze workflow ziet u mogelijk veel variaties voor een bepaald project. De naamgevingsconventies voor onderwerpstakken variëren bijvoorbeeld. Sommige projecten gebruiken conventies zoals bug_345, waarbij 345 het ID # van een GitHub-probleem is dat is gearchiveerd. Sommige projecten geven de voorkeur aan kortere commit-berichten dan andere. Hier is een reeks opdrachten waarmee de bovenstaande workflow wordt voltooid.
Vork de repo op GitHub.com
Kloon de repo met behulp van de URL in de rechterzijbalk:
git clone [email protected]: jcutrell / jquery.git
Ga naar de gekloonde directory en dan kun je op dit punt de upstream-afstandsbediening toevoegen:
cd jQuery git remote add upstream [email protected]: jQuery / jquery.git
Hiermee kun je nu lokaal wijzigingen aanbrengen in de bron en deze samenvoegen, zoals het volgende:
git fetch upstream git merge upstream / master
Voordat u echter uw eigen wijzigingen aanbrengt, kunt u een onderwerpstak uitchecken:
git checkout -b enhancement_345
Nu kunt u uw wijzigingen aanbrengen en een commit maken die volgt alleen die veranderingen.
git commit -am "voegt een smileyface toe aan de documentatie."
Vervolgens zul je deze topic-tak naar je eigen vork van het project duwen.
git push origin enhancment_345
Ten slotte maakt u een pull-aanvraag. Ga eerst naar je vork van de repo. Mogelijk ziet u een "uw recent gepushte takken", en als dat zo is, kun je kiezen "Vergelijk en trek aanvraag". Anders kunt u uw branche selecteren in de vervolgkeuzelijst en vervolgens klikken "Pull Request" of "Vergelijken" in de rechterbovenhoek van de repo-sectie.
Met elk van deze gaat u naar een pagina waar u een pull-aanvraag kunt maken en een reactie op de aanvraag kunt geven. Deze pagina bevat ook een visualisatie van de aangebrachte wijzigingen. Dit maakt het voor de projectbeheerder gemakkelijk om te zien wat u hebt gedaan en om gemakkelijker beslissingen te nemen over de vraag of het passend is om uw commit samen te voegen. Als ze vragen hebben, kunnen ze hen in de opmerkingen vragen; ze kunnen je ook vragen om je pull-aanvraag op te schonen en opnieuw in te dienen en vervolgens het pull-verzoek te sluiten.
Merk op dat het ongelooflijk belangrijk is dat u de beheerders van een project volledig respecteert; je kunt immers altijd je gevorkte versie van de code gebruiken en als ze ervoor kiezen je wijzigingen niet in te voeren, komt dat omdat ze de juiste positie hebben om dat te doen. Onthoud, volgens Github Employee Zach Holman's inleiding "Hoe GitHub GitHub gebruikt om GitHub te bouwen", pull-requests zijn gesprekken. Dit is hoe ze moeten worden behandeld; in plaats van te verwachten dat je commit wordt geaccepteerd, kun je alleen verwachten dat het een gesprek opent over de code die je hebt geschreven.
GitHub biedt GitHub-problemen, wat een robuuste manier is om gedocumenteerde, interactieve, geautomatiseerde gesprekken over bugs of functies voor een bepaald project te creëren. Hoewel Issues kunnen worden uitgeschakeld, zijn ze standaard ingeschakeld. Er zijn veel geweldige functies waarmee Issues is ingebouwd, maar een van de belangrijkste functies is de integratie met pull-aanvragen. Een gebruiker kan verwijzen naar een probleem in hun commit-bericht door simpelweg de numerieke ID van het probleem in het commit-bericht op te nemen. Bijvoorbeeld:
git commit -am "Een header toevoegen, fixes # 3"
Dit commit-bericht markeert automatisch nummer # 3 als gesloten wanneer het bijbehorende pull-verzoek wordt geaccepteerd. Dit soort automatisering maakt GitHub een geweldige tool voor projectmanagement van projecten.
Grote open-sourceprojecten profiteren vaak van veel verschillende soorten samenwerkingswerk.
Laat je niet verleiden door te denken dat de enige manier waarop je een bijdrage kunt leveren, is door pull-verzoeken. Grote open-sourceprojecten profiteren vaak van veel verschillende soorten samenwerkingswerk. Een project als Ruby on Rails was bijvoorbeeld berucht om zijn gemeenschap; deze community beantwoordt vragen op fora en in IRC-chatrooms om te helpen kennis op te bouwen over het raamwerk, en zou ook helpen de richting van het raamwerk in de toekomst te bepalen door te praten over ideeën en bugs bloot te leggen.
Deze samenwerkingskanalen worden meestal geopend als ondersteunende omgevingen zoals eerder genoemd, zoals fora en chatrooms. Er kunnen ook e-mailketens, bijeenkomsten of telefonische vergaderingen zijn die de richting van het project helpen bepalen en een levendige, productieve gemeenschap rond het project creëren. Zonder dit soort community zijn pull-aanvragen veel minder effectief.
Onthoud dat open source wordt gedreven door mensen die de attitude hebben dat het delen van kennis en het opbouwen van collaborative intelligence een lonend streven is. Je betrokkenheid bij deze projecten zal het meest effectief zijn als je een bepaald project benadert met de nieuwsgierige houding die vraagt "hoe kan ik helpen?" in plaats van een gesloten houding die zegt: "Ik ga helpen hoe ik wil." Mensen in de open-source wereld willen werken met mensen die oprecht gedreven zijn om anderen te helpen.
Als u geïnteresseerd bent om deel te nemen aan een open source project, geweldig! Onthoud dat als u het project met de juiste instelling benadert en klein begint, u uw naam op pull-aanvragen kunt zien die is samengevoegd in code die wordt verspreid onder mensen over de hele wereld en die elke dag wordt gebruikt. Neem de tijd om meer te weten te komen over het project en de mensen die betrokken zijn bij het project. Ontwikkel oprechte interesse om het project beter te laten worden. De kracht van GitHub en de open-source wereld blijft elke dag groeien; begin samen te werken met andere ontwikkelaars en je kunt een deel van die wereld zijn!
Accentsconagua