Polub bloga na fejsie!

Jak zostać kontrybutorem open-source na GitHubie

2

W wielu moich wpisach, m.in. tych poradnikowych dla Junior Developerów wspominałem, że jeśli chcesz zrobić dobre wrażenie na pracodawcy to warto zostać kontrybutorem open-source. Ostatnio pochwaliłem się też moim własnym wkładem w otwarty kod za sprawą mojego komponentu do autoryzacji react-routera. Podejrzewam, że wielu z moich czytelników miałoby chęć mieć swój wkład w wolne oprogramowanie. Dlatego też dziś postanowiłem pokazać Ci jak to zrobić. Przedstawię to w kontekście GitHuba, czyli najpopularniejszego obecnie serwisu pozwalającego darmowo hostować projekty open-source.

Dlaczego warto?

Zanim przejdę do omawiania zasad „commitowania” kodu do GitHuba myślę, że warto napisać kilka słów dlaczego warto w ogóle to robić. Trochę już na ten temat pisałem w różnych wpisach ale myślę, że takie zebranie tego w jednym miejscu to dobry pomysł.

#1 – portfolio

No więc po pierwsze, dobrze wyglądający profil GitHub to coś czym można i warto się pochwalić w swoim CV. Zresztą, jeśli przeglądasz oferty pracy to pewnie zauważyłeś, że pracodawcy często proszą o podanie linku do Twojego profilu na GitHubie. Taka prośba często występuje razem z prośbą o link do portfolio. Twoje „commity” w GitHubie stanowią bowiem swoiste programistyczne portfolio Twoich umiejętności. Pokazują jakość kodu jaki tworzysz, a także to, że jesteś pasjonatem…

Dlatego też, moim zdaniem, warto mieć taki profil i zadbać o to aby nie był pusty. Z jednej strony warto mieć tam swoje własne projekty ale jeśli będziesz kontrybuować do jakichś zewnętrznych, być może bardziej nawet znanych projektów to będą to dla Ciebie napewno dodatkowe plusy do „zajebistości”!

#2 – możliwość nauki

Druga sprawa to możliwość nauki. Z jednej strony GitHub oparty jest, jak sama nazwa wskazuje, na rozproszonym systemie kontroli wersji Git. Oczywistym jest więc, że aby coś na niego wrzucić musisz wiedzieć mniej więcej jak z niego korzystać. Poza tym, kiedy dodajesz Pull Request do zewnętrznego projektu, Twój kod zostanie gruntownie sprawdzony przez autorów projektu. Oprócz sprawdzenia Twojej propozycji rozwiązania jakiegoś problemu, zostanie on też przejrzany pod kątem zasad „code style” panujących w projekcie, dobrych praktyk itp. Jest to więc w zasadzie takie typowe „code review”. A jak wiadomo (pisałem o tym w moim wpisie na temat przeglądów kodu), napewno warto je praktykować!

przegląd pull request

Ponadto, wiele projektów zawiera też testy jednostkowe. Jeśli dodajesz coś nowego, to po pierwsze wszystkie dotychczasowe testy muszą nadal przechodzić, a po drugie być może będziesz musiał dopisać własne… Jak więc widzisz, jest tutaj sporo okazji do nauki i rozwinięcia swoich programistycznych umiejętności!

#3 – satysfakcja

Trzecią rzeczą wynikającą z bycia kontrybutorem open-source jest satysfakcja z robienia rzeczy, które mają znaczenie i są wykorzystywane przez innych! Zapewne nie dla każdego jest to istotne ale wiem, że dla wielu osób jest to „sól programowania”. Świadomość tego, że oprogramowanie do którego stworzenia się przyczyniłeś jest przydatne dla innych może świetnie napędzać do dalszego rozwoju

Podsumowując więc, jeśli Twoja obecna praca jest nudna i nie masz z niej satysfakcji to może warto po godzinach zająć się jakimś projektem open-source? Choćby po to, żeby przetrwać ten trudno okres?

Jak zostać kontrybutorem open-source na GitHubie?

Ok, skoro wiemy już dlaczego warto zostać kontrybutorem open-source, czas teraz pokazać jak do tego podejść na GitHubie….

Zanim jednak przejdziemy do technikaliów, przedstawię najpierw jak wybrać projekt, do którego będziemy „commitować”.

Jak wybrać projekt?

Najlepiej by było gdybyś zajął się kontrybucją do projektu, którego używasz na codzień. Najłatwiej wtedy o pomysły na zmiany i usprawnienia. Przecież pracując jako Front-end Developerzy bardzo często wykorzystujemy jakieś biblioteki, które pobieramy z npm (zwykle ich kod źródłowy znajduje się właśnie na GitHubie). Często zdarza się też, że biblioteka taka zawiera jakiś błąd lub brakuje w niej jakiejś przydatnej dla nas funkcjonalności. Jest to dobra okazja, aby dorzucić swoje trzy grosze do takiej biblioteki!

Jeśli jednak akurat nie masz żadnego problemu z używanymi bibliotekami lub zwyczajnie chciałbyś „podłubać” przy czymś innym możesz sobie po prostu poszukać projektu. GitHub dostarcza bowiem fajne narzędzie do wyszukiwania projektów. Jest ono dostępne pod tym adresem i umożliwia przeglądanie repozytoriów pogrupowanych według tematów. Myślę, że jest to dobry sposób by znaleźć coś ciekawego dla siebie.

Jak zacząć?

Zanim zaczniesz cokolwiek robić w danym projekcie, warto sprawdzić czy jego autorzy nie dostarczyli jakichś wskazówek i informacji jak się do tego zabrać!

POLUB BLOGA NA FACEBOOKU!

Chcesz być na bieżąco informowany o nowościach na blogu oraz innych ciekawych treściach? Polub fanpage bloga na Facebooku!

Po pierwsze przeczytaj plik README.md – wyświetla się on domyślnie po wejściu na dane repozytorium. Zwykle zawiera on informacje przede wszystkim na temat tego, jak korzystać z danej biblioteki/narzędzia. Może on jednak zawierać też przydatne informacje dla developerów. Na przykład dostępne komendy do odpalania „builda” czy testów.

Drugim plikiem jakiego należy szukać jeśli chcesz popracować nad danym projektem jest CONTRIBUTING.md. Są w nim zwykle zawarte najważniejsze informacje o zasadach kontrybucji. Jeśli więc plik ten został dodany do projektu to zapewne zawiera wszystko co trzeba wiedzieć przed rozpoczęciem pracy.

contributing

Duże projekty, takie jak na przykład redux, mogą posiadać dużo bardziej rozbudowaną dokumentację. Zwykle znajduje się ona w katalogu docs projektu. Czasem jednak może ona być umieszczona w osobnej domenie. Nie ważne jednak w jaki sposób jest ona dostarczana. Ważne, że może ona również zawierać jakieś wskazówki dotyczące kontrybucji w projekcie! Warto więc przejrzeć ją pod tym kątem.

Dwa rodzaje kontrybucji

Tak na prawdę, możemy na dwa sposoby wnieść wartość do projektów open-source na GitHubie:

  • Zgłaszanie błędów, propozycji, pytań – tak, w ten sposób również możemy zostać kontrybutorem bez napisania choćby linii kodu…
  • Pull Requesty – sposób najbardziej oczywisty, polegający na wprowadzaniu zmian lub naprawie błędów w projekcie

Poniżej znajdziesz więcej na temat obu tych sposobów kontrybucji.

Zgłaszanie błędów, propozycji, pytań

Jak wspomniałem, dzięki zgłaszaniu błędów również można zostać kontrybutorem open-source! Jeśli znalazłeś błąd w danym projekcie wystarczy, że zgłosisz to za pomocą specjalnego formularza. Aby to zrobić musisz przejść do zakładki Issues dostępnej na głównej stronie projektu na GitHubie. Jest tam zielony guzik „New issue”

Zresztą to nie musi być tylko „bug”. Za pomocą Issues możesz też zgłaszać propozycje zmian oraz zadawać pytania społeczności zebranej wokół danego projektu. Jeśli chcesz przeczytać więcej na temat Issues to wszystko co trzeba znajdziesz w tym artykule.

Warto jednak pamiętać o kilku podstawowych zasadach przy dodawaniu Issues (no chyba, że plik CONTRIBUTIONS.md mówi inaczej):

  • sprawdź czy nie zgłaszasz duplikatu (być może ktoś już zgłosił Twój problem?)
  • pisz możliwie jasno, dołącz przykłady kodu (możesz dodać link do jsfidde), generalnie zadbaj o to aby być dobrze zrozumianym
  • jeśli masz możliwość dołącz też logi błędów lub screenshoty

Pull Requesty

Myślę, że jest to najbardziej oczywisty sposób kontrybucji do GitHuba. Jeśli tylko chcesz, możesz spróbować zająć się którymś ze zgłoszonych Issues lub, jeśli masz własną propozycję zmian, zaproponować ją od razu jako Pull Request!

Jak zacząć wprowadzać zmiany

Tutaj również należy się stosować do zaleceń zamieszczonych we wspomnianych dokumentach projektu. Oprócz tego istnieją ogólne zasady, których należy się trzymać. Aby więc rozpocząć prace nad zmianą w projekcie lub naprawą błędu:

  • Najpierw utwórz „forka” projektu (czyli kopię danego projektu we własnym profilu)
  • Następnie sklonuj lokalnie tę „zforkowaną” wersję
  • Jako „remote” dla swojego lokalnego klona, ustaw oryginalny „upstream” – tutaj szczegóły jak to zrobić
  • Często synchronizuj „forka” ze zdalną, oryginalną wersją projektu (jeśli trzeba rób „merge”) – więcej tutaj
  • Utwórz branch dla swojej zmiany i na niej pracuj
  • Pamiętaj o testach jednostkowych (istniejące nadal muszą przechodzić, a jeśli dodajesz funkcjonalność to może wymaga ona testów?)
  • Twórz kod zgodny z „code style” projektu (wcięcia, odstęp, nawiasy klamrowe itp.)

Zgłoszenie Pull Requesta

Kiedy masz już gotowe swoje zmiany, czas zgłosić Pull Request! Jeśli często synchronizowałeś i „mergowałeś” do siebie zmiany w oryginalnym źródle to nie powinno być problemów. Wystarczy teraz, z poziomu widoku „brancha” (w GitHubie), na którym pracowałeś wybrać guzik „New Pull Request”. Pojawi się okno, w którym po lewej wskazujesz bazowy projekt (branch master), a po prawej swojego „forka” (i branch, z którego chcesz puścić zmiany). Przy tworzeniu Pull Requesta, musisz też podać jego odpowiedni opis gdzie napiszesz co zmieniłeś i dlaczego. Opis powininen spełniać poniższe warunki:

  • Opisz dokładnie i precyzyjnie dlaczego chcesz wprowadzić zmianę
  • Przedstaw też w jaki sposób rozwiązałeś dany problem
  • Jeśli zmieniałeś HTML/CSS, możesz dorzucić screenshot przedstawiający różnicę w wyglądzie przed i po Twoich zmianach

Kiedy zgłosisz Pull Request, rozpocznie się dyskusja. Osoby, które utrzymują projekt ale też inne osoby zainteresowane projektem mogą mieć do Ciebie pytania, na które staraj się jak najlepiej odpowiadać. Dyskusja ta może zakończyć się wciągnięciem Twojego Pull Requesta do projektu lub też dostaniesz jakieś uwagi do poprawy. Może się też zdarzyć, że Twoje rozwiązanie będzie kompletnie nieakceptowalne dla autorów projektu. Jeśli więc planujesz wprowadzić jakieś grube zmiany to myślę, że lepiej będzie najpierw zgłosić Issue, w którym przedstawisz swoją propozycję. Dzięki temu upewnisz się wcześniej, że Twój pomysł ma rację bytu…

Podsumowanie

Jak widzisz, wcale nie jest trudno zostać kontrybutorem open-source na GitHubie! Myślę, że jest to świetna opcja dla osób, które chcą pokazać swoje umiejętności przyszłym pracodawcom, zabić nudę spowodowaną pracą w nieciekawym projekcie lub po prostu chcących się rozwinąć.

Mam nadzieję, że ten poradnik będzie dla Ciebie przydatny kiedy będziesz chciał zgłosić „Issue” lub „Pull Request” do jakiegoś dostępnego na GitHubie projektu. Myślę, że warto spróbować swoich sił – satysfakcja jest ogromna kiedy nasza zmiana zostanie zaakceptowana!

REACT, REDUX, REACT-ROUTER - KURSY ON-LINE

Chcesz od podstaw poznać tajniki React, Redux oraz react-router? Zapraszam do moich szkoleń on-line:

Przejdź do szkoleń

Uwaga! Obecnie trwa przedsprzedaż kursów - premiera 1 sierpnia 2017!

  • Dobry wpis dla każdego początkującego. Niemniej jednak, największym problemem jest zawsze znalezienie projektu do którego można dorzucić swoje 3 grosze. Z moich obserwacji wynika, że junior dev bardzo rzadko będzie się udzielał poprzez tworzenie issues bądź PR do repozytorium, bo się boi o zbyt małą własną wiedzę o kodowaniu lub po prostu uważa, że to nie jego problem.
    Taka mała dygresja odnośnie częstej synchronizacji forka. To nie jest niezbędne. Tworząc forka posiadamy referencję do własnego repozytorium i do repozytorium sforkowanego. Wystarczy przy tworzeniu nowego brancha zawsze robić branch z tak zwanego mastera głównego repozytorium. Wtedy master na forku nie musi być synchronizowany.

    • Dzięki za cenne uwagi! Oczywiście jeśli jesteś dobrze obeznany z gitem to będziesz pracować jak Ci wygodnie – tutaj opierałem się na zaleceniach GitHuba odnośnie pracy na forkach.
      To napewno prawda, że Junior będzie miał obawy jednak mam nadzieję, że tego typu wpisy chociaż parę osób ośmielą 😉

Google Analytics Alternative