Ostatnio napisałem kilka postów dotyczących wykorzystania biblioteki SignalR w moim projekcie. Opisywałem tam, jak dodać obsługę SignalR po stronie klienta napisanego we frameworku Angular. W tym celu wykorzystałem bibliotekę ng2-signalr. Podczas pracy z nią zauważyłem, że autor nie dodał jednej funkcjonalności, a dokładnie możliwości wyboru kanału transportu. Zagłębiłem się więc w kod źródłowy i zacząłem działać…
Mój pierwszy pull request
Każdy kto zna stronę GitHub, wie że służy ona do przetrzymywania kodu źródłowego projektów, ale nie tylko. Możemy tam za darmo hostować strony internetowe znajdujące się tam w repozytorium. Projekty mogą być publicznie widoczne dla każdego, lub prywatne (płatna opcja). Twórcy wielu bibliotek trzymają tam swój kod. Nie tylko możemy go przeglądać, ale także dokonywać w nich zmian, oczywiście za zgodą autora. Jak już wcześniej wspomniałem, sam znalazłem się w sytuacji, gdzie potrzebowałem drobnej modyfikacji. Zrobiłem ją na szybko w kopii biblioteki lokalnie, ale stwierdziłem, że nie potrwa to za długo żeby zrobić to jak należy. Nie będę rozpisywał się nad tym co dokładnie zrobiłem. Kto jest ciekawy, niech poczyta o tym tutaj.
Pull request na stronie GitHub.com
Niektórzy być może na co dzień pracują z pull requestami w pracy. Sam do takich osób nie należę, dlatego musiałem sprawdzić samemu jak to działa. A jest to bardzo proste. Zaczynamy oczywiście od wyboru projektu w którym chcemy dokonać zmiany. Następnie klikamy na przycisk Fork.
Dzięki temu dodana zostanie nasza kopia repozytorium. To w niej będziemy dokonywać zmian. Istnieje także drugi typ takiej pracy, gdzie jesteśmy współtwórcami repozytorium. Wtedy możemy dodać nasz branch i dodać pull request do zmian zawartych w nim. Tak jak tutaj pokazuje jest jednak łatwiej, ponieważ nie musimy posiadać żadnych uprawnień do repozytorium. Na naszym profilu GitHub widać że zrobiliśmy forka repozytorium.
Następnym krokiem będzie dokonanie odpowiednich zmian w kodzie. Można to zrobić online z poziomu GitHuba. W przypadku poprawek dokumentacji może i tak zrobilibyśmy, ale w naszym przypadku zmian dokonywać będziemy lokalnie z wykorzystaniem naszego ulubionego IDE. Ten krok pominę, bo to co zmienimy zależy od projektu. Następnie robimy commit naszych zmian. Gdy już je zapiszemy, możemy wysłać pull request, czyli dajemy informację autorowi o tym, że dokonaliśmy poprawek i są gotowe do pobrania.
Autor sprawdza co zrobiliśmy i akceptuje zmiany, lub zwraca nam je do poprawki. Jeżeli musimy poprawić część kodu, wystarczy później ją zapisać w naszym branchu. GitHub automatycznie zaktualizuje nasz pull request. Voila, gotowe. Nasze zmiany zostały przyjęte i są dostępne dla innych.
Po co mam robić cudzy projekt?
Niektórzy być może zadają sobie takie pytanie. Wymienię moim zdaniem kilka najbardziej oczywistych. Być może nie każdego to przekona, ale warto spróbować.
Dla spokoju w projekcie. Jeżeli korzystamy z biblioteki i musimy zrobić w niej jakąś poprawkę, najszybciej będzie zrobić kopię kodu źródłowego i dodać ją do naszego projektu. Nie musi to być poprawka zrobiona najlepiej jak się da. Wiadomo, ważne żeby działało. Wadą tego rozwiązania jest to, że jeżeli biblioteka otrzyma inne poprawki, które będziemy chcieli mieć w naszym projekcie, nasza poprawka będzie musiała zostać dodana na nowo. Pozornie łatwiejsza zmiana będzie niosła ze sobą więcej pracy w przyszłości. Naturalnie możemy liczyć na to, że ktoś inny dokona tych poprawek. Wiadomo jednak że najlepiej liczyć zawsze na siebie…
Dla satysfakcji. Tutaj bardzo obiektywna sprawa, ale mi bardzo wiele radości sprawia myśl, że mogę dodać zmiany z których inni będą korzystać. Wielu programistów ma to samo, ten moment gdy coś działa® i my to dodaliśmy. Mimo wielu lat, dalej jest to dla mnie coś bardzo przyjemnego, polecam.
Dla własnych korzyści. Dodanie w CV że aktywnie działamy podczas rozwoju kilku projektów typu open source to może być wielki plus w oczach pracodawcy. Ten punkt jest głównie dla programistów z mniejszym stażem, którzy w ten sposób mogą zapełnić swoje skromne CV. Łatwo pokazać w ten sposób że potrafimy coś zrobić i wiemy więcej niż uczą tylko na studiach. Doświadczeni programiści także mogą czerpać z tego korzyści, aktywny udział w dużych projektach i nie tylko może odróżnić nas od konkurencji na rynku.
Podsumowanie
Żałuję, że dopiero teraz udało mi się zrobić mój pierwszy wkład w projekty tego typu. Następnym razem, gdy będę korzystał z biblioteki w której będzie jakiś problem, poświęcę chwilę na sprawdzenie czy poprawka mojego problemu to duży problem. Może jednak dodanie jej własnoręcznie będzie lepsze niż szukanie obejścia problemu w internecie? Zachęcam Was do tego samego, w końcu na co dzień wszyscy korzystamy z bibliotek na które ktoś inny poświęcił swój czas. Może warto poświęcić trochę naszego?