Github przyjazny przewodnik peter bell

GitHub. Przyjazny przewodnik Peter Bell Brent Beer

O’REILLY™ Beijing • Cambridge • Farnham • Köln • Sebastopol • Tokyo

Tytuł oryginału: Introducing GitHub Tłumaczenie: Piotr Cieślak ISBN: ePub: 978-83-283-0504-5, mobi: 978-83-283-0505-2 © 2015 Helion S.A. Authorized Polish translation of the English edition of Introducing GitHub, ISBN 9781491949740 © 2015 Pragmatic Learning, Inc. This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same.

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from the Publisher.

Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji.

Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli.

Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne.

Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce.

Wydawnictwo HELION ul. Kościuszki 1c, 44-100 GLIWICE tel. 32 231 22 19, 32 230 98 63 e-mail: helion@helion.pl WWW: http://helion.pl (księgarnia internetowa, katalog książek) Drogi Czytelniku!

Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/github_ebook Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.

Poleć książkę Kup w wersji papierowej Oceń książkę

Księgarnia internetowa Lubię to! » nasza społeczność

Spis treści Przedmowa Do kogo jest adresowana ta książka?

Nie tylko kod Komu nie przyda się ta książka?

Jak korzystać z niniejszej książki?

Konwencje zastosowane w książce Podziękowania 1. Wstęp Czym jest Git? Czym jest GitHub? Dlaczego warto używać Gita?

Dlaczego warto używać GitHuba?

Najważniejsze pojęcia 2. Przeglądanie Zapoznanie się ze stroną projektu Wyświetlanie pliku README.md Przeglądanie historii zmian Wyświetlanie zgłoszeń Wyświetlanie problemów Wyświetlanie pulsu Wyświetlanie wykresów w GitHubie Wykres współpracowników Wykres zmian Wykres częstotliwości zmian w kodzie Wykres „karta perforowana” Wykres sieciowy Lista uczestników Wykres ruchu sieciowego 3. Edycja Udział w projekcie za pośrednictwem odgałęzień Dodawanie pliku Tworzenie zgłoszenia Edytowanie pliku Zmiana nazwy albo przenoszenie pliku Praca z folderami

Tworzenie folderu Zmiana nazwy folderu Ograniczenia edytowania w serwisie GitHub 4. Współpraca Wprowadzanie zmian w odgałęzieniu Tworzenie zgłoszenia z poziomu gałęzi Współpraca przy zgłoszeniach Zaangażowanie konkretnych osób w zgłoszenie Przeglądanie zgłoszeń Komentowanie zgłoszeń Uatrakcyjnianie komentarzy Modyfikowanie zgłoszeń Testowanie zgłoszenia Akceptowanie zgłoszenia Kto powinien akceptować zgłoszenia?

Powiadomienia o zgłoszeniach Zalecenia dotyczące zgłoszeń Problemy Definiowanie nowego problemu Zarządzanie kamieniami milowymi w ramach problemów Zarządzanie etykietami w ramach problemów Komentowanie problemów Odwoływanie się do problemów w zmianie Zalecenia dotyczące problemów Wiki Rozpoczęcie pracy z wiki Dodawanie stron do wiki i odwoływanie się do nich Informacyjne strony WWW w GitHubie Tworzenie strony internetowej dla projektu Tworzenie strony internetowej dla siebie albo dla organizacji 5. Tworzenie i konfigurowanie Tworzenie repozytorium Dodawanie współpracowników Konfigurowanie repozytorium Integracja z innymi systemami Repozytoria osobiste i repozytoria organizacji Tworzenie organizacji Zarządzanie zespołami 6. Pobieranie

Po co klonować repozytorium?

GitHub w wersji dla systemu Mac OS Przesyłanie zmian przy użyciu programu GitHub dla Mac OS-a Wyświetlanie zmian w programie GitHub dla Mac OS-a Program GitHub w wersji dla systemu Windows Przesyłanie zmian przy użyciu programu GitHub dla Windows Konfigurowanie narzędzi do obsługi Gita z poziomu wiersza poleceń systemu Windows 7. Kolejne kroki Skorowidz

Przedmowa GitHub zmienia sposób tworzenia oprogramowania. Serwis ten, pomyślany jako narzędzie ułatwiające programistom współpracę nad kodem open source, szybko staje się standardowym środowiskiem tworzenia aplikacji. Służy on nie tylko do przechowywania kodu źródłowego, ale jest także wyposażony w zaawansowane narzędzia umożliwiające definiowanie wymogów projektu, jak również omawianie i analizowanie aplikacji.

Do kogo jest adresowana ta książka?

Jeśli współpracujesz z programistami przy realizacji projektu aplikacji, to ta książka jest przeznaczona dla Ciebie. Możesz być: • Udziałowcem firmy, który chciałby nadzorować postępy nad projektem.

• Menedżerem produktu lub projektu chcącym mieć pewność, że program zostanie ukończony na czas i w ramach dostępnego budżetu.

• Projektantem odpowiedzialnym za dostarczenie różnych elementów, takich jak makiety lub kod HTML/CSS. • Copywriterem, którego zadanie polega na opracowywaniu tekstów reklamowych lub innych materiałów przeznaczonych do umieszczenia na stronie internetowej lub w aplikacji.

• Prawnikiem odpowiedzialnym za analizę różnych aspektów projektu pod względem legalności lub opracowanie warunków użytkowania bądź polityki prywatności.

• Członkiem zespołu chcącym analizować i komentować pracę na projektem, a także (lub) brać udział w jego rozwoju.

• Programistą, który wcześniej nie miał styczności z GitHubem i chciałby się dowiedzieć, w jaki sposób współpracować w zespole za pośrednictwem GitHuba.

Jeżeli zależy Ci na śledzeniu rozwoju programu — jeżeli chciałbyś mieć możliwość opiniowania postępów bądź wzięcia udziału we wdrażaniu zmian w projekcie, to z tej książki dowiesz się, jak efektywnie używać GitHuba w pracy zespołowej nad tworzeniem oprogramowania.

Nie tylko kod Choć GitHub jest wciąż stosowany głównie do pracy nad kodem, to można używać go z powodzeniem do realizacji innego rodzaju projektów zespołowych: począwszy od pisania książek (takich jak ta), przez rozpowszechnianie modeli do drukowania 3D, aż do opracowywania dokumentów natury prawnej. Każdy zespół pracujący nad pewnym zbiorem

dokumentów może rozważyć użycie GitHuba do zarządzania projektem. W przykładach opisanych w książce przyjęliśmy założenie, że pracujesz nad tworzeniem kodu, bo właśnie w tym celu GitHuba używa się najczęściej, przy czym zawarte w niej informacje są znakomitym źródłem wiedzy o użytkowaniu GitHuba niezależnie od tego, jakiego rodzaju projektami się zajmujesz.

Komu nie przyda się ta książka?

Niniejsza książka została opracowana z myślą o czytelnikach pragnących opanować podstawowe umiejętności niezbędne do efektywnego posługiwania się GitHubem. Jeśli wiesz już, na czym polega klonowanie, rozgałęzianie projektów, posługiwanie się gałęziami funkcji i zgłoszeniami, to zapewne nie dowiesz się z niej wiele nowego.

Nie jest to dobry wybór także dla tych, którzy szukają bardziej kompleksowego omówienia systemu kontroli wersji Git. W książce tej znajdziesz informacje wystarczające do rozpoczęcia pracy z GitHubem, jednak nie należy jej traktować jako zaawansowanego przewodnika po systemie Git. Czytelników zainteresowanych takimi zagadnieniami zachęcamy do zapoznania się ze znakomitą książką Jona Loeligera i Matthew McCullougha Kontrola wersji z systemem Git (Helion 2014).

Jak korzystać z niniejszej książki?

Staraliśmy się, by treść książki była tak przystępna, jak to tylko możliwe. Powinno dać się ją przeczytać stosunkowo szybko. Jeśli chciałbyś mieć pewność, że naprawdę wiesz, do czego służy GitHub i jak go używać, to zalecamy przeczytanie naszej książki od początku do końca.

Domyślamy się jednak, że masz mało czasu. Jeśli bardzo Ci się spieszy, zacznij od przekartkowania rozdziału 1. Rozdział ten stanowi krótki wstęp do Gita i GitHuba oraz wprowadza kilka istotnych pojęć, które warto znać, by ułatwić sobie przyswojenie pozostałej części książki. Potem zaś sięgnij do dowolnego rozdziału, który jest Ci w danej chwili potrzebny. Staraliśmy się napisać tę książkę tak, by każdy rozdział przedstawiał konkretny proces; lektura poszczególnych rozdziałów powinna więc pozwolić Ci na wykonanie zadania, które Cię w danej chwili interesuje.

Konwencje zastosowane w książce W tej książce zostały zastosowane następujące konwencje typograficzne: Kursywa Nowe pojęcia, adresy URL i e-mail, nazwy plików oraz rozszerzenia plików.

Czcionka o stałej szerokości

Instrukcje lub inny tekst, który powinien być wpisany dosłownie przez użytkownika.

Podziękowania Peter: Chcę podziękować żonie za wsparcie i wysiłek włożony w pracę nad tą książką, a także nad wieloma innymi projektami, które nie dość, że zabierają mi czas, jaki moglibyśmy spędzać wspólnie, to — na domiar złego — nie mają sekcji „Podziękowania”! Pragnę też podziękować swojej mamie za to, że zawsze dokładała wszelkich starań, by wspierać mnie w realizacji moich marzeń — nawet gdy wiatr wiał w oczy.

Brent: Pragnę podziękować swojej mamie za to, że tak usilnie zachęcała mnie do czytania — bez tego być może nigdy bym tego nie pokochał. Dziękuję także swojemu tacie. Gdybym nie mógł obserwować zza jego ramienia, jak pracuje na swoim komputerze, gdybym nie patrzył na przezabawną aplikację dla Mac OS-a z Oskarem z Ulicy Sezamkowej mieszkającym w koszu, gdyby nie zachęty ojca, bym uczył się programować, z pewnością dziś nie robiłbym tego, co robię.

Obaj chcielibyśmy podziękować Matthew i Jordanowi McCulloughom, jak również reszcie zespołu GitHuba za inspirację oraz opinie i uwagi na temat tej książki, a także za wszelkie pomysły i wieloletnie wsparcie. Najlepsze fragmenty tej publikacji to głównie ich zasługa.

Pragniemy też złożyć podziękowania na ręce niezrównanej Meg Blanchette z wydawnictwa O’Reilly, bez której ta książka nigdy nie zostałaby wymyślona, napisana i wydana. Bardzo dziękujemy, Meg!

Więcej na: www.ebook4all.pl

ROZDZIAŁ 1.

Wstęp Pierwszy rozdział zaczniemy od omówienia tego, czym są Git i GitHub, do czego służą, jakie są między nimi różnice i po co w ogóle ich używać. Potem wyjaśnimy kilka pojęć, które często padają w rozmowach na temat serwisu GitHub. Dzięki temu będziesz mógł łatwiej zrozumieć tematykę takich rozmów i brać w nich udział.

Czym jest Git? Git to system kontroli wersji. System kontroli wersji jest programem służącym do śledzenia zmian w plikach wraz z upływem czasu. Bardziej precyzyjnie rzecz ujmując, Git jest rozproszonym systemem kontroli wersji, co oznacza, że wszyscy pracujący nad projektem w repozytorium Gita dysponują kopią pełnej historii zmian projektu, a nie tylko aktualnymi plikami.

Czym jest GitHub? GitHub to serwis internetowy, do którego można wysyłać kopie repozytorium Gita. Ułatwia on współpracę między wszystkimi osobami zaangażowanymi w realizację projektu. Źródłem tych ułatwień jest wspólna, scentralizowana lokalizacja repozytorium, a także wygodny interfejs WWW do przeglądania go, wyposażony w funkcje umożliwiające tworzenie rozgałęzień projektu (forking), wysyłanie zgłoszeń (pull requests), obsługę problemów i zadań (issues) oraz tworzenie dokumentacji (wiki). Wszystkie te narzędzia pozwalają na efektywne wprowadzanie, omawianie i analizowanie zmian wspólnie z zespołem.

Dlaczego warto używać Gita?

Nawet jeśli pracujesz sam, a Twoja praca polega na edytowaniu plików tekstowych, to korzystanie z repozytorium Gita ma pewne zalety. Kilka spośród nich zostało wymienionych poniżej: Możliwość anulowania zmian Jeśli popełnisz błąd, możesz wrócić do wcześniejszego etapu projektu i odtworzyć jego starszą wersję.

Kompletna historia wszystkich zmian

Jeśli kiedykolwiek będziesz chciał sprawdzić, jak Twój projekt wyglądał dzień wcześniej, tydzień, miesiąc albo rok temu, możesz przejrzeć jedną z zapisanych wcześniej wersji, by zapoznać się z ówczesnym stanem poszczególnych plików.

Dostęp do dokumentacji uwzględniającej przyczyny wprowadzenia zmian Czasami trudno jest zapamiętać, dlaczego jakaś zmiana została wprowadzona. Dzięki komentarzom do zmian w Gicie można łatwo udokumentować przyczynę wprowadzenia danej zmiany, by móc zweryfikować ją w przyszłości.

Bezpieczne wprowadzanie zmian Ponieważ odtworzenie poprzedniej wersji projektu jest bardzo proste, masz gwarancję bezpieczeństwa przy wprowadzaniu dowolnych zmian. Jeśli coś nie zadziała, zawsze możesz wrócić do jednego z wcześniejszych etapów pracy.

Wiele strumieni historii Istnieje możliwość tworzenia rozgałęzień historii pozwalających sprawdzić różne przeróbki projektu albo tworzyć nowe funkcje w sposób niezależny od siebie. Takie funkcje, gdy będą już gotowe, można następnie scalić z zasadniczym projektem (jego główną gałęzią) lub usunąć, jeśli się okaże, że nie spełniają swojego zadania.

Podczas pracy w grupie korzystanie z Gita w celu śledzenia zmian w projekcie ma jeszcze więcej zalet. Oto najważniejsze korzyści wynikające z używania Gita w pracy zespołowej: Możliwość rozwiązywania konfliktów Dzięki Gitowi wiele osób może równocześnie pracować z jednym plikiem. Na ogół Git będzie w stanie automatycznie scalić wprowadzone zmiany, a jeśli się to nie uda, wskaże miejsca, w których doszło do konfliktów, a także ułatwi Ci ich rozwiązanie.

Niezależne strumienie historii Różne osoby biorące udział w projekcie mogą pracować na różnych gałęziach, co pozwala na niezależne przygotowywanie różnych funkcji i późniejsze scalanie ich, gdy będą gotowe.

Dlaczego warto używać GitHuba?

GitHub jest czymś więcej niż tylko miejscem do składowania repozytoriów Gita. Serwis ten zapewnia wiele innych korzyści, a wśród nich takie jak: Dokumentowanie wymogów projektowych Dzięki funkcji Issues (problemy) możesz dokumentować błędy albo opisywać nowe funkcje, które chciałbyś, aby zostały opracowane przez zespół.

Współpraca nad niezależnymi strumieniami historii Za pomocą rozgałęzień i zgłoszeń (pull requests) możesz uczestniczyć we wspólnej pracy nad różnymi gałęziami i funkcjami projektu.

Przegląd trwających prac Na podstawie listy zgłoszeń możesz zapoznać się ze wszystkimi funkcjami, nad którymi aktualnie trwa praca. Kliknięcie danego zgłoszenia umożliwia wyświetlenie najnowszych związanych z nim zmian oraz dyskusji na ich temat.

Analiza postępów zespołu Na podstawie tzw. pulsu projektu albo analizy historii zmian możesz sprawdzić, nad czym pracował zespół.

Najważniejsze pojęcia Aby móc skutecznie posługiwać się Gitem i GitHubem, powinieneś zrozumieć pewne pojęcia i koncepcje. Oto lista najczęściej używanych terminów wraz z krótkimi opisami i przykładami tego, w jaki sposób mogą one zostać użyte w rozmowie1.

Commit (zmiana) Za każdym razem, gdy chcesz w Gicie wykonać pewne modyfikacje w jednym pliku lub w ich większej liczbie, musisz wprowadzić nową zmianę (commit). Przykład użycia: Wprowadźmy te zmiany i wyślijmy je do GitHuba.

Commit message (komentarz do zmiany) Przy wprowadzaniu zmiany powinieneś dołączyć do niej informację o tym, dlaczego została wykonana. Komentarze do zmian są nieocenione przy późniejszych próbach zrozumienia przyczyn implementacji danej poprawki. Przykład użycia: Pamiętaj o uwzględnieniu w komentarzu do zmiany uwag Krysi co do nowych wytycznych.

Branch (gałąź) Sekwencja zmian niezależnych od głównego projektu, wykonanych w celu przetestowania eksperymentalnej wersji albo opracowania nowej funkcji. Przykład użycia: Utwórzmy gałąź, w której wypróbujemy nową funkcję wyszukiwania.

Master branch, master (gałąź główna) W każdym nowym projekcie Gita jest tworzona domyślna gałąź o nazwie master. Ta gałąź powinna być ostatecznym celem pracy nad projektem, gdy będzie on już gotowy do opublikowania w finalnej, produkcyjnej wersji. Przykład użycia: Pamiętaj, aby nigdy nie wprowadzać zmian bezpośrednio w gałęzi głównej.

Feature (topic) branch (gałąź funkcji, gałąź tematyczna) Za każdym razem, gdy pracujesz nad nową funkcją, powinieneś utworzyć dla niej osobną gałąź. Jest ona nazywana gałęzią funkcji. Przykład użycia: Mamy za dużo gałęzi funkcji.

Skupmy się na dokończeniu jednej albo dwóch z nich i zaimplementowaniu ich w wersji produkcyjnej.

Release branch (gałąź wydania) Jeśli projekt podlega ręcznej (nieautomatycznej) kontroli jakości bądź też jeśli musisz zapewniać wsparcie dla starszych wersji projektu, możesz potrzebować gałęzi jego

poszczególnych wydań do wprowadzania zmian i aktualizacji. Z technicznego punktu widzenia gałąź funkcji nie różni się od gałęzi wydania; rozróżnienie przydaje się jednak podczas dyskusji w zespole na temat projektu. Przykład użycia: Musimy usunąć lukę w bezpieczeństwie w gałęziach wszystkich wspieranych wydań.

Merge (scalanie) Jest to metoda przenoszenia prac ukończonych w jednej gałęzi projektu do innej gałęzi.

Najczęściej scala się gałąź funkcji z gałęzią główną. Przykład użycia: Dobra robota z funkcją „moje konto”. Czy możesz scalić ją z gałęzią główną, żeby weszła do wersji produkcyjnej?.

Tag (etykieta) Odwołanie do konkretnej wprowadzonej zmiany. Najczęściej służy do dokumentowania wydań produkcyjnych, dzięki czemu wiadomo, jaka dokładnie wersja kodu weszła do wydania produkcyjnego i kiedy to miało miejsce. Przykład użycia: Oznaczmy to wydanie etykietą i opublikujmy jako wersję produkcyjną.

Check out (weryfikacja) Wyświetlenie określonej wersji projektu, umożliwiające przejrzenie historycznego stanu plików z danego okresu. Najczęściej weryfikacji poddaje się wybraną gałąź, aby zapoznać się z pracami, które zostały na niej wykonane — ale w ten sam sposób można zweryfikować dowolną zmianę. Przykład użycia: Czy możesz sprawdzić etykietę ostatniego wydania? W wersji produkcyjnej jest błąd, który trzeba odtworzyć i naprawić.

Pull request (zgłoszenie) Początkowo narzędzie Pull request służyło do sformułowania prośby o zweryfikowanie zmian wprowadzonych w danej gałęzi i scalenie ich z gałęzią główną. Obecnie często jest ono używane na wcześniejszym etapie prac w celu zapoczątkowania dyskusji o potencjalnych, nowych funkcjach. Przykład użycia: Wyślij zgłoszenie dotyczące nowej funkcji głosowania, żeby sprawdzić, co na ten temat sądzi reszta zespołu.

Issue (problem, zadanie) GitHub jest wyposażony w funkcję o nazwie Issues (problemy), która może służyć do omawiania funkcji, wyłapywania błędów — albo jednocześnie w jednym i w drugim celu. Przykład użycia: Masz rację, logowanie nie działa na iPhonie. Możesz zgłosić problem w GitHubie wraz z listą kroków umożliwiającą odtworzenie tego błędu?.

Wiki (dokumentacja, wiki) Mechanizm wiki, pierwotnie opracowany przez Warda Cunninghama, umożliwia wygodne tworzenie powiązanych ze sobą stron internetowych. Dokumentacja projektów GitHuba bardzo często bazuje na silniku wiki. Przykład użycia: Możesz dodać do wiki stronę z opisem konfiguracji projektu umożliwiającej uruchomienie go na wielu serwerach?.

Clone (klonowanie) Czasami zachodzi potrzeba pobrania kopii projektu z GitHuba, aby można było pracować

na nim lokalnie. Proces kopiowania repozytorium na komputer lokalny jest nazywany klonowaniem. Przykład użycia: Czy możesz wieczorem sklonować repozytorium, usunąć błąd, a potem wysłać poprawkę z powrotem do GitHuba?.

Fork (rozgałęzienie projektu, rozwidlenie, fork) Niekiedy nie będziesz mieć uprawnień do wprowadzania zmian bezpośrednio w repozytorium. Może tak być na przykład w wypadku programu open source, tworzonego przez osoby, których nie znasz, bądź projektu realizowanego przez inny zespół w Twojej firmie, z którym zwykle nie współpracujesz. Jeśli chcesz wprowadzić zmiany w takim projekcie, musisz najpierw utworzyć jego kopię na własnym koncie GitHub. Ten proces jest nazywany rozwidlaniem albo rozgałęzianiem całego repozytorium (ang. forking)2.

Takie repozytorium można następnie sklonować, wprowadzić w nim zmiany i wysłać je z powrotem za pośrednictwem zgłoszenia (pull request). Przykład użycia: Chciałbym zobaczyć stronę główną ze zmodyfikowanym tekstem marketingowym. Zrób fork repozytorium i wyślij zgłoszenie z proponowanymi zmianami.

Nie przejmuj się, jeśli cała ta terminologia początkowo wyda Ci się dość zagmatwana. Gdy zaczniesz pracę z prawdziwymi projektami, wszystko nabierze sensu! W następnym rozdziale przyjrzymy się różnym elementom typowego repozytorium w GitHubie i omówimy ich zastosowanie do śledzenia postępów prac nad projektem.

ROZDZIAŁ 2.

Przeglądanie W tym rozdziale zapoznasz się z możliwościami przeglądania bieżącego stanu projektu, co pozwoli Ci zobaczyć, co się w nim dzieje. Jako przykładu użyjemy Bootstrapa (http://getbootstrap.com/) — popularnego projektu open source.

Zapoznanie się ze stroną projektu Bootstrap to narzędzie umożliwiające szybkie projektowanie atrakcyjnie wyglądających stron internetowych. Odwiedź stronę projektu w serwisie GitHub (https://github.com/twbs/bootstrap). Na stronie głównej znajduje się wiele informacji — zacznijmy od przejrzenia najważniejszych jej elementów (rysunek 2.1).

Jedną z pierwszych rzeczy, na którą warto zwrócić uwagę, jest widoczna w lewym górnym rogu nazwa projektu („bootstrap”) oraz informacja o tym, że jego właścicielem jest użytkownik (w tym wypadku konkretnie organizacja) o nazwie „twbs”. Jeśli odwiedziłbyś stronę https://github.com/twbs, to mógłbyś przejrzeć wszystkie projekty tej organizacji dostępne w GitHubie. Po lewej stronie nazwy organizacji znajduje się ikona oznaczająca, że jest to repozytorium publiczne, a więc takie, które każdy może przeglądać. Wielu projektom, nad którymi będziesz pracować, może towarzyszyć symbol zamkniętej kłódki, oznaczający, że są to projekty prywatne i mogą być oglądane tylko przez osoby będące współpracownikami w projekcie.

Rysunek 2.1. Strona główna repozytorium Bootstrapa w serwisie GitHub Jak można zobaczyć po prawej stronie nazwy projektu, w chwili robienia zrzutu ekranu pokazanego na rysunku 2.1 repozytorium Bootstrapa obserwowało (Watch) 3857 osób, aby otrzymywać informacje za każdym razem, gdy w projekcie zostaną wprowadzone jakieś zmiany. Ponadto 68 928 osób oznaczyło projekt gwiazdką (Star), aby w ten sposób dodać go do swoich ulubionych, a 25 292 osoby zrobiły odgałęzienie całego repozytorium (Fork), czyli utworzyły w serwisie GitHub jego kopię, w której mogą wprowadzać zmiany i udostępniać je innym użytkownikom.

Nieco niżej na stronie znajduje się krótki opis projektu, a pod nim widnieje informacja, że w projekcie wprowadzono łącznie 9448 zmian (commit), aktualnie jest rozwijanych 16 gałęzi historii (branch), 27 wydań zostało oznaczonych jako zalecane (tzw. wersje produkcyjne, czyli release), a nad kodem pracowało w sumie 550 osób (contributor).

Jak widać, aktualnie przeglądamy gałąź główną projektu, czyli jesteśmy w folderze głównym repozytorium o nazwie bootstrap, a ostatnia zmiana w tej gałęzi ma następujący opis: „Fixes #13872 more: add overrides for lg and sm input modifiers” (cokolwiek by to oznaczało).

Zmiany tej dokonał użytkownik GitHuba o pseudonimie „mdo” (https://github.com/mdo).

Jeszcze niżej na rysunku znajdują się foldery (zwane też katalogami) oraz pliki umieszczone w folderze głównym projektu (tzw. root).

Wyświetlanie pliku README.md Jeśli w folderze root projektu znajduje się plik o nazwie README.md, to jego zawartość zostanie wyświetlona pod listą folderów i plików na stronie głównej tego projektu.

Wspomniany plik zawiera ogólne omówienie projektu oraz pomocnicze informacje, które mogą się przydać jego współautorom, takie jak sposób instalacji oprogramowania albo uruchomienia testów, dopuszczalne zastosowanie kodu i możliwe rodzaje współpracy.

Obecnie w plikach README coraz częściej znajdują się infografiki ilustrujące aktualny stan prac, generowane na przykład przez automatyczne narzędzia do testowania. Jak pokazano na rysunku 2.2, na stronie projektu Bootstrap znajdują się numery wersji dwóch innych projektów, od których Bootstrap jest zależny. Widać na nim też, że automatyczne testy zostały wykonane bez przeszkód, a zależności są aktualne; ponadto na infografice widnieją numery wersji przeglądarek i systemów operacyjnych, w których Bootstrap powinien poprawnie funkcjonować.

Rysunek 2.2. Zawartość pliku README.md projektu Bootstrap

Przeglądanie historii zmian Historia zmian jest znakomitym źródłem informacji na temat prac wykonanych w danej gałęzi projektu. Otwórz stronę projektu Bootstrap w serwisie GitHub (https://github.com/twbs/bootstrap) i kliknij odsyłacz z liczbą zmian — w chwili, gdy piszę te słowa, miał on postać 9,448 commits, ale gdy Ty odwiedzisz wspomnianą stronę, liczba ta będzie oczywiście inna. Na ekranie wyświetli się lista zmian, począwszy od najnowszych (rysunek 2.3).

Rysunek 2.3. Lista najnowszych zmian w projekcie Kliknięcie dowolnej zmiany spowoduje wyświetlenie powiązanego z nią komunikatu, który powinien wyjaśniać przyczynę jej wprowadzenia. Poniżej zostaną wyświetlone pliki, które dodano, usunięto lub zmodyfikowano w ramach danej zmiany, przy czym fragmenty usunięte zostaną wyróżnione kolorem czerwonym, dodane zaś — zielonym (rysunek 2.4).

Wyświetlanie zgłoszeń Zgłoszenia (pull requests) pozwalają zorientować się w bieżącym stanie prac. Wróć na stronę główną i kliknij odsyłacz Pull Requests, znajdujący się po prawej stronie, u góry. W oknie przeglądarki pojawi się wówczas lista otwartych zgłoszeń. Są to na ogół funkcje lub poprawki, nad którymi aktualnie pracują uczestnicy projektu (rysunek 2.5).

Rysunek 2.4. Jedna z najnowszych zmian w projekcie

Rysunek 2.5. Otwarte zgłoszenia do projektu Po kliknięciu dowolnego zgłoszenia wyświetlony zostanie jego tytuł wraz z krótkim opisem.

Opisowi mogą towarzyszyć numery proponowanych zmian oraz komentarze użytkowników dyskutujących nad ich zaimplementowaniem (rysunek 2.6).

Rysunek 2.6. Jedno z niedawnych zgłoszeń Przeglądanie zgłoszeń jest znakomitym sposobem na zapoznanie się z najnowszymi pracami toczącymi się w ramach projektu oraz aktualnym stanem zmian — niezależnie od tego, czy są to poprawki błędów, czy proponowane funkcje.

Wyświetlanie problemów O ile zgłoszenia pozwalają określić aktualny stan prac nad poprawkami błędów i funkcjami, o tyle przeglądanie problemów (issues) umożliwia spojrzenie z szerszej perspektywy na te aspekty projektu, które wciąż oczekują na realizację. Zgłoszenia są często powiązane z problemami, ale w wielu projektach istnieją takie problemy, nad którymi nikt jeszcze nie zaczął pracować, a co za tym idzie — nie zgłosił ich.

Po kliknięciu odsyłacza Issues umożliwiającego wyświetlenie listy problemów domyślnie pokazuje się zestawienie tych z nich, które nadal są otwarte (rysunek 2.7).

Rysunek 2.7. Otwarte problemy dla danego projektu Po kliknięciu wybranego problemu wyświetli się jego tytuł oraz dotyczące go komentarze.

Jeśli w kwestii tego problemu zostały wprowadzone jakieś zmiany i wysłano je do GitHuba, a w komentarzu do tych zmian jest wzmianka o danym problemie, to zostaną one wyświetlone na stronie problemu, abyś mógł sprawdzić, co zostało zrobione. Jak pokazano na rysunku 2.8, jeden z użytkowników ma kłopoty z pewną funkcją Bootstrapa.

Wyświetlanie pulsu Puls (odsyłacz Pulse) to świetny sposób na oszacowanie bieżącej aktywności projektu. Puls można skonfigurować tak, by ilustrował działania z ostatniego dnia, ostatnich trzech dni lub ostatniego tygodnia albo miesiąca. Na rysunku 2.9 pokazano działania obejmujące tydzień.

Puls rozpoczyna się informacją o liczbie zgłoszeń włączonych do projektu, czyli scalonych (merged), oraz zgłoszeń proponowanych (proposed). Pokazuje też liczbę zgłoszeń zamkniętych i otwartych. Warto zapamiętać, że podana w pulsie liczba aktywnych zgłoszeń i zmian nie odnosi się do zgłoszeń i zmian nierozpatrzonych, ale tylko do tych, które zostały zapoczątkowane i ukończone w wybranym okresie. Na przykład w chwili, gdy piszę te słowa, w projekcie Bootstrap było 15 scalonych i 8 proponowanych zgłoszeń, co daje łącznie 23 aktywne zgłoszenia w danym tygodniu, jednakże sumaryczna liczba otwartych zgłoszeń wynosiła 28.

Rysunek 2.8. Jeden z niedawnych problemรณw

Rysunek 2.9. Puls dla projektu Bootstrap

Akapit znajdujący się poniżej stanowi zwięzłe podsumowanie ostatnich modyfikacji i zawiera dane o liczbie ich autorów, zmian w gałęzi głównej, całkowitej liczbie zmian we wszystkich gałęziach oraz liczbie plików dodanych, usuniętych lub zmodyfikowanych w obrębie gałęzi głównej. Oprócz tego znajduje się w nim informacja o liczbie linii tekstu, które zostały dodane lub usunięte; z tym zastrzeżeniem, że jeśli w pliku tekstowym zostanie zmieniona zawartość jednej linii, Git potraktuje to tak, jakby jedna linia została usunięta, a inna dodana na jej miejsce.

Po prawej stronie znajduje się wykres słupkowy ilustrujący zestawienie uczestników projektu, którzy w danym okresie dokonali największej liczby zmian. Pod nim widnieje lista tytułów scalonych i proponowanych zgłoszeń, po niej zaś lista zamkniętych i otwartych problemów.

Podgląd pulsu kończy się listą „niezamkniętych dyskusji” (unresolved conversations), czyli zestawieniem wszystkich problemów i zgłoszeń, które zostały w jakiś sposób skomentowane, ale są nadal nierozwiązane.

Wyświetlanie wykresów w GitHubie O ile puls stanowi podsumowanie bieżącej aktywności, o tyle strony z wykresami (odsyłacz Graphs) umożliwiają oszacowanie prac, jakie zostały wykonane w ramach danego projektu przez dłuższy czas.

Wykres współpracowników Wykres współpracowników, pokazany na rysunku 2.10, przedstawia fluktuacje zaangażowania w projekt w czasie na podstawie liczby operacji zmieniania, dodawania i usuwania. Główny wykres obejmuje wszystkie takie działania, pod nim zaś znajdują się mniejsze wykresy, ilustrujące aktywność poszczególnych uczestników projektu — od najbardziej do najmniej aktywnych.

Domyślny wykres zmian ilustruje liczbę zmian w gałęzi głównej w kontekście czasu, przy czym są to jedynie te zmiany, które zostały scalone w tej gałęzi. Jeśli ktoś z Twojego zespołu przez cały tydzień pracował nad gałęzią poświęconą jakiejś funkcji, a jego praca nie została jeszcze włączona do gałęzi głównej, to aktywność tego członka zespołu nie zostanie uwzględniona aż do chwili, gdy funkcja uzyska status produkcyjny i zostanie scalona z gałęzią główną projektu.

Rysunek 2.10. Wykres współpracowników projektu Bootstrap Domyślnie wykresy obejmują cały czas funkcjonowania projektu. Jeśli chciałbyś wybrać węższy zakres czasu, kliknij wykres tam, gdzie zakres ten ma się zaczynać, a potem przeciągnij kursorem myszy i zwolnij jej przycisk w miejscu, w którym ma się on kończyć. Rysunek 2.11 przedstawia efekt takiej operacji, mającej na celu wyświetlenie zmian przeprowadzonych latem 2013 roku. Jak widać, główny diagram w górnej części strony pozostał bez zmian, z tym że w jego lewym górnym rogu widnieje informacja o wybranym zakresie czasu (od 21 czerwca do 30 sierpnia). Za to wykresy ilustrujące zmiany dokonane przez poszczególnych uczestników przedstawiają rozkład tych zmian tylko w wybranym okresie.

Nie istnieją wytyczne co do wielkości zmiany. Przyjmuje się regułę, że jeśli uczestnicy projektu nie zajmują się analizą problemów lub przeprowadzaniem testów, lecz piszą kod, to powinni wysyłać zmiany co 5 – 10 minut. Jednak w zależności od zespołu, z którym pracujesz, może się okazać, że niektórzy programiści generują znacznie mniej zmian niż inni pomimo wykonywania podobnej ilości pracy. W takim przypadku z listy Contributions (aktywności), znajdującej się obok wykresów aktywności, wybierz opcję Additions (dodania) albo Deletions (usunięcia). W ten sposób będziesz mógł lepiej oszacować liczbę linii kodu dodanych do projektu lub usuniętych z niego przez poszczególnych programistów. W wypadku modyfikacji zmiana w jednej linii zostanie policzona jako usunięcie starej linii i dodanie nowej.

Rysunek 2.11. Wykres aktywności dla lata 2013 roku

Wykres zmian Wykres zmian, pokazany na rysunku 2.12, ilustruje liczbę zmian tygodniowo w ciągu całego okresu pracy nad projektem, co pozwala z grubsza zorientować się w aktywności tegoż projektu i jej zmienności w czasie.

Zasadniczym powodem, dla którego warto zapoznać się z wykresem zmian, jest możliwość oszacowania liczby zmian tygodniowo w trakcie całego okresu trwania projektu. Diagram zaczyna się od zestawienia słupkowego, w którym jeden słupek odpowiada jednemu tygodniowi. Takie zestawienie pozwala łatwo wychwycić cykliczność lub długoterminowe trendy. Czy liczba zmian w projekcie stopniowo spada? Czy dokooptowanie nowych programistów spowodowało zauważalny wzrost liczby zmian? Czy większość zmian przypada na ostatni tydzień każdego miesiąca albo czy na wykresie daje się zauważyć tendencje sezonowe? Omawiany wykres pozwala uzyskać dobre rozeznanie w tym, jak liczba zmian — którą można traktować jako bardzo przybliżoną miarę produktywności zespołu — ulega modyfikacji w czasie.

Rysunek 2.12. Wykres liczby zmian w projekcie Bootstrap Pod zestawieniem słupkowym znajduje się wykres liniowy pokazujący uśrednioną wartość zmian w poszczególnych dniach tygodnia podczas całego życia projektu. Wykres ten może się przydać do oszacowania cyklu aktywności w trakcie typowego tygodnia pracy nad projektem.

Czy na przykład uczestnicy nie wysyłają zmian w poniedziałki ze względu na dużą liczbę spotkań? A może większość zmian wprowadzają w czwartki, przed piątkowymi prezentacjami? Albo zbyt dużo pracują w weekendy, co nie rokuje utrzymania tempa rozwoju projektu w dłuższej perspektywie czasowej?

Wykres częstotliwości zmian w kodzie Wykres częstotliwości zmian w kodzie, zaprezentowany na rysunku 2.13, przedstawia liczbę linii dodanych do projektu i usuniętych z niego w kontekście czasu. Wykres ten doskonale nadaje się do sprawdzania tego, kiedy w ramach pracy nad danym projektem zaszły w nim największe zmiany.

W wypadku refaktoryzacji kodu programiści często dodają i usuwają setki albo nawet tysiące linii naraz, podczas gdy w zwykłym cyklu pracy jedna zmiana obejmuje najczęściej tylko kilka dodanych, usuniętych lub zmodyfikowanych linii. We wspomnianej refaktoryzacji liczba zmian może być relatywnie mała, przy czym liczba zmodyfikowanych linii będzie wyraźnie większa; jeśli więc chciałbyś oszacować, kiedy w projekcie zaszły najpoważniejsze przeobrażenia, powinieneś zacząć od wykresu częstotliwości zmian w kodzie. Na przykład na podstawie rysunku 2.13 widać, że w lutym i marcu 2013 roku doszło do znaczącej refaktoryzacji kodu.

Rysunek 2.13. Wykres częstotliwości zmian w kodzie dla projektu Bootstrap

Wykres „karta perforowana” Wykres typu „karta perforowana”, przedstawiony na rysunku 2.14, pozwala oszacować, o jakiej porze dnia i w jakich dniach wprowadzono najwięcej zmian.

Na wykresie tego typu poszczególne godziny we wszystkich dniach tygodnia zostały przedstawione w postaci kółek. Średnice kółek są proporcjonalne do procentowej liczby zmian w projekcie, wprowadzonych o danej porze danego dnia. Im większe kółko, tym więcej zmian w projekcie nastąpiło właśnie w tym czasie. Jest to kolejny świetny sposób na oszacowanie najbardziej produktywnych pór dnia dla zespołu.

Rysunek 2.14. Wykres „karta perforowana” dla projektu Bootstrap

Wykres sieciowy Wykres sieciowy, zaprezentowany na rysunku 2.15, ilustruje liczbę gałęzi i zmian w tych gałęziach w trakcie życia projektu. Przedstawia on także odgałęzienia całego repozytorium (forki) wykonane przez uczestników.

Wykres sieciowy przydaje się do oszacowania postępów prac w danej gałęzi i daje pewien pogląd na rodzaj zadań wykonywanych przez wybranego członka zespołu w obrębie jego forka. Gdy zmiany te trafiają do głównej gałęzi w źródłowym repozytorium, fakt ten jest symbolizowany strzałką z informacją o scaleniu zmiany (jeśli została ona scalona przez zgłoszenie). Wybraną zmianę można wskazać kursorem myszy, co spowoduje wyświetlenie jej autora oraz dołączonego do niej komentarza.

Lista uczestników Ostatnie zestawienie, które mogą obejrzeć wszyscy, niezależnie od rodzaju uprawnień, to lista uczestników projektu. Jeśli w danym projekcie zrobiono wyjątkowo dużo rozgałęzień (forków), na ekranie pojawi się komunikat taki jak na rysunku 2.16, informujący o wyświetleniu tylko częściowego ich zestawienia.

Rysunek 2.15. Wykres sieciowy

Rysunek 2.16. Lista czล onkรณw

Lista uczestników zawiera tylko te osoby, które wykonały odgałęzienia repozytorium albo odgałęzienia odgałęzień. Te osoby nie należą do zespołu pracującego nad oryginalnym, źródłowym repozytorium i z tego względu potrzebują jego kopii, by mogły wprowadzać zmiany za pośrednictwem zgłoszeń.

Wykres ruchu sieciowego Jest jeszcze jeden pomocniczy wykres, dostępny tylko dla właścicieli i współautorów projektu, a mianowicie wykres ruchu sieciowego, pokazany na rysunku 2.17.

Rysunek 2.17. Wykres ruchu sieciowego Wykres ten przedstawia liczbę wyświetleń projektu i liczbę unikatowych gości strony na przestrzeni czasu. Na stronie z tym wykresem są ponadto podane takie informacje jak adresy stron WWW, z których internauci trafiają na stronę projektu, oraz najpopularniejsze materiały na stronie danego projektu w serwisie GitHub. Prezentowany wykres to świetny sposób na oszacowanie popularności projektów open source.

Na bazie informacji przedstawionych w tym rozdziale powinieneś nieźle się orientować, jak można szybko zapoznać się z projektem na podstawie pliku README, analizy zmian, zgłoszeń, problemów, pulsu i wykresów dostępnych w serwisie GitHub. W następnym rozdziale przyjrzymy się zagadnieniom dotyczącym uczestnictwa w projekcie.

ROZDZIAŁ 3.

Edycja Z tego rozdziału dowiesz się, w jaki sposób można wziąć czynny udział w pracach nad projektem. Zaczniemy od omówienia przypadku, w którym nie masz uprawnień do wprowadzania bezpośrednich zmian w projekcie, więc po to, aby je zasugerować, musisz utworzyć odgałęzienie całego repozytorium (fork) i posłużyć się zgłoszeniami. Potem zaś przeczytasz o tym, jak dodawać, edytować i usuwać pliki oraz zmieniać ich nazwy bezpośrednio w serwisie GitHub. Dowiesz się też, jak pracować z folderami w GitHubie, na koniec zaś przeczytasz o tym, jak należy postąpić w celu wprowadzenia wielu modyfikacji w ramach jednej zmiany.

Udział w projekcie za pośrednictwem odgałęzień Jeśli chcesz bezpośrednio uczestniczyć w pracach nad projektem, musisz być jego właścicielem albo zostać dodany do zespołu jako współpracownik. Jeżeli zależy Ci na wzięciu udziału w pracach nad projektem, którego właścicielem jest ktoś inny (a Ty nie należysz do jego zespołu), to musisz utworzyć kopię tego projektu na swoim koncie użytkownika serwisu GitHub. Proces ten jest określany jako tworzenie odgałęzienia (forking).

Po utworzeniu odgałęzienia (forka) będziesz mógł wprowadzać w nim dowolne zmiany i sugerować chęć włączenia tych zmian do oryginalnego projektu za pośrednictwem zgłoszeń (pull requests). Zapoznajmy się z tym procesem.

Otwórz stronę https://github.com/pragmaticlearning/github-example. Kliknij przycisk Fork (odgałęzienie), znajdujący się w prawym górnym rogu strony (rysunek 3.1).

Rysunek 3.1. Fragment strony serwisu GitHub z widocznym przyciskiem Fork Po kliknięciu przycisku Fork, jeśli jesteś członkiem dowolnej organizacji w serwisie GitHub, na ekranie pojawi się lista miejsc, w których możesz utworzyć odgałęzienie. Rysunek 3.2 przedstawia przykład tego rodzaju listy.

Rysunek 3.2. Wybór miejsca do utworzenia kopii repozytorium Po wybraniu miejsca do utworzenia kopii repozytorium (repozytoria często nazywa się w skrócie repo), a także wtedy, gdy nie należysz do żadnej organizacji, zostaniesz automatycznie przeniesiony na stronę swojego nowego projektu. Po utworzeniu odgałęzienia (kopii) repozytorium możesz wprowadzać w nim dowolne zmiany. W dalszej części rozdziału dowiesz się, jak można dodać do repozytorium nowy plik i jak utworzyć zgłoszenie, które umożliwi Ci włączenie wprowadzonej zmiany do projektu źródłowego.

Dodawanie pliku W tej części niniejszego rozdziału przeczytasz o tym, w jaki sposób można dodać nowy plik do projektu. Jak widać na rysunku 3.3, obok nazwy projektu znajduje się niewielki przycisk z symbolem plusa (+).

Rysunek 3.3. Odsyłacz umożliwiający utworzenie nowego pliku Kliknij wspomniany przycisk, aby wyświetlić stronę pokazaną na rysunku 3.4.

Rysunek 3.4. Ekran tworzenia nowego pliku W górnej części strony, tuż obok nazwy projektu, znajduje się pole tekstowe — można w nim wprowadzić nazwę pliku, który zamierzasz dodać do projektu. Poniżej widnieje znacznie większe pole, w którym można wprowadzać i edytować zawartość tego pliku. Po nadaniu plikowi nazwy i wprowadzeniu dowolnej treści przewiń zawartość strony w dół, do obszaru pokazanego na rysunku 3.5. Znajdują się tam dwa kolejne pola tekstowe: pierwsze przeznaczone na krótki opis pliku (wymagany), a drugie — na opis opcjonalny, dłuższy, przybliżający zmianę, jaką zamierzasz wprowadzić.

Rysunek 3.5. Dolna część ekranu tworzenia nowego pliku

Podane w tych polach opisy zostaną potraktowane jako komentarze do zmiany. Jeśli nie wpiszesz nic, serwis wygeneruje komentarz domyślny o treści Create (utworzenie), zawierający nazwę pliku. Zasadniczo warto jednak opatrzyć zmianę sensownym komentarzem, by inne osoby przeglądające projekt wiedziały, co i dlaczego zmieniłeś. Na koniec kliknij zielony przycisk Commit new file (zatwierdź nowy plik), aby dodać nowy plik do projektu oraz związaną z tym zmianę — do historii zmian. Jak widać na rysunku 3.6, do listy plików został dodany plik o nazwie new_file.md. W wypadku mojego projektu mamy do czynienia z trzema zmianami — ostatnią z nich jest dodanie nowego pliku.

Rysunek 3.6. Strona główna projektu po dodaniu nowego pliku

Tworzenie zgłoszenia Wprowadziliśmy zmianę w naszym odgałęzieniu projektu, ale zmiana ta nie trafiła do repozytorium źródłowego. To logiczne: przecież każdy może wykonać kopię publicznie dostępnego projektu, a jego właściciel raczej nie życzyłby sobie, by każdy, kto tylko chce, mógł modyfikować pliki źródłowe. Czasami warto jednak pozwolić innym na zaproponowanie zmian w projekcie. Takie rozwiązanie pozwala większej liczbie osób wygodnie pracować nad projektem open source albo małemu zespołowi — nad projektem wewnętrznym o mniejszej skali. Możliwość proponowania zmian zapewniają zgłoszenia.

Dzięki zgłoszeniom możesz zasugerować włączenie do projektu źródłowego zmian wprowadzonych we własnym odgałęzieniu repozytorium. Za chwilę przeczytasz, na czym to polega. Zauważ, że na rysunku 3.7 w prawej części strony głównej projektu znajduje się zakładka Pull Requests (zgłoszenia).

Rysunek 3.7. Strona główna projektu z widoczną zakładką Pull Requests Po kliknięciu zakładki Pull Requests na ekranie pojawi się strona podobna do pokazanej na rysunku 3.8, z komunikatem informującym o braku otwartych zgłoszeń. Kliknij zielony przycisk New pull request (nowe zgłoszenie), znajdujący się w prawej górnej części ekranu.

Po kliknięciu przycisku New pull request pokaże się strona podobna do przedstawionej na rysunku 3.9.

Jeden z pierwszych komunikatów widocznych na rysunku 3.9 informuje, że zgłoszenie dotyczy gałęzi głównych dwóch repozytoriów: pragmaticlearning:master i PeterBell:master.

Zgłoszenia to sugestie przeniesienia zmian z jednej gałęzi (gałęzie takie określane są też jako strumienie historii) do drugiej. W tym wypadku GitHub poprawnie odgadł, że zamierzam zasugerować wprowadzenie zmiany wykonanej w gałęzi głównej mojej kopii repozytorium (zmiana ta polegała na utworzeniu pliku) do gałęzi głównej oryginalnego repozytorium. Zwróć uwagę, że gałąź ze zmianami przeznaczonymi do scalenia znajduje się po prawej stronie, zaś gałąź docelowa — po lewej.

Rysunek 3.8. Ekran zgłoszeń

Rysunek 3.9. Ekran podglądu zgłoszenia Jak pokazano nieco niżej, na rysunku 3.9, na tej samej stronie znajduje się krótkie podsumowanie zmian, które będą wprowadzone, jeśli zgłoszenie zostanie uwzględnione: rzeczywiście wykonałem jedną zmianę polegającą na zmodyfikowaniu jednego pliku. Poniżej,

na zielono, została wyświetlona nowa treść, która będzie dodana do pliku new_file.md w wypadku zatwierdzenia zmiany. Jeśli kliknąłbym przycisk Show diff stats (pokaż statystyki różnic), poznałbym szczegółowe informacje o zmianie, na przykład takie, że dodana została dokładnie jedna linia treści, a żadna linia nie została usunięta.

Po upewnieniu się, że proponowane zgłoszenie jest zgodne z oczekiwaniami, można kliknąć duży zielony przycisk Create pull request (utwórz zgłoszenie). W rezultacie na ekranie pojawi się strona podobna do pokazanej na rysunku 3.10.

Rysunek 3.10. Ekran tworzenia zgłoszenia W tym miejscu masz możliwość wyjaśnienia, dlaczego Twoja zmiana powinna trafić do projektu źródłowego, poświęć więc chwilę na nadanie jej zrozumiałego tytułu oraz opatrzenie stosownym opisem. Domyślnie tytuł jest generowany na podstawie pierwszej linii komentarza do ostatniej wprowadzonej zmiany, lecz jeśli zmian w gałęzi, którą proponujesz dodać do projektu głównego, było więcej, to w opisie znajdzie się punktowana lista składająca się z pierwszych linii wszystkich komentarzy do zmian uwzględnionych w zgłoszeniu. To dobry punkt wyjścia, warto jednak poświęcić trochę czasu i uzupełnić te dane nie tylko o opis dotyczący rodzaju wprowadzonych zmian, ale także przyczyn ich wprowadzenia i zalet, które przemawiają za uwzględnieniem tych zmian w projekcie głównym.

Po zakończeniu prac nad opisem zgłoszenia kliknij przycisk Create pull request, a wyświetli

się strona podobna do przedstawionej na rysunku 3.11.

Rysunek 3.11. Gotowe zgłoszenie Patrząc na rysunek 3.11, warto zwrócić uwagę na kilka kwestii. Pierwsza to taka, że jesteśmy w oryginalnym projekcie — w repozytorium pragmaticlearning. To logiczne: chcieliśmy utworzyć zgłoszenie mające na celu uwzględnienie naszych zmian w tym projekcie, więc zgłoszenie to należy właśnie do niego, a nie do utworzonego odgałęzienia. W górnej części strony widnieje komunikat o treści: PeterBell wants to merge 1 commit into pragmaticlearning:master from PeterBell:master (PeterBell chce włączyć 1 zmianę z gałęzi PeterBell:master do gałęzi pragmaticlearning:master). Oprócz tego komunikatu podane są też informacje o samym zgłoszeniu (tytuł i opis) oraz o wprowadzonej zmianie. Kliknięcie tej zmiany spowoduje wyświetlenie szczegółowych danych na jej temat, co pokazano na rysunku 3.12.

Zauważ, że użycie odsyłacza do zmiany spowodowało powrót do repozytorium PeterBell, ponieważ zmiana zaszła właśnie tam. Na ekranie widoczne są: komentarz do zmiany, nazwa jej autora oraz informacje o tym, na czym ona polegała.

Rysunek 3.12. Wyświetlanie informacji o zmianie z poziomu zgłoszenia Spójrz raz jeszcze na ekran zgłoszenia pokazany na rysunku 3.11. Zauważ, że znajduje się na nim przycisk Merge pull request (scal zgłoszenie). Ta możliwość jest dostępna tylko dla właściciela projektu oraz osób dodanych jako współpracownicy. Jeśli ten ekran wyświetliłby ktoś bez stosownych uprawnień, to nie mógłby zatwierdzić proponowanego zgłoszenia. Na przykład w sytuacji pokazanej na rysunku 3.13 zalogowałem się jako inny użytkownik i po wyświetleniu tej samej strony nie widzę już wspomnianego wcześniej przycisku, choć nadal mógłbym skomentować zgłoszenie, jeślibym chciał.

Przed zatwierdzeniem zgłoszenia często dochodzi do dyskusji, ale temu zagadnieniu bliżej przyjrzymy się w rozdziale 4. Na razie przyjmijmy, że zaakceptowałem zgłoszenie i włączam zmianę do głównego repozytorium. Aby to zrobić, wystarczy kliknąć przycisk Merge pull request — na ekranie pojawia się wtedy pole tekstowe, w którym możesz zmodyfikować komentarz do akceptacji zgłoszenia, jak na rysunku 3.14.

Po wprowadzeniu dowolnych zmian w treści komentarza wystarczy kliknąć przycisk Confirm merge (zatwierdź scalenie), znajdujący się pod komentarzem, po jego prawej stronie. Zmiana jest wówczas uwzględniana w repozytorium, a jej rezultat wyświetlany na ekranie, tak jak na rysunku 3.15.

Rysunek 3.13. Wyświetlanie zgłoszenia bez uprawnień do zatwierdzenia go

Rysunek 3.14. Przygotowanie do zatwierdzenia zgłoszenia

Rysunek 3.15. Wyświetlanie zamkniętego (scalonego) zgłoszenia Zauważ, że komentarz do zgłoszenia i zmiany jest nadal widoczny, lecz teraz wiemy ponadto, kto uwzględnił zgłoszenie i mniej więcej kiedy to miało miejsce. Jak widać, zgłoszenie jest obecnie zamknięte, co stało się automatycznie po jego zaakceptowaniu. Jeśli teraz przyjrzysz się stronie projektu, pokazanej na rysunku 3.16, zapewne zwrócisz uwagę na dwie sprawy.

Rysunek 3.16. Oryginalny projekt (pragmaticlearning) po uwzględnieniu zgłoszenia Po pierwsze, do projektu został dodany plik new_file.md. Po drugie, w oryginalnym projekcie widoczna jest teraz informacja o czterech zmianach. Po kliknięciu odsyłacza 4 commits można się przekonać, dlaczego tak się stało (rysunek 3.17).

Rysunek 3.17. Historia zmian oryginalnego projektu W oryginalnym projekcie były dwie zmiany, doszła do nich kolejna — Create new_file.md, wykonana w moim odgałęzieniu repozytorium, a potem jeszcze jedna, polegająca na scaleniu tej zmiany ze źródłowym repozytorium, co nastąpiło w chwili zatwierdzenia zgłoszenia (merge commit). Tego rodzaju zmiana jest automatycznie generowana przy każdym uwzględnieniu zgłoszenia. Zmiany te są naprawdę przydatne, ponieważ komentarze do nich (które można edytować przed zatwierdzeniem zgłoszenia) pozwalają uargumentować to, dlaczego zdecydowałeś się uwzględnić konkretne modyfikacje. Co więcej, jeśli chciałbyś usunąć wszystkie zmiany wynikłe z zatwierdzenia danego zgłoszenia, możesz po prostu poprosić jednego z członków zespołu o „cofnięcie zmian związanych z danym zgłoszeniem” — dzięki omawianemu rozwiązaniu można to zrobić bez trudu.

Edytowanie pliku Niekiedy rzeczywiście zachodzi potrzeba dodania do projektu nowego pliku, ale na ogół wprowadza się modyfikacje w istniejących plikach. Przypuśćmy, że chciałbyś zmienić treść pliku README.md tak, by poinformować zainteresowanych, w jaki sposób mogą wziąć udział w rozwoju projektu. Aby to zrobić, najpierw wyświetl stronę główną swojej kopii repozytorium projektu, a potem kliknij nazwę pliku README.md. Spowoduje to wyświetlenie strony podobnej do pokazanej na rysunku 3.18.

Rysunek 3.18. Wyświetlanie zawartości pliku README.md Na wspomnianym rysunku widać, kto jako ostatni wprowadzał zmiany w pliku i jak dawno zmiany te zostały dokonane; widzimy też na nim pierwszą linię komentarza do zmiany oraz liczbę osób, które pracowały nad tym plikiem. Powyżej zawartości pliku znajduje się kilka przycisków. Tym razem użyjemy przycisku Edit (edycja). Jego kliknięcie spowoduje wyświetlenie strony podobnej do przedstawionej na rysunku 3.19, umożliwiającej modyfikowanie zawartości pliku.

Rysunek 3.19. Edytowanie pliku README.md Podobnie jak miało to miejsce w wypadku ekranu służącego do tworzenia pliku, po wprowadzeniu żądanych zmian przewiń zawartość strony w dół, po czym wprowadź komentarz do zmiany i kliknij przycisk Commit changes (scal zmiany). Gdy to zrobisz, na ekranie pojawi się strona z zawartością pliku README.md z uwzględnieniem wszystkich wprowadzonych poprawek. Na rysunku 3.20 widoczne są informacje, które dodałem do wspomnianego pliku. Podobnie jak podczas tworzenia nowego pliku, jeśli Twoim celem było wprowadzenie zmian tylko we własnym odgałęzieniu repozytorium, to sprawa załatwiona. Ale jeśli chciałbyś, aby poprawki trafiły do projektu źródłowego pragmaticlearning/githubexample, to musiałbyś utworzyć zgłoszenie. Rysunek 3.20 przedstawia zamknięte zgłoszenie, które specjalnie w tym celu utworzyłem, a potem zatwierdziłem, by wprowadzić zmiany w mojej kopii pliku README.md projektu źródłowego.

Rysunek 3.20. Zatwierdzone zgłoszenie zmiany poprawionego pliku README.md

Zmiana nazwy albo przenoszenie pliku Często trzeba zmienić nazwę pliku albo przenieść go z jednego folderu do drugiego. W repozytoriach Gita i w GitHubie obydwa procesy są tożsame: przy zmianie nazwy pliku opcjonalnie można podać nazwę nowego folderu. W tej części rozdziału przeniosę utworzony wcześniej plik new_file.md do folderu o nazwie documentation i zmienię nazwę tego pliku na chapter_1.md.

Aby to zrobić, najpierw otworzyłem stronę główną mojej kopii repozytorium źródłowego, a następnie kliknąłem nazwę pliku new_file.md, by wyświetlić jego zawartość. Potem zaś kliknąłem przycisk Edit, tak jak we wcześniejszym podrozdziale „Dodawanie pliku”. W rezultacie na ekranie wyświetliła się strona pokazana na rysunku 3.21.

Rysunek 3.21. Ekran edytowania pliku new_file.md Tym razem nie będę edytować treści, lecz skorzystam z pola tekstowego z nazwą pliku, które znajduje się w górnej części tej strony. Jeśli chciałbym tylko zmienić nazwę pliku, pozostawiając go w tym samym folderze, to wystarczyłoby po prostu tę nazwę wpisać. Ale w wypadku przeniesienia pliku do innego folderu (niezależnie od tego, czy on istnieje), trzeba jeszcze uwzględnić nazwę docelowego folderu, zaczynając od oddzielenia jej od nazwy pliku ukośnikiem (/). W tym wypadku w polu z nazwą pliku powinienem więc wpisać tekst documentation/chapter_1.md. Jak widać na rysunku 3.22, od razu po wpisaniu ukośnika GitHub rozpoznaje odwołanie do folderu. Jeśli chciałbym przenieść dany plik w górę drzewa folderów, powinienem zacząć od wpisania znaków ../ w polu przeznaczonym na nazwę pliku.

Rysunek 3.22. Edytowanie folderu lub nazwy pliku Jeśli podczas przenoszenia pliku pomylisz się przy wpisywaniu nazwy docelowego folderu, po prostu kliknij przycisk cancel (anuluj), widoczny na rysunku 3.22, i zacznij wpisywanie raz

jeszcze. Po zmianie nazwy lub przeniesieniu pliku przewiń stronę w dół i zatwierdź wykonaną zmianę. Rysunek 3.23 przedstawia skutek zmiany nazwy pliku i przeniesienia go do folderu /documentation.

Rysunek 3.23. Plik o zmienionej nazwie w folderze /documentation

Praca z folderami Jeśli chodzi o foldery, to warto zacząć od tego, w jaki sposób Git je traktuje — otóż... ignoruje je! W tym sensie, że dla Gita liczą się wyłącznie pliki. Foldery to po prostu miejsca do przechowywania plików. Z tego względu nie da się dodać do projektu folderu, jeśli nie będzie on od razu zawierał co najmniej jednego pliku.

Czasami przysparza to pewnych problemów. Na przykład w wielu projektach aplikacji konieczny jest folder /build, do którego trafiają pliki generowane automatycznie podczas kompilacji programu. W niektórych systemach w wypadku braku takiego folderu nie da się uruchomić projektu.

Tworzenie folderu Często stosowaną metodą jest tworzenie pustego pliku o nazwie .gitkeep w dowolnym folderze, który chciałbyś utworzyć, ale w takim, w którym na razie nie zamierzasz przechowywać plików. To rozwiązanie wydaje się trochę dziwne, lecz jest skuteczne i stało się dość powszechne; jeśli więc będziesz kiedyś chciał utworzyć pusty folder, po prostu umieść w nim plik .gitkeep (rysunek 3.24).

Rysunek 3.24. Folder /build z plikiem .gitkeep

Zmiana nazwy folderu Być może domyślasz się już, że tak jak nie da się bezpośrednio utworzyć folderu, tak też nie da się bezpośrednio zmienić jego nazwy. Z kolei zmiana nazwy pliku umożliwia jednocześnie przeniesienie go do innego folderu. Aby na przykład przenieść plik chapter_1.md z folderu documentation do folderu new_docs, kliknij odsyłacz Edit i w polu tekstowym zacznij wpisywać nową nazwę od znaków ../, aby przenieść się w górę drzewa folderów o jeden poziom. Potem zaś wpisz new_docs, by utworzyć folder o takiej nazwie lub po prostu umieścić w nim plik, jeśli folder ten już istnieje. W GitHubie nie da się jednak zwyczajnie zmienić nazwy folderu. Trzeba zmienić nazwy wszystkich plików w tym folderze po kolei, przenosząc je jednocześnie do nowego folderu.

Ograniczenia edytowania w serwisie GitHub Właśnie poznałeś jedno z ograniczeń funkcjonalności serwisu GitHub. Początkowo GitHub miał umożliwiać programistom udostępnianie swoich repozytoriów. Programiści wprowadzali zmiany w projektach lokalnie, na przykład na swoich laptopach, zapisywali te zmiany w Gicie i przesyłali rezultaty do GitHuba. Teraz, gdy za pośrednictwem GitHuba współpracuje coraz więcej osób bez zaawansowanej wiedzy technicznej, wiele prac związanych z edycją projektu da się wykonać bezpośrednio w serwisie, ale są rzeczy, których nie można zrobić za pośrednictwem interfejsu WWW. Obecnie GitHub nie pozwala na przykład na zmianę nazwy folderu albo zmodyfikowanie kilku plików w ramach jednej zmiany (commit). Serwis WWW jest też pozbawiony narzędzi Gita służących do edytowania historii repozytorium i nie pozwala na rozwiązywanie konfliktów online. Jeśli więc jakieś zgłoszenie koliduje z innym, ktoś będzie musiał pobrać kopię repozytorium (sklonować je), wprowadzić zmiany i przesłać całość z powrotem do GitHuba.

Jeśli chcesz poznać podstawy pracy lokalnej z Gitem, zajrzyj do rozdziału 6., w którym znajdziesz wskazówki ułatwiające rozpoczęcie korzystania z klienta GitHuba w wersji dla systemów Mac OS lub Windows. Tymczasem jednak przyjrzymy się, w jaki sposób można skutecznie współpracować w zespole za pośrednictwem GitHuba.

ROZDZIAŁ 4.

Współpraca Ten rozdział zaczniemy od omówienia metod bezpośredniej współpracy nad jednym repozytorium bez użycia odgałęzień (forków). Następnie poświęcimy trochę miejsca na bliższe przyjrzenie się pracy zespołowej z użyciem zgłoszeń i problemów. Zajmiemy się też tworzeniem stron WWW w GitHubie.

Odgałęzienia całego repozytorium stanowią dobry sposób na wykorzystywanie prac wykonanych przez osoby, z którymi nie współpracuje się regularnie, lecz w wypadku stałego zespołu bywają zbyt kłopotliwe. Z tego względu w zespole na ogół pracuje się na jednym, wspólnym repozytorium. Nawet wtedy jednak warto pamiętać o użyciu gałęzi i zgłoszeń przy odrębnych wątkach prac.

Wprowadzanie zmian w odgałęzieniu W ramach organizacji pragmaticlearning (https://github.com/pragmaticlearning) utworzyłem repozytorium o nazwie single-repo-example (https://github.com/pragmaticlearning/single-repo-example), pokazane na rysunku 4.1.

Jeśli chciałbym na przykład rozbudować treść pliku README.md, to najpierw powinienem utworzyć gałąź. Dzięki temu będę mógł odseparować swoje zmiany od głównego repozytorium. Aby to zrobić, można po prostu kliknąć przycisk branch:master (gałąź:główna).

Na ekranie pojawi się wtedy rozwijana lista bieżących gałęzi projektu oraz pole tekstowe umożliwiające wpisanie nazwy gałęzi istniejącej lub nowej, którą zamierzam utworzyć. Ten etap pracy jest zilustrowany na rysunku 4.2.

Rysunek 4.1. Repozytorium single-repo-example

Rysunek 4.2. Lista gałęzi Po utworzeniu nowej gałęzi, na przykład o nazwie update_readme, jak na rysunku 4.3, GitHub automatycznie przełączy się na nią. Widać to zarówno na wspomnianym wcześniej przycisku, na którym jest wyświetlona nazwa aktualnej gałęzi, jak i na pasku adresu przeglądarki, na którym wyświetlony adres kończy się teraz nazwą tree/update_readme, co oznacza, że

jesteśmy w gałęzi o nazwie update_readme.

Rysunek 4.3. Gałąź update_readme Kolejny krok polega na wprowadzeniu żądanych poprawek. Na potrzeby tego przykładu zmodyfikowałem zatem plik README.md i zatwierdziłem zmiany. Jak widać na rysunku 4.4, w gałęzi głównej projektu mam tylko jedną, początkową zmianę (initial commit), ale jeśli spojrzysz na rysunek 4.5, gdzie przełączyłem się na gałąź update_readme, to oprócz zmiany inicjalizującej tę gałąź dostrzeżesz także drugą zmianę, którą w niej wykonałem.

Rysunek 4.4. W gałęzi głównej nadal widnieje tylko jedna zmiana

Rysunek 4.5. Tymczasem w gałęzi update_readme są już dwie zmiany Teraz mogę kontynuować pracę w tej gałęzi, aż wprowadzę wszystkie niezbędne modyfikacje.

A gdy będę gotowy do wysłuchania opinii na temat proponowanych przez siebie zmian, powinienem utworzyć zgłoszenie, by rozpocząć dyskusję na ich temat.

Tworzenie zgłoszenia z poziomu gałęzi Aby utworzyć zgłoszenie, podobnie jak w poprzednim rozdziale, należy kliknąć zakładkę Pull Requests (zgłoszenie), znajdującą się w prawej części strony głównej projektu, potem zaś należy kliknąć zielony przycisk tworzenia nowego zgłoszenia. Tutaj, jak widać na rysunku 4.6, zaczynają się pewne różnice. Teraz GitHub nie jest pewien, jakich gałęzi ma dotyczyć zgłoszenie, więc muszę mu to podpowiedzieć.

Rysunek 4.6. Inicjowanie zgłoszenia z poziomu gałęzi Po lewej stronie mamy gałąź base:master. To znakomicie, bo jeśli utworzone w ten sposób zgłoszenie będzie zatwierdzone, zostanie ono scalone z gałęzią główną — a dokładnie na tym

mi zależy. Muszę jednak kliknąć przycisk, na którym widnieje nazwa gałęzi compare:master, aby poinformować GitHub, z której gałęzi będzie pochodziło zgłoszenie (rysunek 4.7).

Zmiana, jaką planuję wprowadzić w gałęzi głównej, pochodzi z gałęzi update_readme.

Rysunek 4.7. Wybór gałęzi do utworzenia zgłoszenia Po wybraniu gałęzi proces przebiega tak samo jak w rozdziale 3., w którym opisywałem tworzenie zgłoszenia z poziomu forka repozytorium. Po kliknięciu przycisku Create pull request (utwórz zgłoszenie) należy wprowadzić opis wyjaśniający przyczyny zgłoszenia oraz jego tytuł, a potem po raz kolejny kliknąć przycisk o tej samej nazwie. Utworzone w ten sposób zgłoszenie zostało pokazane na rysunku 4.8.

Rysunek 4.8. Nowe zgłoszenie

Współpraca przy zgłoszeniach Zgłoszenia, czyli pull requests, są metodą na zapoczątkowanie dyskusji o proponowanej zmianie — zwykle nowej funkcji albo poprawce błędu. Początkowo zgłoszenia były tworzone tylko po ukończeniu jakiegoś etapu kodowania, by poprosić kogoś o włączenie gotowych zmian do projektu, ale obecnie zgłoszeń używa się do różnych celów.

Nawet jeśli zamierzasz wykonać zmianę, co do której nie masz żadnych wątpliwości, to i tak możesz utworzyć dla niej nową gałąź, wprowadzić wszystkie poprawki i zgłosić je dopiero wtedy, gdy będą gotowe. W takim wypadku zgłoszenie jest czymś w rodzaju dodatkowego zabezpieczenia, pozwalającego zyskać pewność, że reszta zespołu zgadza się z proponowanymi przez Ciebie zmianami, zanim zostaną one włączone do głównej gałęzi i produkcyjnej wersji projektu.

Istnieje jeszcze inny sposób posługiwania się zgłoszeniami. W wielu firmach pracownicy często tworzą zgłoszenia dla funkcji, o których chcieliby podyskutować. Jeśli masz pomysł na zmianę, ale nie jesteś pewien, czy jest dobry, to rozważ utworzenie gałęzi i zacznij pracę nad tą zmianą od absolutnych podstaw — na przykład utwórz krótki plik tekstowy z jej opisem. Po dokonaniu w swojej gałęzi zmiany polegającej na utworzeniu takiego pliku możesz wykorzystać tę zmianę do utworzenia zgłoszenia, by zainicjować rozmowę na temat swojego pomysłu.

Zaangażowanie konkretnych osób w zgłoszenie Jeśli po utworzeniu zgłoszenia chciałbyś uzyskać opinie na jego temat od konkretnych osób z zespołu, musisz o nich „wspomnieć” przy użyciu znaku @ i nazwy użytkownika (jest to tzw. wzmianka, ang. at mention). Aby to zrobić, w zgłoszeniu albo komentarzu do niego wpisz znak @, a potem nazwę użytkownika GitHuba. Jeśli dana osoba jest właścicielem projektu albo współpracownikiem, serwis sam będzie sugerował odpowiednie nazwy podczas wpisywania.

Jeżeli na przykład chciałbym uzyskać opinię Brenta Beera (członka zespołu szkoleniowego GitHuba i współautora tej książki) na temat moich sugestii, to mógłbym utworzyć komentarz w rodzaju: „Cześć @brntbeer, mógłbyś zerknąć na to zgłoszenie i powiedzieć, co o nim sądzisz?”. Oficjalność sformułowań w takim zapytaniu zależy od tego, z kim współpracujesz, ale komentarze do zmian są często pisane w luźny, nieformalny sposób.

Przeglądanie zgłoszeń Jeśli chciałbyś zobaczyć, nad czym aktualnie pracują osoby zaangażowane w projekt, otwórz stronę główną tego projektu i kliknij zakładkę Pull Requests po prawej stronie. Na ekranie pojawi się lista wszystkich otwartych zgłoszeń.

W większości projektów jest otwartych na ogół tylko kilka zgłoszeń naraz. W wypadku prywatnych repozytoriów warto przestrzegać zasady, że na jednego programistę powinno przypadać maksymalnie jedno lub dwa otwarte zgłoszenia. Zasadniczo im mniej zgłoszeń jest otwartych, tym lepiej, bo zespół powinien przedkładać dokończenie prac nad istniejącymi funkcjami nad rozpoczęcie nowych. Liczba otwartych zgłoszeń w projektach open source jest jednak na ogół znacznie większa, ponieważ zgłoszenie może utworzyć każdy, a jego analiza, akceptacja i (lub) zamknięcie przez zespół projektowy może trochę potrwać.

Po znalezieniu zgłoszenia, którym chciałbyś się zająć, kliknij je, aby wyświetlić jego szczegóły.

Komentowanie zgłoszeń Bardzo ważnym aspektem pracy w zespole projektowym jest analiza dotyczących Cię zgłoszeń. Nie ma nic bardziej frustrującego od kompletnego braku odzewu na zgłoszenie dotyczące funkcji, nad którą pracowałeś kilka dni. Pamiętaj też, że każdy może zgłosić swoją zmianę do gałęzi głównej, warto więc poświęcić trochę czasu na przyjrzenie się pracy innych ludzi, by tym samym nie zachęcać ich do samodzielnego scalania zmian, zanim co najmniej jedna albo dwie inne osoby się im przyjrzą.

Za każdym razem, gdy otrzymasz e-mail albo powiadomienie na stronie WWW, że zostałeś wspomniany w zgłoszeniu (za pomocą znaku @ i Twojej nazwy), zerknij na nie najszybciej, jak się da, i wprowadź stosowny komentarz. A nawet jeśli nikt nie wywoła Cię do tablicy osobiście, poświęć codziennie kilka chwil na przejrzenie zalegających zgłoszeń i opatrz je komentarzem, by sprecyzować dalszy kierunek zmian w projekcie.

Komentowanie zgłoszeń jest bardzo proste. Wystarczy przewinąć w dół zawartość strony z opisem zgłoszenia, wpisać komentarz w polu na samym dole i kliknąć przycisk Comment (komentuj).

Uatrakcyjnianie komentarzy Komentowanie zgłoszeń to jedna z najczęstszych form kontaktu w zespole, zwłaszcza w takim, który nie pracuje przez cały czas wspólnie, w jednym biurze. Z tego względu od czasu do czasu warto trochę uatrakcyjnić dyskusję.

GitHub ma wbudowaną obsługę emotikonów (emoji). Emotikony to niewielkie obrazki służące do wyrażania nastroju albo emocji w graficzny sposób. Komentarz pokazany na rysunku 4.9 zawiera emotikony :+1: (podoba mi się ta funkcja) oraz :ship:1 (włączmy to do projektu).

Rysunek 4.9. Komentarz z emotikonami Jeśli chcesz zapoznać się z wybranymi emotikonami dostępnymi w GitHubie, odwiedź stronę ze „ściągą” (http://www.emoji-cheat-sheet.com/), której fragment pokazano na rysunku 4.10.

Rysunek 4.10. Ściąga z dostępnymi emotikonami

Inny sposób na ubarwianie komentarzy w GitHubie polega na zastosowaniu animowanych GIF-ów. O ile emotikony są raczej subtelne, o tyle wiele spośród animowanych GIF-ów jest znacznie większych od emotikonów i robi adekwatnie większe wrażenie — często są one używane w żartobliwym charakterze albo w celu wyrażenia zdecydowanego wsparcia (lub dezaprobaty) dla zmiany lub komentarza. Aby dodać animowany GIF (albo inny obrazek) do zgłoszenia, wystarczy przeciągnąć go do pola komentarza; zostanie on wysłany automatycznie.

Modyfikowanie zgłoszeń Może się zdarzyć, że będziesz chciał wprowadzić zmianę bezpośrednio w zgłoszeniu. Być może na przykład ktoś zaprojektował nową stronę WWW, a Ty chciałbyś wprowadzić na niej drobne zmiany w tekście marketingowym, poprawki natury prawnej albo nawet modyfikacje w CSS-ie, by całość lepiej się wyświetlała w Twojej ulubionej przeglądarce. Wprowadzanie poprawek w zgłoszeniu utworzonym przez kogoś innego jest proste.

Proces przebiega tak samo jak podczas edytowania pliku, o czym mogłeś przeczytać w poprzednim rozdziale. Jedyna różnica polega na tym, że należy wyświetlić właściwą gałąź. Na potrzeby tego przykładu wziąłem na warsztat zgłoszenie z gałęzi update_readme, w którym chcę trochę rozbudować zawartość pliku README.md, jak na rysunku 4.11.

Jeśli uznałbym, że w pliku powinien się znaleźć krótki przewodnik dla osób chętnych do podjęcia współpracy przy projekcie, to zamiast zgłaszać, że w pliku README.md nie ma takiego przewodnika, mógłbym napisać go sam.

Aby wprowadzić taką zmianę, wystarczy otworzyć stronę główną projektu i z listy dostępnych gałęzi wybrać gałąź update_readme. Po kliknięciu, kolejno, pliku oraz przycisku Edit (edycja) na ekranie pojawi się strona edycji pliku (rysunek 4.12).

Rysunek 4.12. Edytowanie pliku README.md w gałęzi update_readme

Rysunek 4.11. Zgłoszenie z gałęzi update_readme Po wprowadzeniu zmian należy przewinąć stronę w dół i wpisać komentarz do poprawek, jak na rysunku 4.13.

Rysunek 4.13. Dodawanie komentarza do zmiany Jak widać na rysunku 4.14, moja poprawka została już uwzględniona na stronie zgłoszenia.

Każdy, kto obserwował to zgłoszenie, otrzyma powiadomienie, że zostało ono zaktualizowane, a następnie może ocenić moją poprawkę i ją skomentować.

Rysunek 4.14. Nowa zmiana w zgłoszeniu

Testowanie zgłoszenia Jeśli jesteś programistą, to przed zatwierdzeniem zgłoszenia dotyczącego daleko idących modyfikacji kodu, których działania nie da się ocenić na oko, powinieneś pobrać kopię repozytorium (sklonować je). W tak utworzonej kopii możesz otworzyć gałąź, której dotyczy zgłoszenie, przeprowadzić automatyczne testy, by się przekonać, czy wszystkie kończą się powodzeniem, potem uruchomić kod i być może poddać go jakimś manualnym weryfikacjom, aby się upewnić, że spełnia swoje zadanie. O klonowaniu repozytoriów przeczytasz w rozdziale 6.

Jeśli nie jesteś programistą, możesz zostawić to zadanie swojemu zespołowi, ale wówczas zadbaj o to, by co najmniej jeden albo dwóch współpracowników pobrało kod i przed zatwierdzeniem zgłoszenia uruchomiło automatyczne testy, a potencjalnie przeprowadziło także kilka testów manualnych.

Akceptowanie zgłoszenia Gdy będziesz gotowy do akceptacji zgłoszenia, po prostu kliknij duży zielony przycisk z napisem Merge pull request (scal zgłoszenie), widoczny na rysunku 4.15.

Rysunek 4.15. Przycisk Merge pull request Gdy to zrobisz, GitHub poprosi Cię o wpisanie komentarza do zmiany (domyślnie będzie to tytuł zgłoszenia), co pokazano na rysunku 4.16. Po wprowadzeniu komentarza kliknij przycisk Confirm merge (potwierdź scalenie). Zgłoszenie zostanie wówczas włączone do projektu i zamknięte, jak opisano to w rozdziale 3.

Rysunek 4.16. Zamykanie zgłoszenia Zamykanie zgłoszeń powinno podlegać pewnym regułom. W wielu zespołach wymaga się, by jedna albo dwie osoby (oprócz głównego autora) zagłosowały :+1: przed wdrożeniem zgłoszenia. Reguły te powinny być jednak proste. Pamiętaj, że scalenie zmiany zawsze można cofnąć, zwykle więc lepiej działać i (od czasu do czasu) coś zepsuć, niż kazać wszystkim dwudziestu siedmiu osobom z listy akceptować każde zgłoszenie, by mogło ono zostać scalone.

Kto powinien akceptować zgłoszenia?

Stosunkowo często powtarza się pytanie o to, czy zgłoszenie powinno być potwierdzone przez osobę, która je utworzyła, czy przez kogoś innego. Zasadniczo zalecam, by zgłoszenia były potwierdzane przez ich autorów. Już tłumaczę dlaczego.

W wielu firmach funkcjonuje reguła: „ten, kto utworzył zgłoszenie, nie może go akceptować”.

Przesłanką przemawiającą za takim rozwiązaniem jest chęć uniknięcia sytuacji, w której ktoś generuje zgłoszenie i scala je, nie czekając na opinie. Przesłanka ta jest wprawdzie słuszna, ale nie sądzę, by takie postępowanie było najlepszym wyjściem.

W większości sytuacji autor zgłoszenia wie na jego temat najwięcej. To sprawia, że zawsze

chcę, by był obecny przy scalaniu danej zmiany — choćby w razie nieoczekiwanych problemów. Jeden z najprostszych sposobów na to, by mieć pewność, że osoba ta rzeczywiście będzie obecna przy zmianie, polega na poproszeniu jej o wykonanie tejże zmiany. Z tego względu zalecam, by prosić autorów zgłoszeń o ich potwierdzenie, ale nie wcześniej, niż otrzymają od reszty zespołu zielone światło w postaci kilku pozytywnych opinii (:+1:).

Powiadomienia o zgłoszeniach Jeśli będziesz autorem zgłoszenia, skomentujesz je, wprowadzisz w nim zmiany albo w sytuacji, gdy ktoś @wspomni w nim o Tobie — domyślnie staniesz się subskrybentem takiego zgłoszenia. To oznacza, że gdy ktokolwiek skomentuje zgłoszenie, wprowadzi w nim zmiany, scali je albo zamknie, zostaniesz o tym powiadomiony. Informacja znajdująca się w sekcji Notifications (powiadomienia), widocznej w prawej części rysunku 4.17, świadczy o tym, że jestem obecnie subskrybentem pewnego zgłoszenia.

Rysunek 4.17. Jestem na liście subskrybentów tego zgłoszenia Jeśli przestanie Cię interesować zgłoszenie, którego jesteś subskrybentem, po prostu kliknij przycisk Unsubscribe (zrezygnuj), by przestać otrzymywać informacje na jego temat. W sytuacji, gdy ktokolwiek @wspomni o Tobie w komentarzach do tego zgłoszenia, zostaniesz ponownie zapisany na listę subskrybentów. Jeśli nie jesteś subskrybentem informacji o zgłoszeniu, które chciałbyś śledzić, po prostu kliknij przycisk Subscribe (subskrybuj), widoczny w prawej części rysunku 4.18. Od tej pory będziesz powiadamiany o wszelkich działaniach związanych z tym zgłoszeniem.

Rysunek 4.18. Przycisk Subscribe widoczny na stronie zgłoszenia

Zalecenia dotyczące zgłoszeń Istnieje kilka ogólnych zaleceń dotyczących obsługi zgłoszeń — warto o nich pamiętać: Twórz zgłoszenia dla wszystkich podejmowanych działań.

Za każdym razem, gdy chcesz usunąć błąd albo dodać nową funkcję, upewnij się, że robisz to na osobnej gałęzi, a potem utwórz zgłoszenie dla zmiany, aby zebrać opinie na jej temat przed włączeniem do gałęzi głównej.

Stosuj zrozumiałe tytuły.

Inni członkowie zespołu będą przeglądali zgłoszenia, aby się zorientować w sytuacji.

Tytuł powinien być dobrą wskazówką na temat tego, nad czym obecnie pracujesz.

Nie żałuj czasu na komentowanie.

Nawet jeśli nie zostaniesz @wspomniany, będziesz miał lepszą orientację co do rozwoju projektu i korzystnie wpłyniesz na jakość pracy całego zespołu. @wspominaj najważniejsze osoby.

Jeśli zależy Ci na uzyskaniu uwag z działu marketingu, opinii prawnej albo jeśli chcesz poznać zdanie zespołu wykonawczego, @wspomnij kluczowych użytkowników. W ten sposób zyskasz pewność, że nie przegapią zgłoszenia, i zwiększysz swoje szanse na otrzymanie cennych komentarzy.

Przeprowadzaj testy.

Upewnij się, że chociaż jeden programista pobierze najnowsze zmiany wprowadzone w zgłoszeniu, zweryfikuje odpowiednią gałąź i uruchomi automatyczne testy. W wypadku nietrywialnych zmian nie wystarczy ocena kodu na oko.

Opracuj logiczną i jasną procedurę zatwierdzania zgłoszeń.

Większość firm wymaga, by co najmniej jedna lub dwie osoby (inne niż autor) oceniły zgłoszenie i opatrzyły je komentarzem :+1:, zanim zgłoszenie to będzie mogło zostać zatwierdzone.

O ile zgłoszenia są używane do wspólnej pracy nad określonymi zadaniami, o tyle narzędzie Issues (problemy) służy do opisywania znalezionych błędów lub przedstawiania nowych funkcji, nad którymi warto się zastanowić i które ewentualnie warto zacząć realizować.

Problemy Issues w GitHubie to wygodne, łatwe w obsłudze narzędzie służące do zarządzania niewykonanymi jeszcze pracami — na przykład błędami, które nie zostały naprawione, lub nowymi funkcjami czekającymi na zrealizowanie.

Zwykle, gdy przystępuję do pracy nad nowym projektem, zarówno w kwestii błędów, jak i nowych funkcji korzystam z narzędzia Issues, zaś po inne aplikacje, takie jak Pivotal Tracker, JIRA, LightHouse, Trello albo Asana, sięgam tylko wtedy, gdy potrzebuję funkcji

niedostępnych w GitHubie.

Definiowanie nowego problemu Aby zdefiniować nowy problem, kliknij zakładkę Issues (problemy), a potem — przycisk New issue (nowy problem), widoczny na rysunku 4.19.

Po kliknięciu przycisku New issue na ekranie pojawi się formularz podobny do pokazanego na rysunku 4.20 — w formularzu tym można wpisać szczegółowe informacje na temat dokumentowanego zagadnienia.

Rysunek 4.19. Strona z widocznym przyciskiem New issue

Rysunek 4.20. Formularz nowego problemu Wpisz zrozumiały tytuł, który pozwoli innym współpracownikom szybko zorientować się, z jakiego rodzaju błędem albo funkcją mają do czynienia. Jeśli wiesz, kto powinien zająć się danym problemem, możesz wybrać tę osobę z listy współpracowników znajdującej się po prawej stronie napisu No one is assigned (nikt nie został przydzielony). Nieco dalej, po prawej stronie, widnieje kolejna lista, z której możesz wybrać kamień milowy, jeśli chcesz powiązać problem ze sprintem2 lub w inny sposób określić graniczną datę jego rozwiązania.

Poniżej, w polu przeznaczonym na komentarz, podaj obszerniejszy opis problemu. Zwróć uwagę na zestaw kolorowych etykiet, umieszczony po prawej stronie. Zaznacz wszystkie etykiety mające zastosowanie do danego problemu, a potem, by zakończyć jego definiowanie, kliknij przycisk Submit new issue (zgłoś nowy problem), znajdujący się na dole strony.

Zarządzanie kamieniami milowymi w ramach problemów Funkcja kamieni milowych jest często używana w celu powiązania problemu z konkretnym sprintem albo określenia terminu jego rozwiązania w inny sposób, narzucony przez wymogi zewnętrzne (np. „29 lipca, prezentacja dla inwestorów”). Aby utworzyć nowy kamień milowy, kliknij zakładkę Issues (problemy), widoczną po prawej stronie. Następnie kliknij przycisk Milestones (kamienie milowe) w lewej górnej części ekranu, znajdujący się obok przycisków Issues (problemy), Pull requests (zgłoszenia) i Labels (etykiety). Na ekranie pojawi się strona o podobnej strukturze jak w wypadku problemów i zgłoszeń, z przyciskiem New milestone (nowy kamień milowy), który jest widoczny na rysunku 4.21.

Rysunek 4.21. Strona z widocznym przyciskiem New milestone Po kliknięciu przycisku New milestone na ekranie pojawi się formularz podobny do pokazanego na rysunku 4.22 — w formularzu tym należy podać tytuł, natomiast opis oraz data upłynięcia terminu są opcjonalne.

Rysunek 4.22. Dodawanie nowego kamienia milowego Wpisz przynajmniej tytuł i kliknij przycisk Create milestone (utwórz kamień milowy), znajdujący się w prawej dolnej części strony. Na liście kamieni milowych pojawi się wtedy nowa pozycja, jak widać na rysunku 4.23. Kamienie milowe można edytować, zamykać i usuwać, a także przeglądać listy problemów powiązane z każdym z nich.

Rysunek 4.23. Nowy kamień milowy

Zarządzanie etykietami w ramach problemów Zapewne będziesz chciał utworzyć jakieś niestandardowe etykiety dla projektu. Kliknij przycisk Labels (etykiety), znajdujący się w lewej górnej części ekranu, obok przycisków Issues (problemy), Pull requests (zgłoszenia) oraz Milestones (kamienie milowe). Na stronie, która się wówczas pojawi (rysunek 4.24), będziesz mógł edytować tytuły oraz kolory etykiet, a także usuwać etykiety i tworzyć nowe.

Rysunek 4.24. Strona Labels Aby usunąć etykietę, kliknij przycisk Delete (usuń), znajdujący się po prawej stronie danej etykiety, w jej wierszu. W celu zmodyfikowania etykiety kliknij przycisk Edit (edycja).

Będziesz mógł wtedy zmienić treść etykiety oraz jej kolor, co pokazano na rysunku 4.25.

Rysunek 4.25. Edytowanie etykiety Jeśli chciałbyś utworzyć nową etykietę, kliknij przycisk New label (nowa etykieta). Na ekranie pojawi się wtedy pole tekstowe z listą kolorów do wyboru oraz przycisk Create label (utwórz etykietę), jak na rysunku 4.26.

Rysunek 4.26. Dodawanie nowej etykiety

Komentowanie problemów Proces jest taki jak w wypadku zgłoszeń: • Aby dodać komentarz do problemu, kliknij ten problem, przewiń stronę w dół aż do pola tekstowego, wpisz w nim komentarz i kliknij przycisk Comment (komentuj).

• Pamiętaj, by codziennie poświęcać trochę czasu na sprawdzanie, czy pojawiły się jakieś nowe problemy, oraz by odpowiadać jak najszybciej na @wzmianki odnoszące się do Ciebie.

• Nie wahaj się używać emotikon i animowanych GIF-ów, by trochę urozmaicić pracę.

Odwoływanie się do problemów w zmianie

Jeśli wprowadzisz zmianę, która odwołuje się do jakiegoś problemu albo naprawia opisany w nim błąd, wstaw znak krzyżyka (#) z numerem tego problemu w komentarzu do zmiany. Taka zmiana będzie wyświetlana w historii danego problemu. Jeśli dana zmiana rozwiązuje problem, a Ty poprzedzisz jego numer słowem kluczowym, takim jak closes, fixes albo resolves, to gdy ta zmiana zostanie włączona do gałęzi domyślnej projektu (zwykle master), problem zostanie automatycznie zamknięty.

Zalecenia dotyczące problemów Oto kilka wartych zapamiętania zaleceń dotyczących zastosowania narzędzia Issues w GitHubie: Utwórz etykiety takie jak Bug (błąd) i Feature (funkcja).

W ten sposób ułatwisz sobie znalezienie nierozwiązanych problemów z błędami albo funkcjami.

Używaj kamieni milowych, jeśli pasuje to do specyfiki Twojej pracy.

Jeśli pracujesz pod dyktando narzuconych terminów albo w rytm wewnętrznej metodyki, na przykład sprintów, to skorzystaj z kamieni milowych, by przypisać konkretnym problemom daty rozwiązania. Jeśli nie musisz przestrzegać terminów dostarczania produktów, rozważ użycie kamieni milowych (bez dat) do tematycznego pogrupowania zadań. Możesz na przykład zdefiniować kamień milowy w postaci: „Całkowita zmiana wyglądu strony”, a po nim kolejny — o treści: „Dodanie sklepu internetowego”.

Uważaj podczas przypisywania problemów.

Na ogół lepiej jest, jeśli członkowie zespołu projektowego sami wybierają problemy, którymi są zainteresowani, niż wtedy, gdy trzeba je im narzucać.

Często posługuj się etykietami.

Oprócz stosowania etykiet „wysokiego poziomu”, umożliwiających odróżnienie problemów dotyczących błędów od tych związanych z funkcjami, etykiet można używać w wielu innych celach. Rozważ dodanie etykiet pozwalających śledzić stan prac, przypisywać różnym zespołom zadania („iOS”, „skrypty serwerowe”, „frontend” itp.), a nawet śledzić inne ciekawe informacje, na przykład dotyczące wagi błędu albo celu biznesowego nowej funkcji.

Wiki Na pewnym etapie życia projektu plik README.md stanie się zbyt długi, by można było wygodnie się nim posługiwać. W takim momencie (a nawet wcześniej) warto rozważyć zastosowanie funkcji wiki, w którą jest wyposażony GitHub. Wiki to bardzo prosty system zarządzania treścią, ułatwiający zespołowi projektowemu utworzenie zbioru połączonych ze sobą stron internetowych. Wiki w GitHubie są zwykle używane do gromadzenia dokumentacji dla użytkownika, dokumentacji projektowej lub ich

obydwu — dzięki temu komplet informacji związanych z projektem jest dostępny za pośrednictwem jego strony w GitHubie.

Rozpoczęcie pracy z wiki Jeśli Twój projekt nie jest jeszcze wyposażony w wiki, zacznij od kliknięcia zakładki Settings (ustawienia) i przewinięcia wyświetlonej strony w dół, do sekcji Features (funkcje), widocznej na rysunku 4.27. Upewnij się, że pole opcji obok pozycji Wikis (wiki) jest zaznaczone. Jeśli zamierzasz utworzyć projekt publiczny, ale chciałbyś ograniczyć dostęp do niego tak, by tylko członkowie zespołu mogli aktualizować dokumentację w wiki, zaznacz też kolejną opcję.

Rysunek 4.27. Sprawdzanie, czy mechanizm wiki jest włączony Gdy upewnisz się, że mechanizm wiki jest włączony, kliknij zakładkę Wiki (wiki) w prawej części dowolnej podstrony projektu. Jeśli dotychczas jeszcze nie edytowałeś wiki, na ekranie pojawi się strona podobna do pokazanej na rysunku 4.28.

Kliknij zielony przycisk z napisem Create the first page (utwórz pierwszą stronę), aby wyświetlić stronę przypominającą tę, którą przedstawiono na rysunku 4.29.

Domyślnie pierwsza strona nosi nazwę Home (strona główna), ale jej tytuł możesz zmienić na dowolny. Potem zaś możesz przystąpić do edytowania treści w głównym polu tekstowym.

Zauważ, że ponad obszarem edycji tekstu znajduje się kilka przycisków umożliwiających zmianę stylów treści; nie jest to jednak edytor typu WYSIWYG (czyli „dostajesz to, co widzisz”).

Rysunek 4.28. Domyślna strona wiki

Rysunek 4.29. Tworzenie pierwszej strony w wiki Przyciski powodują po prostu wstawienie odpowiednich znaczników w polu tekstowym. Jeśli chciałbyś się przekonać, jak będzie wyglądać tworzony materiał, kliknij zakładkę Preview (podgląd) ponad paskiem z przyciskami formatowania — na ekranie pojawi się wtedy podgląd strony z uwzględnieniem znaczników stylów, jak na rysunku 4.30.

Po kliknięciu rozwijanej listy Edit mode (tryb edycji) możesz wybrać jedną z opcji formatowania składni (rysunek 4.31). Osobiście zalecam wybranie domyślnej opcji Markdown (znaczniki), gdyż jest ona zgodna z formatem stosowanym przez zespół GitHuba i jest wykorzystywana w różnych obszarach tego serwisu, na przykład w komentarzach do problemów i zgłoszeń.

Rysunek 4.30. Podgląd nowej strony w wiki

Rysunek 4.31. Inne sposoby formatowania Po zakończeniu pracy nad treścią wpisz w polu Edit Message (edytuj wiadomość) krótki opis przyczyn wprowadzenia zmiany, a potem kliknij przycisk Save Page (zapisz stronę).

Dodawanie stron do wiki i odwoływanie się do nich Za każdym razem, gdy będziesz chciał dodać do wiki nową stronę, po prostu kliknij przycisk New Page (nowa strona), znajdujący się w prawym górnym rogu dowolnej strony wiki. Po dodaniu strony pojawi się ona w sekcji Pages (strony) w prawej części ekranu, jak widać na rysunku 4.32.

Aby umieścić na stronie odsyłacz prowadzący do innej strony, najpierw, za pomocą listy Pages (strony), odszukaj tę, do której chciałbyś dodać odsyłacz. Następnie skopiuj adres URL tej strony z przeglądarki do schowka; za chwilę się nam przyda. Potem, przy użyciu listy Pages, odszukaj stronę, na której chcesz umieścić odsyłacz. Kliknij przycisk Edit (edycja) w

prawej

Rysunek 4.32. Lista stron w wiki górnej części tej strony. Znajdź w treści strony miejsce, w którym chcesz umieścić odsyłacz, i kliknij przycisk odsyłacza na pasku narzędzi (przypomina dwa złączone ogniwa łańcucha). Na ekranie pojawi się wtedy okno dialogowe widoczne na rysunku 4.33.

Rysunek 4.33. Okno dialogowe Insert Link (wstawianie odsyłacza) W pierwszym polu wpisz treść odsyłacza — najlepiej kojarzącą się ze stroną, na którą ów odsyłacz będzie prowadzić. Potem zaś w polu URL wklej adres URL strony wiki, skopiowany wcześniej do schowka.

Jeśli chcesz w pełni wykorzystać możliwości wiki (a także komentarzy do problemów lub zgłoszeń), zapoznaj się ze stroną poświęconą znacznikom dostępnym w GitHubie (https://github.github.com/github-flavored-markdown/).

Informacyjne strony WWW w GitHubie Strony wiki to doskonałe narzędzie do tworzenia dokumentacji w GitHubie, a dzięki temu, że znajdują się w tym samym serwisie, co kod, jest spora szansa, że będą aktualizowane częściej

niż zupełnie osobny dokument. Czasami jednak zachodzi potrzeba utworzenia bardziej wyrafinowanej strony internetowej, na której będziesz mógł zamieszczać informacje o sobie, swojej organizacji i projekcie. W takich sytuacjach w sukurs przychodzi narzędzie Pages (strony), umożliwiające projektowanie i hosting stron WWW bezpośrednio w GitHubie.

Tworzenie strony internetowej dla projektu Zawsze, gdy tworzysz w GitHubie nowe repozytorium, masz możliwość dodania do niego strony internetowej z informacjami mającymi na celu promocję lub przedstawienie projektu.

Aby zapoznać się z możliwościami GitHuba w tym zakresie, kliknij przycisk Settings (ustawienia), a potem — przycisk Automatic page generator (automatyczny generator stron).

Na ekranie pojawi się strona przypominająca tę pokazaną na rysunku 4.34.

Rysunek 4.34. Formularz generowania stron WWW w GitHubie Formularz ten umożliwia wprowadzenie nazwy projektu, sloganu i głównej części strony, w ramach której możesz wstępnie opracować treść z użyciem znaczników. Jeśli chcesz, możesz też dodać identyfikator serwisu Google Analytics, pozwalający rejestrować historię odwiedzin. Po zakończeniu pracy z pierwszą stroną kliknij przycisk Continue to layouts (przejdź do szablonów), który spowoduje wyświetlenie strony podobnej do pokazanej na rysunku 4.35. Na tej stronie możesz wybrać jeden z predefiniowanych motywów graficznych, będący punktem wyjścia do dalszej pracy.

Rysunek 4.35. Wybór szablonu dla strony WWW w GitHubie Po wybraniu projektu kliknij przycisk Publish page (publikuj stronę) w prawej górnej części ekranu, by utworzyć stronę. Gotową stronę można obejrzeć pod adresem http://nazwa_organizacji.github.io/nazwa_projektu3. Ja na przykład utworzyłem stronę dla projektu o nazwie github-example w ramach organizacji pragmaticlearning. Strona ta jest dostępna pod adresem http://pragmaticlearning.github.io/github-example.

Gdy zostanie utworzona strona WWW dla projektu, GitHub doda do niego nową gałąź o nazwie gh-pages. Po wybraniu tej gałęzi z listy pojawi się na ekranie zestawienie podobne do pokazanego na rysunku 4.36. Znajdziesz w nim listę wygenerowanych plików z kodem strony, który możesz samodzielnie modyfikować, jeśli znasz HTML i CSS.

Rysunek 4.36. Zawartość gałęzi gh-pages

Tworzenie strony internetowej dla siebie albo dla organizacji Jeśli za pośrednictwem narzędzia Pages w GitHubie chciałbyś zaprojektować stronę WWW dla siebie albo swojej organizacji, to musisz najpierw utworzyć projekt o nazwie nazwa_uzytkownika.github.io. W wypadku stron osobistych albo organizacji zamiast gałęzi gh-pages do zbudowania witryny jest używana zawartość gałęzi głównej (master).

W celu utworzenia strony internetowej dla organizacji najpierw otwórz stronę główną tej organizacji w GitHubie i kliknij przycisk +, a potem wybierz polecenie New repository (nowe repozytorium). Nadaj repozytorium nazwę nazwa_organizacji.github.io, a potem zaznacz opcję Initialize this repository with a README (zainicjalizuj to repozytorium z plikiem README), jak na rysunku 4.37.

Po utworzeniu takiego projektu kliknij odsyłacz Settings (ustawienia) i przewiń stronę w dół, do sekcji GitHub Pages (strony GitHub), aby się przekonać, że nowa strona została już opublikowana w serwisie GitHub (rysunek 4.38).

Rysunek 4.37. Tworzenie repozytorium na potrzeby strony WWW organizacji

Rysunek 4.38. Zakładka z ustawieniami dla strony organizacji w serwisie GitHub Jeśli znasz HTML i CSS, możesz od razu rozpocząć projektowanie strony. Jeżeli wolałbyś skorzystać z wbudowanego generatora, możesz zastąpić domyślny projekt jednym z szablonów: kliknij przycisk Automatic page generator (automatyczny generator stron), po czym przystąp do pracy tak samo jak w wypadku stron projektu w GitHubie.

Więcej na: www.ebook4all.pl

ROZDZIAŁ 5.

Tworzenie i konfigurowanie Do tej pory zajmowaliśmy się przeglądaniem i edytowaniem projektów oraz współpracą. W tym rozdziale przyjrzymy się procesowi tworzenia i konfigurowania repozytorium GitHuba na potrzeby nowego projektu.

Jeśli współpracujesz z programistami na zasadzie kontraktów, przyda Ci się repozytorium, którym mogliby się oni posługiwać. Dzięki utworzeniu takiego repozytorium zawsze będziesz mieć dostęp do kodu oraz pomocniczych informacji zapisanych w zgłoszeniach, problemach i wiki. Po utworzeniu repozytorium możesz dodać do niego programistów w charakterze współpracowników, aby mieli bezpośredni dostęp do projektu — aż do chwili, gdy z jakichś względów będziesz chciał cofnąć te uprawnienia. Nie powinieneś zlecać programistom utworzenia repozytorium. W takim wypadku bowiem będą mogli w dowolnej chwili usunąć Ciebie z projektu.

Tworzenie repozytorium Aby utworzyć nowy projekt w GitHubie, kliknij przycisk z symbolem plusa (+), znajdujący się po prawej stronie Twojej nazwy użytkownika w prawej górnej części ekranu. Następnie wybierz z rozwijanej listy polecenie New repository (nowe repozytorium). Na ekranie pojawi się formularz nowego repozytorium, podobny do przedstawionego na rysunku 5.1.

Pierwsza decyzja polega na wyborze między opublikowaniem repozytorium pod nazwą użytkownika a nazwą organizacji. Na rysunku 5.2 widać listę organizacji, pod których szyldem mógłbym utworzyć nowe repozytorium. Jeśli nie masz dostępu do żadnej organizacji, po prostu zostaw opcję domyślną, czyli nazwę użytkownika. Pamiętaj, że w razie potrzeby zawsze możesz potem przenieść projekt.

Rysunek 5.1. Formularz nowego repozytorium

Rysunek 5.2. Wybór właściciela nowego repozytorium Kolejny krok polega na nazwaniu repozytorium. Nazwa może się składać z liter, cyfr, myślników i (lub) podkreśleń1. Wszystkie inne znaki zostaną zastąpione myślnikami.

Po wprowadzeniu nazwy powinieneś zadecydować, czy repozytorium będzie prywatne, czy nie. Repozytoria publiczne mogą być oglądane przez kogokolwiek. Repozytoria prywatne zaś mogą być przeglądane tylko przez te osoby, które zaprosisz do projektu w charakterze współpracowników. W obydwu sytuacjach natomiast projekt może być modyfikowany tylko przez zaproszonych współpracowników.

Zwykle, jeśli kod ma pewną wartość komercyjną, to opłata rzędu kilku dolarów miesięcznie za utrzymanie jego prywatności nie powinna stanowić problemu. Jeśli nie ma takiej wartości, możesz po prostu utworzyć repozytorium publiczne, które nie będzie Cię kosztowało ani grosza. Jeśli nie widzisz opcji pozwalającej na założenie prywatnego repozytorium, to znaczy, że musisz zmienić plan taryfowy swojego konta albo organizacji, w ramach której chcesz je utworzyć, na umożliwiający obsługę prywatnych repozytoriów.

Ostatnia decyzja związana z tworzeniem nowego repozytorium dotyczy tego, czy inicjalizować je z plikiem README — służy do tego specjalna opcja pokazana na rysunku 5.3.

Rysunek 5.3. Inicjalizowanie repozytorium z plikiem README.md Większość programistów nie zaznacza opcji służącej do inicjalizowania repozytorium. Wolą utworzyć projekt lokalnie, zapisać go przy użyciu Gita, a potem przesyłać gotowe pliki do GitHuba. Ale jeśli nie jesteś programistą, to zapewne powinieneś zainicjalizować repozytorium z plikiem README, ponieważ umożliwia to pracę nad projektem bez konieczności tworzenia lokalnego repozytorium Gita i zdalnego przesyłania danych. Potem Twoi programiści będą mogli sklonować (pobrać) takie repozytorium i umieścić w nim swój kod.

Gdy wszystko będzie gotowe, kliknij przycisk Create repository (utwórz repozytorium), aby utworzyć nowe repozytorium.

Jeśli zainicjalizujesz repozytorium z plikiem README, GitHub utworzy projekt i wyświetli stronę przypominającą tę pokazaną na rysunku 5.4. Taki projekt można już bez przeszkód klonować, jak również można zacząć wprowadzać w nim zmiany.

Rysunek 5.4. Nowy projekt zainicjalizowany z plikiem README.md Jeśli nie zainicjalizujesz repozytorium, na ekranie pojawi się strona podobna do zilustrowanej

na rysunku 5.5. W takim wypadku Ty albo ktoś z Twojego zespołu musi najpierw przesłać do GitHuba istniejące repozytorium Gita, by z utworzonym w ten sposób repozytorium można było w GitHubie normalnie pracować, a także by można było je klonować.

Dodawanie współpracowników Kolejny krok, po utworzeniu i zainicjalizowaniu repozytorium, polega na dodaniu współpracowników. Jeśli utworzyłeś repozytorium publiczne, to nie musisz tego robić — zwłaszcza w sytuacji, gdy rzadko pracujesz z innymi osobami. Wystarczy, że poprosisz potencjalnych współpracowników o utworzenie kopii (forka) Twojego repozytorium i wysyłanie zgłoszeń za każdym razem, gdy będą oni chcieli coś zaproponować lub wprowadzić zmiany. Ale jeśli utworzyłeś repozytorium prywatne lub masz zespół, z którym rutynowo pracujesz nad danym projektem, to powinieneś dodać członków tego zespołu jako współpracowników.

Rysunek 5.5. Nowy projekt wymagający przesłania istniejącego repozytorium Jeśli utworzyłeś repozytorium w ramach organizacji, to możesz zarządzać dostępem do niego za pośrednictwem funkcji Teams (zespoły) — przeczytasz o tym w dalszej części tego rozdziału. Ale w sytuacji, gdy utworzyłeś repozytorium na swoim indywidualnym koncie, poszczególnych współpracowników musisz dodać pojedynczo.

Aby dodać współpracowników, kliknij odsyłacz Settings (ustawienia), znajdujący się w prawej dolnej części ekranu, a potem kliknij zakładkę Collaborators (współpracownicy), jak na rysunku 5.6. Być może zostaniesz poproszony o wprowadzenie hasła w celu potwierdzenia,

że to rzeczywiście Ty dokonujesz zmian w serwisie.

Aby dodać współpracowników, musisz znać nazwy użytkowników GitHuba (loginy), z którymi chcesz pracować. Po rozpoczęciu przez Ciebie wpisywania serwis będzie podpowiadał pasujące nazwy, jak przedstawiono to na rysunku 5.7. Po wybraniu właściwej nazwy kliknij przycisk Add collaborator (dodaj współpracownika).

Po dodaniu współpracowników poświęć chwilę na przejrzenie innych opcji, aby sprawdzić, czy jest coś, co chciałbyś dodatkowo skonfigurować.

Rysunek 5.6. Odsyłacz Settings i zakładka Collaborators

Rysunek 5.7. Automatyczne uzupełnianie nazwy współpracownika

Konfigurowanie repozytorium Aby skonfigurować repozytorium, najpierw kliknij odsyłacz Settings (ustawienia), umieszczony w prawej dolnej części strony. Domyślnie na ekranie pojawi się wtedy zakładka Options (opcje) z sekcji Settings, co zilustrowano na rysunku 5.8. Na zakładce tej można skonfigurować kilka ogólnych ustawień repozytorium.

Pierwsza opcja umożliwia zmianę nazwy repozytorium. Jeśli zmienisz nazwę widoczną w polu tekstowym, uaktywni się przycisk Rename (zmień nazwę), umożliwiający zatwierdzenie nowej nazwy projektu. Nie przejmuj się, jeśli programiści z Twojego zespołu dołączyli do projektu wcześniej, gdy jeszcze nosił starą nazwę. Nie będą musieli nic zmieniać — każdy, kto odwoływał się do projektu przy użyciu starej nazwy albo starego adresu URL, zostanie automatycznie skierowany we właściwe miejsce.

Rysunek 5.8. Zakładka Options z sekcji Settings Na omawianej stronie za pomocą listy Default branch (domyślna gałąź) można zmienić domyślną gałąź projektu z głównej (master) na dowolną istniejącą. Tę opcję na ogół najlepiej pozostawić bez zmian, ale jeśli zespół zdecyduje, że zmiana domyślnej gałęzi jest konieczna, to po utworzeniu odpowiedniej gałęzi da się ustawić ją jako domyślną za pomocą wspomnianej opcji. Domyślna gałąź decyduje o działaniu funkcji takich jak, przykładowo, automatyczne zamykanie problemów. Zazwyczaj, jeśli w komentarzu do zmiany umieści się informację w rodzaju closes #10 albo fixed #10, to po włączeniu takiej zmiany do gałęzi głównej, problem numer 10 zostanie automatycznie zamknięty. Dzieje się tak jednak tylko wtedy, gdy zmiana zostanie włączona do gałęzi domyślnej; jeśli więc chciałbyś, aby domyślna gałąź nosiła jakąś inną nazwę (np. trunk), to właśnie tutaj możesz wprowadzić odpowiednie zmiany.

Na stronie Settings/Options (ustawienia/opcje) można ponadto skonfigurować wiki oraz obsługę problemów. Domyślnie obydwie te funkcje są włączone we wszystkich nowych projektach. Aby je wyłączyć, usuń zaznaczenia z odpowiednich pól. Jeśli chciałbyś, aby wiki publicznego projektu mogli edytować tylko współpracownicy, zaznacz opcję Restrict editing to collaborators only (zezwól na edycję tylko współpracownikom).

Nieco niżej na stronie Settings/Options znajdują się pomocnicze ustawienia, widoczne na rysunku 5.9.

Jeśli planujesz utworzenie strony internetowej dla projektu, kliknij przycisk Automatic page generator (automatyczny generator stron), aby ją skonfigurować.

Rysunek 5.9. Zakładka Options z sekcji Settings — ciąg dalszy Ostatnia sekcja nosi nazwę Danger Zone (niebezpieczna strefa). Znajdują się w niej opcje umożliwiające zmianę charakteru projektu z publicznego na prywatny, przekazanie własności projektu innemu użytkownikowi albo organizacji oraz, w razie absolutnej konieczności, usunięcie danego repozytorium. Nie obawiaj się skutków przypadkowego kliknięcia przycisku Delete this repository (usuń to repozytorium). Nawet jeśli go klikniesz, na ekranie pojawi się okno z prośbą o potwierdzenie tej operacji, pokazane na rysunku 5.10.

Integracja z innymi systemami Czasami zachodzi potrzeba połączenia GitHuba z innymi używanymi programami — na przykład serwerami regularnie wykonującymi automatyczne testy oprogramowania w ramach procesu ciągłej integracji albo aplikacjami do zarządzania projektem lub wychwytywania błędów. Istnieją trzy sposoby łączenia zewnętrznego oprogramowania z repozytorium GitHuba.

Jedną z opcji jest API (interfejs programistyczny aplikacji) GitHuba. Otwórz stronę https://developer.github.com/, pokazaną na rysunku 5.11, i kliknij odsyłacz API, znajdujący się w górnej części tejże strony. Dowiesz się stamtąd, w jaki sposób niemal dowolną operację

na repozytorium można wykonać zdalnie, za pośrednictwem API GitHuba.

Rysunek 5.10. Okno z potwierdzeniem usunięcia repozytorium

Rysunek 5.11. Strona główna serwisu GitHub Developer

Za pomocą API programiści mogą niemal dowolnie odwoływać się do repozytorium i wprowadzać w nim zmiany, ale czasami chodzi tylko o to, by otrzymać informację na temat konkretnego zdarzenia. Programiści mogą na przykład chcieć, by napisany przez nich program był informowany za każdym razem, gdy ktoś zgłosi problem albo prześle do repozytorium GitHuba nowe dane. Aby otrzymywać powiadomienia o tym, co dzieje się w projekcie, należy skonfigurować opcję Webhooks (obsługa zdarzeń), znajdującą się w sekcji Settings/Webhooks & Services (ustawienia/obsługa zdarzeń i usługi), przedstawionej na rysunku 5.12.

Rysunek 5.12. Strona Webhooks & Services Kliknięcie przycisku Add webhook (dodaj uchwyt zdarzenia) powoduje wyświetlenie strony Add webhook, zilustrowanej na rysunku 5.13.

Rysunek 5.13. Strona Add webhook Na tej stronie można skonfigurować GitHuba tak, by wysyłał powiadomienie do zewnętrznej aplikacji za każdym razem, gdy nastąpi jakieś konkretne zdarzenie. Aby mechanizm zadziałał, trzeba podać adres URL programu, który będzie oczekiwał na informacje, określić formę przesyłanych danych, wpisać opcjonalny „tajny kod” (by niepożądane osoby nie mogły wysyłać fałszywych danych na podany adres URL) oraz wybrać rodzaj zdarzeń, o jakich chcesz być powiadamiany. Jeśli Twoi programiści pracują nad niestandardowym sposobem wykorzystania GitHuba, to zapewne udzielą Ci szczegółowych informacji o właściwej konfiguracji uchwytu zdarzenia (albo uchwytów).

Ostatnia opcja nie wymaga udziału programistów. Wyświetl stronę Webhooks & Services (obsługa zdarzeń i usługi) i kliknij przycisk Add service (dodaj usługę). Na ekranie pojawi się lista rozwijana, podobna do tej z rysunku 5.14.

Rysunek 5.14. Lista Add service Jeśli używasz jednego z popularnych programów standardowo współpracujących z GitHubem, zacznij wpisywanie nazwy tej aplikacji w polu Filter services (filtruj usługi); po chwili powinieneś znaleźć żądany program. Kliknij jego nazwę, aby wyświetlić stronę, z której dowiesz się, w jaki sposób powiązać daną aplikację z GitHubem.

Przypuśćmy na przykład, że zależy Ci na połączeniu z Basecampem. Zacznij wpisywać nazwę „Basecamp”, a potem wybierz opcję Basecamp z listy, aby wyświetlić stronę podobną do pokazanej na rysunku 5.15. Znajdują się na niej pola umożliwiające wprowadzenie adresu URL projektu Basecampa oraz dane logowania, których GitHub powinien użyć w celu uzyskania dostępu do tego projektu.

Rysunek 5.15. Integracja GitHuba z Basecampem Każdy proces integracji przebiega nieco inaczej — zarówno pod względem rodzaju informacji, jakie należy podać, by połączyć się z zewnętrznym programem, jak i osiąganej w ten sposób funkcjonalności. Jak widać na rysunku 5.16, uwagi dotyczące procesu integracji z programem Asana dość znacznie różnią się od tych dotyczących Basecampa.

Ostatnia zakładka w sekcji Settings (ustawienia) w repozytorium GitHuba nosi nazwę Deploy keys (klucze dostępu). Jej kliknięcie powoduje wyświetlenie strony podobnej do pokazanej na rysunku 5.17.

Oprócz tego, że dostępu do repozytorium potrzebują różne osoby, czasami zachodzi konieczność udostępnienia go pewnym programom. Na przykład zespół programistów może dysponować automatycznym systemem kompilacji oprogramowania, umożliwiającym błyskawiczne („jednym kliknięciem”) przesłanie najnowszych zmian z GitHuba na serwer produkcyjny.

Rysunek 5.16. Integracja GitHuba z Asaną

Rysunek 5.17. Konfigurowanie kluczy dostępu

W takim wypadku wspomniany system musi dysponować dostępem do repozytorium. Taki dostęp można zapewnić na kilka sposobów, a jednym z nich jest założenie konta maszynowego. Polega to na utworzeniu w GitHubie konta użytkownika dla wspomnianego systemu informatycznego i dodaniu tego konta do listy współpracowników. To podejście sprawdza się zwłaszcza w sytuacji, gdy system powinien mieć dostęp do kilku różnych repozytoriów.

Inna metoda polega na utworzeniu klucza dostępu. Klucz dostępu to w istocie klucz SSH (ang.

Secure Shell), tworzony w celu udostępnienia konkretnemu programowi jednego, wybranego repozytorium w GitHubie. Szczegółowe informacje na ten temat raczej Ci się nie przydadzą, wiedz jedynie, że gdy Twoi programiści poproszą Cię o skonfigurowanie klucza dostępu, powinieneś zapytać ich o klucz publiczny SSH i poprosić o podanie oczekiwanej nazwy klucza dostępu (np. „serwer XYZ”). Uzyskane informacje możesz wpisać w odpowiednie pola formularza w sekcji Add a deploy key (dodaj klucz dostępu), widocznego na rysunku 5.18.

Rysunek 5.18. Dodawanie klucza dostępu do repozytorium GitHuba

Repozytoria osobiste i repozytoria organizacji Pierwsze pytanie, jakie powinieneś sobie zadać przy tworzeniu repozytorium, dotyczy tego, czy repozytorium to powinno być powiązane z Twoim kontem użytkownika, czy też lepiej będzie je dodać do konta organizacji.

Jeśli pracujesz nad prywatnym projektem (darmowym lub komercyjnym), to zapewne powinieneś utworzyć go w ramach osobistego konta na GitHubie. Ale jeśli tworzysz projekt, który ma być własnością kogoś innego i przez tego kogoś będzie zarządzany — na przykład

przez organizację non profit lub firmę — to na ogół powinieneś zacząć od zdefiniowania tej organizacji, a potem utworzyć dla niej projekt. Takie rozwiązanie pozwoli Ci w przyszłości z łatwością przekazać własność projektu.

Nie jest to może szczególnie istotne, bo własność repozytorium zawsze można przenieść na kogoś innego — w razie wątpliwości więc po prostu utwórz je na własnym koncie. Niemniej, jeśli z góry wiesz, że będziesz realizować projekt na rzecz jakiejś organizacji, to możesz zacząć od utworzenia tejże organizacji.

Tworzenie organizacji Aby utworzyć organizację, zaloguj się do GitHuba, po czym kliknij przycisk z symbolem +, znajdujący się w prawej górnej części strony, na prawo od Twojej nazwy użytkownika, i z rozwijanej listy pokazanej na rysunku 5.19 wybierz polecenie New organization (nowa organizacja).

Rysunek 5.19. Pierwszy krok tworzenia nowej organizacji Spowoduje to wyświetlenie strony podobnej do przedstawionej na rysunku 5.20, za pomocą której możesz utworzyć nową organizację.

Rysunek 5.20. Tworzenie nowej organizacji Rozpocznij od nadania organizacji jakiejś nazwy i wprowadzenia adresu e-mail, na który będą wysyłane rachunki. Następnie należy wybrać plan taryfowy. Jeśli wszystkie Twoje projekty będą miały charakter otwarty, możesz bezpłatnie utworzyć organizację typu open source. Jeśli jednak chciałbyś utrzymywać w serwisie prywatne repozytoria, będziesz potrzebować choćby najtańszego (Bronze) planu taryfowego, który za 25 dolarów miesięcznie umożliwia obsługę do 10 prywatnych repozytoriów (i dowolną liczbę repozytoriów publicznych).

Jeżeli zdecydujesz się na założenie konta organizacji umożliwiającego obsługę prywatnych repozytoriów, zostaniesz poproszony o dane karty kredytowej albo dane konta PayPal w celu skonfigurowania metody pobierania miesięcznych opłat.

Po utworzeniu organizacji możesz zająć się definiowaniem zespołów (grup roboczych).

Zarządzanie zespołami Jeśli utworzysz repozytorium na własnym koncie, możesz bezpośrednio dodawać współpracowników do projektu. Ale wtedy gdy utworzysz repozytorium na koncie organizacji i chciałbyś, aby inne osoby miały do niego dostęp, powinieneś zacząć od stworzenia zespołów.

Domyślnie podczas zakładania organizacji GitHub utworzy zespół o nazwie Owners (właściciele) i umieści w nim Ciebie jako założyciela. Jeśli zamierzasz zezwolić innym na dostęp do projektu, musisz albo dodać ich do zespołu Owners w ramach organizacji, albo utworzyć nowy zespół.

W większości przypadków lepiej utworzyć nowy zespół z ograniczonymi uprawnieniami.

Często zakładam zespół o nazwie Collaborators (współpracownicy) dla osób, z którymi zamierzam realizować projekt. Jeśli działam w większej organizacji, czasami tworzę zespoły dla działu biznesowego, marketingowego albo prawnego.

Aby utworzyć zespół, otwórz stronę główną organizacji i kliknij odsyłacz Teams (zespoły), widoczny na rysunku 5.21 po prawej stronie.

Rysunek 5.21. Strona główna organizacji Strona Teams powinna wyglądać podobnie jak na rysunku 5.22. Będzie się na niej znajdowała lista wszystkich zespołów należących do organizacji oraz lista ikon przedstawiających członków każdego z tych zespołów.

Aby utworzyć nowy zespół, kliknij zielony przycisk z napisem + New team (dodaj nowy zespół), znajdujący się w prawej górnej części strony. Na ekranie pojawi się formularz podobny do zaprezentowanego na rysunku 5.23.

Nadaj zespołowi nazwę. W wypadku gdy pracujesz tylko z kilkoma programistami nad jednym produktem, nazwa ta może być bardzo prosta, na przykład „programisci”. Jeżeli należysz do większej organizacji, nazwa może odzwierciedlać funkcję biznesową albo nazwę zespołu projektowego, na przykład „programisci dzialu mobile” albo „programisci API” itp.

Rysunek 5.22. Wyświetlanie zespołów w organizacji

Rysunek 5.23. Dodawanie nowego zespołu do organizacji Do nazwy możesz opcjonalnie dołączyć krótki opis zadań zespołu, jeśli jego rola nie jest oczywista dla innych członków organizacji. Następnie należy określić prawa dostępu do repozytoriów: odczyt (read), zapis (write) lub administracja (admin). Jeśli zapewnisz zespołowi prawa do odczytu, jego członkowie będą mogli tylko przeglądać i klonować repozytorium oraz używać tworzonej w nim aplikacji. Jeśli natomiast przyznasz prawa do zapisu, zespół będzie mógł wprowadzać zmiany w repozytorium. Z kolei w sytuacji gdy przyznasz prawa administratora, poszczególni członkowie zespołu będą mogli dodawać kolejnych współpracowników do projektów, do których sami mają dostęp. Na koniec kliknij przycisk Create team (utwórz zespół).

Po utworzeniu zespołu następnym krokiem jest dodanie do niego odpowiednich osób. Jak widać na rysunku 5.24, wystarczy zacząć wpisywać nazwę użytkownika serwisu GitHub, którego zamierzasz umieścić w zespole, by serwis zasugerował pasujące nazwy.

Rysunek 5.24. Dodawanie nowego użytkownika do zespołu Wtedy gdy będziesz chciał usunąć kogoś z zespołu, kliknij nazwę tego zespołu, a potem użyj przycisku Remove (usuń), umieszczonego obok nazwy danego użytkownika. Gdy będziesz chciał usunąć cały zespół, wtedy na stronie Teams (zespoły) kliknij zespół do skasowania. Na ekranie powinna się pojawić strona zbliżona wyglądem do pokazanej na rysunku 5.25.

Rysunek 5.25. Strona z informacjami o zespole Kliknij przycisk Settings (ustawienia) w lewej części strony, by wyświetlić formularz podobny do przedstawionego na rysunku 5.26.

Rysunek 5.26. Strona z ustawieniami zespołu Aby usunąć zespół, należy kliknąć przycisk Delete this team (usuń ten zespół), znajdujący się w dolnej części strony. Zespół zostanie usunięty po kliknięciu przycisku OK w wyświetlonym okienku z prośbą o potwierdzenie decyzji.

Gratulacje! Jeśli dotarłeś do tego miejsca książki, powinieneś umieć zrobić w repozytorium GitHuba niemal wszystko, między innymi — przeanalizować bieżący stan projektu, edytować pliki w projekcie, współpracować z zespołem oraz tworzyć i konfigurować nowe repozytoria.

W następnym rozdziale zapoznasz się z klientami GitHuba dla systemów Windows i Mac OS, umożliwiającymi pobranie kopii repozytorium i wprowadzenie w nim prostych zmian lokalnie, na własnym laptopie.

ROZDZIAŁ 6.

Pobieranie Być może nigdy nie będziesz musiał klonować (pobierać) repozytorium. Na podstawie lektury poprzednich rozdziałów przekonałeś się, że za pomocą interfejsu WWW GitHuba można bez trudu zapoznać się z bieżącym stanem projektu, edytować jego treść, współpracować z zespołem, a także tworzyć i konfigurować repozytoria. Sklonowanie istniejącego repozytorium bywa jednak konieczne. W tym rozdziale przeczytasz o tym, do czego może się przydać kopiowanie repozytorium, a także jak to zrobić za pomocą klienta GitHuba dla systemów Windows i Mac OS. Jeśli używasz Linuksa, to zapewne najwygodniej będzie Ci zainstalować program Git i zapoznać się z jego poleceniami umożliwiającymi pracę z repozytoriami Gita z poziomu wiersza poleceń — to zagadnienie wykracza jednak poza ramy niniejszej książki.

Po co klonować repozytorium?

Istnieje kilka powodów przemawiających za klonowaniem repozytoriów. Poniżej zostały wymienione jedne z najczęstszych: Tworzenie kopii zapasowej Klonowanie repozytorium powoduje utworzenie dokładnej kopii całego projektu — z uwzględnieniem gałęzi, znaczników i historii — na komputerze użytkownika. Czasami warto sklonować repozytorium i regularnie pobierać zachodzące w nim zmiany, aby mieć pewność, że dysponuje się kompletną kopią projektu na własnym komputerze.

Edycja w IDE Interfejs WWW nie daje takich możliwości jak zaawansowane środowiska programistyczne IDE (ang. Integrated Development Environment), a nawet dobre edytory tekstowe. Jeśli więc przez cały dzień pracujesz nad edycją treści, wygodniej będzie Ci to robić lokalnie, na własnym komputerze.

Edycja offline W GitHubie nie da się edytować plików bez dostępu do internetu. Jeśli więc chciałbyś kontynuować pracę pomimo braku połączenia z siecią, powinieneś wcześniej sklonować repozytorium.

Edycja wielu plików Jednym z głównych ograniczeń edytowania plików bezpośrednio w GitHubie jest brak możliwości zgrupowania kilku powiązanych ze sobą modyfikacji i wprowadzenia ich w postaci jednej zmiany.

Uruchamianie kodu

Czasami warto uruchomić kod lokalnie, aby zweryfikować jego działanie.

Wykonywanie testów Jeśli dysponujesz mechanizmami umożliwiającymi automatyczną weryfikację projektu, to takie testy warto przeprowadzić lokalnie, aby zyskać pewność, że najnowsze zmiany nie powodują błędów.

Jeżeli chciałbyś wykonać dowolną z wymienionych operacji, to powinieneś zainstalować na swoim komputerze system kontroli wersji Git oraz (ewentualnie) interfejs graficzny (GUI) dla Gita, ułatwiający wykonywanie typowych czynności.

Istnieje kilka aplikacji umożliwiających obsługę repozytorium Gita za pośrednictwem interfejsu graficznego. W tym rozdziale omówimy programy dostępne w serwisie GitHub: klienta GitHuba dla systemu Mac OS oraz klienta GitHuba dla systemu Windows.

GitHub w wersji dla systemu Mac OS Aby pobrać kopię programu GitHub dla Mac OS-a, najpierw odwiedź stronę https://mac.github.com. Na ekranie pojawi się strona podobna do pokazanej na rysunku 6.1.

Kliknij przycisk Download GitHub for Mac (pobierz GitHuba dla Mac OS-a), aby pobrać archiwum ZIP do domyślnego folderu przeznaczonego na pliki pobierane z poziomu przeglądarki — zwykle nosi on nazwę Pobrane albo Downloads. Po dwukrotnym kliknięciu archiwum powinien zostać z niego wypakowany plik o nazwie GitHub.app, który trafi do tego samego folderu (rysunek 6.2).

Rysunek 6.1. Strona internetowa programu GitHub w wersji dla systemu Mac OS

Rysunek 6.2. GitHub dla Mac OS-a — archiwum ZIP i plik z aplikacją Przeciągnij plik GitHub.app do folderu Applications (Aplikacje). Następnie kliknij ten folder, potem zaś dwukrotnie kliknij plik GitHub.app. Na ekranie może się pojawić komunikat przypominający, że program GitHub.app został pobrany z internetu (rysunek 6.3). To nie szkodzi — po prostu kliknij przycisk Open (Otwórz) w wyświetlonym oknie z komunikatem, by uruchomić GitHuba.

Na ekranie powinno się pojawić okno zbliżone wyglądem do przedstawionego na rysunku 6.4 — z podziękowaniami za wypróbowanie GitHuba dla Mac OS-a.

Rysunek 6.3. Komunikat ostrzegający przed uruchomieniem programu pobranego z internetu

Rysunek 6.4. Kreator instalacji programu GitHub dla Mac OS-a Kliknij przycisk Continue (kontynuuj), podaj login i hasło do serwisu GitHub, a potem kliknij przycisk Sign in (zaloguj się). Jeśli uaktywniłeś dwuetapową autoryzację, aby lepiej zabezpieczyć konto, zostaniesz poproszony o podanie kodu, który został przesłany SMS-em na Twój telefon komórkowy.

Po pomyślnym logowaniu na ekranie powinno się pojawić okno podobne do pokazanego na rysunku 6.5.

Rysunek 6.5. Potwierdzenie logowania na konto w GitHubie dla Mac OS-a Po ponownym kliknięciu przycisku Continue zostaniesz poproszony o wprowadzenie kilku informacji potrzebnych do skonfigurowania Gita. W pierwszym polu tekstowym wpisz nazwę, pod jaką chcesz występować, w drugim zaś podaj adres e-mail, z którym będą powiązane generowane przez Ciebie zmiany. W pierwszym polu wpisuje się na ogół pełne imię i nazwisko, jeśli zaś chodzi o adres — wpisuje się ten, który podano w serwisie GitHub; tak też zrobiłem (rysunek 6.6).

Rysunek 6.6. Konfigurowanie ustawień Gita Pod wymienionymi polami znajduje się sekcja o nazwie Command Line (wiersz poleceń).

Kliknij przycisk Install Command Line Tools (zainstaluj narzędzia wiersza poleceń). Dzięki zainstalowaniu tych narzędzi, w sytuacji gdy kiedykolwiek chciałbyś skorzystać z możliwości posługiwania się Gitem z poziomu wiersza poleceń, będziesz mógł to zrobić. Teraz musisz wprowadzić dane uwierzytelniające administratora systemu operacyjnego. Gdy to zrobisz, na ekranie powinien pojawić się komunikat przypominający ten, który przedstawiono na rysunku 6.7. Informuje on o ukończeniu działania kreatora i pomyślnym zainstalowaniu narzędzi do obsługi Gita z wiersza poleceń.

Rysunek 6.7. Komunikat o pomyślnym zainstalowaniu narzędzi do obsługi Gita z wiersza poleceń Po kliknięciu przycisku OK, a potem przycisku Continue (kontynuuj) na ekranie pojawi się okno umożliwiające wyszukanie lokalnych repozytoriów. Na razie po prostu kliknij przycisk Done (gotowe), by wrócić do głównego okna programu GitHub w wersji dla Mac OS-a — okno to wygląda tak jak na rysunku 6.8.

Nie przejmuj się, gdy po skonfigurowaniu GitHuba dla Mac OS-a otrzymasz e-mail (podobny do pokazanego na rysunku 6.9), z którego dowiesz się, że do Twojego konta został dodany nowy klucz publiczny. Jest to powiadomienie informujące o pomyślnym powiązaniu programu GitHub dla Mac OS-a z Twoim kontem w internetowym serwisie GitHub. To powiązanie wymaga utworzenia nowego klucza publicznego, który będzie używany przez klienta GitHuba do komunikacji ze zdalnym kontem.

Rysunek 6.8. Główne okno programu GitHub w wersji dla systemu Mac OS

Rysunek 6.9. E-mail z serwisu GitHub z informacją o dodaniu do Twojego konta nowego klucza publicznego Po zainstalowaniu GitHuba dla Mac OS-a odszukaj repozytorium przeznaczone do sklonowania (pobrania), którego jesteś właścicielem bądź współtwórcą. Możesz wprawdzie sklonować dowolne repozytorium publiczne, ale jeśli nie jesteś jego właścicielem ani nie dodano Cię do współpracowników, to zmian wprowadzonych lokalnie nie będziesz mógł potem scalić ze źródłowym repozytorium w GitHubie. W prawym dolnym rogu strony repozytorium (rysunek 6.10) znajduje się przycisk Clone in Desktop (klonuj na komputerze).

Rysunek 6.10. Strona repozytorium z widocznym przyciskiem Clone in Desktop Kliknij przycisk Clone in Desktop. Rezultat wykonania tej operacji może nieco się różnić w zależności od używanej przeglądarki i jej wersji. Na przykład w mojej przeglądarce Chrome pojawia się okienko pokazane na rysunku 6.11, zawierające pytanie, czy przeglądarka powinna odwołać się do programu GitHub.app. U Ciebie powinno to wyglądać podobnie.

Rysunek 6.11. Odwołanie do zewnętrznego protokołu wymagającego uruchomienia programu

GitHub dla Mac OS-a Powinieneś zezwolić na takie odwołanie — ja kliknąłem w tym celu przycisk Launch Application (Uruchom aplikację), by uruchomić program GitHub w wersji dla systemu Mac OS i otworzyć okno eksploratora plików, pokazane na rysunku 6.12.

Rysunek 6.12. Wybór katalogu do sklonowania repozytorium Wybierz katalog, w którym chciałbyś umieścić sklonowane repozytorium, po czym kliknij przycisk Clone (klonuj), a GitHub wykona żądaną kopię. Po pomyślnym sklonowaniu repozytorium na ekranie powinno się pojawić okno podobne do przedstawionego na rysunku 6.13.

W lewym górnym rogu tego okna znajduje się przycisk + umożliwiający utworzenie nowego repozytorium w podanym katalogu lub sklonowanie repozytorium z GitHuba. Poniżej, po lewej stronie, jest umieszczony panel z listą repozytoriów, nad którymi możesz pracować lokalnie.

Panel ten można ukryć przez kliknięcie niebieskiego przycisku w górnej części okna.

Na samej górze okna, po prawej stronie wspomnianego przycisku, znajduje się kolejny przycisk, służący do tworzenia nowej gałęzi. Obok zaś umieszczona jest lista rozwijana umożliwiająca wybór gałęzi, z którą chcesz pracować albo się zapoznać. Poniżej, na domyślnej zakładce Changes (zmiany), widnieje pole tekstowe, w którym możesz wprowadzić komentarz do zmiany, jeśli przygotowałeś jakąś zmianę do scalenia.

Rysunek 6.13. Podgląd repozytorium w programie GitHub dla Mac OS-a

Przesyłanie zmian przy użyciu programu GitHub dla Mac OSa Przed wprowadzeniem zmiany przy użyciu programu GitHub w wersji dla systemu Mac OS będziesz zapewne chciał utworzyć nową gałąź. Ja utworzyłem w tym celu gałąź o nazwie new_feature, pokazaną na rysunku 6.14.

Rysunek 6.14. Tworzenie nowej gałęzi

Jeśli teraz spojrzysz na listę po prawej stronie przycisku służącego do tworzenia gałęzi, to powinieneś dostrzec na niej nazwę gałęzi utworzonej przed chwilą. Jeśli tak jest w istocie, możesz przystąpić do wprowadzania zmiany polegającej na dodaniu nowego pliku. Program GitHub dla Mac OS-a nie jest wyposażony w środowisko IDE ani edytor tekstowy. Jest to po prostu narzędzie do przesyłania zmian do Gita, tak więc do utworzenia nowego pliku będziesz potrzebować edytora tekstowego albo innego narzędzia, a gotowy plik powinieneś zapisać w folderze projektu. Utwórz zatem nowy plik przy użyciu edytora, zapisz go w folderze projektu i wróć do programu GitHub. Wprowadzone zmiany powinny zostać odzwierciedlone na ekranie podobnym do pokazanego na rysunku 6.15.

Rysunek 6.15. Podgląd zmian do przesłania w programie GitHub w wersji dla Mac OS-a Kliknij w polu tekstowym Summary (streszczenie) pod etykietą Uncommitted Changes (nieprzesłane zmiany), wpisz komentarz do zmiany, a potem kliknij przycisk Commit & Sync (prześlij i synchronizuj). Zmiany zostaną zapisane w historii i przekazane do zdalnego repozytorium.

Jeśli nie masz uprawnień do przesyłania zmian do zdalnego repozytorium albo jeśli nie jesteś zalogowany na swoim koncie w programie GitHub dla Mac OS-a, to na ekranie pojawi się okno przypominające wyglądem pokazane na rysunku 6.16.

Rysunek 6.16. Komunikat o błędzie autoryzacji W takim wypadku sprawdź swoje dane uwierzytelniające w oknie Preferences/Accounts (preferencje/konta). Po udanej autoryzacji i potwierdzeniu, że jesteś właścicielem albo współautorem projektu, możesz kliknąć zielony przycisk po prawej stronie przycisku Commit (prześlij), by zsynchronizować zmiany i wysłać je do GitHuba.

Wyświetlanie zmian w programie GitHub dla Mac OS-a W górnej części okna programu GitHub w wersji dla systemu Mac OS znajdują się jeszcze trzy inne zakładki: History (historia), Branches (gałęzie) oraz Settings (ustawienia). Na zakładce History znajduje się lista zmian w bieżącej gałęzi — wspomniana lista może wyglądać tak jak na rysunku 6.17.

Rysunek 6.17. Podgląd historii

Po kliknięciu zakładki Branches na ekranie pojawi się okno podobne do przedstawionego na rysunku 6.18.

Rysunek 6.18. Podgląd gałęzi W oknie tym jest wyświetlona lista wszystkich gałęzi, które zostały utworzone lokalnie, a także lista innych gałęzi znajdujących się w zdalnym repozytorium GitHuba.

Po kliknięciu zakładki Settings pojawi się okno pokazane na rysunku 6.19.

Rysunek 6.19. Podgląd ustawień Na zakładce Settings można skonfigurować dwie rzeczy. Pierwszą jest zmiana zdalnego repozytorium — tej operacji zapewne nie będziesz wykonywać bardzo często. Ciekawsza jest jednak druga opcja, umożliwiająca nakazanie Gitowi ignorowanie określonych plików. Na ogół nie wysyła się do repozytorium Gita plików systemowych (takich jak .DS_Store z systemu Mac OS), plików konfiguracyjnych środowiska IDE, plików wykonywalnych, logów albo dużych plików binarnych. Jeśli wpiszesz nazwy takich plików w polu Ignored files (ignorowane pliki), to zostaną one dodane do pliku o nazwie .gitignore, który następnie można przesłać do repozytorium. Dzięki temu nikt inny w ramach tego projektu przypadkiem nie prześle wspomnianych plików.

Mam nadzieję, że dzięki podanym wskazówkom będziesz umiał w razie potrzeby, przy użyciu programu GitHub w wersji dla systemu Mac OS, klonować repozytoria i przesyłać do zdalnego repozytorium lokalnie wprowadzone zmiany.

Przyjrzyjmy się teraz analogicznej aplikacji przeznaczonej do zastosowania w systemie Windows.

Program GitHub w wersji dla systemu Windows Aby pobrać program GitHub dla Windows, najpierw odwiedź stronę https://windows.github.com. Na ekranie powinna się pojawić strona podobna do pokazanej na rysunku 6.20.

Kliknij przycisk Download GitHub for Windows (pobierz program GitHub dla Windows) i określ, czy chcesz uruchomić program, zapisać go czy anulować całą operację — w przypadku instalacji oczywiście trzeba go uruchomić. Na ekranie może się pojawić komunikat systemu zabezpieczeń, podobny do zilustrowanego na rysunku 6.21. W takim wypadku po prostu kliknij przycisk Install (Instaluj), by pobrać i zainstalować aplikację.

Po uruchomieniu programu GitHub dla Windows na ekranie powinno się pojawić okno przypominające to, które przedstawiono na rysunku 6.22, zachęcające do zalogowania się.

Rysunek 6.20. Strona internetowa programu GitHub w wersji dla systemu Windows

Rysunek 6.21. Komunikat systemu zabezpieczeń wyświetlony podczas instalacji programu

Rysunek 6.22. Kreator konfiguracji programu GitHub dla Windows Podaj login i hasło do serwisu GitHub, a potem kliknij przycisk Log in (zaloguj się). Jeśli uaktywniłeś dwuetapową autoryzację, aby lepiej zabezpieczyć konto, zostaniesz poproszony o podanie kodu, który został przesłany SMS-em na Twój telefon komórkowy (rysunek 6.23).

Rysunek 6.23. Dwuetapowa autoryzacja Po udanym logowaniu na ekranie powinno się pojawić okno z prośbą o wprowadzenie kilku informacji potrzebnych do skonfigurowania Gita. W pierwszym polu tekstowym wpisz nazwę, pod jaką chcesz występować, w drugim zaś podaj adres e-mail, z którym będą powiązane generowane przez Ciebie zmiany. Na ogół w pierwszym polu wpisuje się pełne imię i nazwisko, zaś w drugim — ten sam adres, którego używa się w serwisie GitHub; tak też zrobiłem (rysunek 6.24).

Rysunek 6.24. Konfigurowanie ustawień Gita Po kliknięciu przycisku Continue (kontynuuj) na ekranie pojawi się okno umożliwiające wyszukanie lokalnych repozytoriów. Na razie po prostu kliknij przycisk Skip (pomiń), by wrócić do głównego okna programu GitHub w wersji dla Windows (rysunek 6.25).

Nie przejmuj się, jeżeli po skonfigurowaniu GitHuba w wersji dla Windows otrzymasz e-mail podobny do pokazanego na rysunku 6.26, z którego dowiesz się, że do Twojego konta został dodany nowy klucz publiczny. Jest to potwierdzenie pomyślnego powiązania klienta GitHuba z Twoim kontem w internetowym serwisie GitHub. To powiązanie wymaga utworzenia nowego klucza publicznego, który będzie używany przez program GitHub w celu komunikacji ze zdalnym kontem w serwisie GitHub.

Rysunek 6.25. Główny ekran programu GitHub dla Windows

Rysunek 6.26. E-mail z serwisu GitHub z informacją o dodaniu do Twojego konta nowego klucza publicznego Po zainstalowaniu GitHuba dla Windows odszukaj repozytorium przeznaczone do sklonowania (pobrania), którego jesteś właścicielem bądź współautorem. Wprawdzie możesz sklonować dowolne repozytorium publiczne, ale jeśli nie jesteś jego właścicielem ani nie dodano Cię do grona współpracowników, to zmian wprowadzonych lokalnie nie będziesz mógł potem scalić ze źródłowym repozytorium w serwisie GitHub. W prawym dolnym rogu strony repozytorium (rysunek 6.27) znajduje się przycisk Clone in Desktop (klonuj na komputerze).

Rysunek 6.27. Strona repozytorium z widocznym przyciskiem Clone in Desktop Kliknij przycisk Clone in Desktop — rezultat tej operacji może być różny w zależności od wykorzystywanej przeglądarki i jej wersji. Na przykład w Internet Explorerze wyświetliło mi się okienko, pokazane na rysunku 6.28, z pytaniem o pozwolenie na przełączenie bieżącej aplikacji. Na Twoim komputerze powinno być podobnie.

Rysunek 6.28. Potwierdź chęć uruchomienia programu GitHub Kliknij przycisk Yes (tak), by uruchomić program GitHub dla Windows i otworzyć okno eksploratora plików, pokazane na rysunku 6.29.

Rysunek 6.29. Zapisywanie sklonowanego repozytorium w programie GitHub dla Windows Wybierz katalog, w którym chciałbyś umieścić sklonowane repozytorium, po czym kliknij przycisk Clone (klonuj), a program GitHub dla Windows wykona żądaną kopię. Po pomyślnym sklonowaniu repozytorium na ekranie powinno się pojawić okno podobne do przedstawionego na rysunku 6.30.

W lewym górnym rogu tego okna znajduje się przycisk + umożliwiający utworzenie nowego repozytorium w podanym katalogu lub sklonowanie repozytorium z GitHuba. Poniżej, po lewej stronie, jest umieszczony panel z listą repozytoriów, nad którymi możesz pracować lokalnie.

Na samej górze okna, po prawej stronie niebieskiego przycisku, znajduje się rozwijana lista umożliwiająca wybór istniejącej gałęzi lub utworzenie nowej. Pod nią jest umieszczone pole tekstowe, w którym możesz wprowadzić komentarz do zmiany, jeśli przygotowałeś jakąś zmianę do scalenia.

Rysunek 6.30. Podgląd repozytorium w programie GitHub dla Windows

Przesyłanie zmian przy użyciu programu GitHub dla Windows Zanim wprowadzisz zmianę przy użyciu programu GitHub dla Windows, zapewne będziesz chciał utworzyć nową gałąź. Ja utworzyłem w tym celu gałąź o nazwie windows_feature, widoczną na rysunku 6.31.

Kliknij przycisk Create... (utwórz) pod nazwą nowej gałęzi, a potem spójrz na listę znajdującą się ponad polem, w którym tę nazwę wpisywałeś — nowa gałąź powinna zostać automatycznie uaktywniona. Teraz można już zająć się wprowadzaniem zmiany polegającej na dodaniu nowego pliku. Program GitHub dla Windows nie jest wyposażony w środowisko IDE ani edytor tekstowy. Jest to po prostu narzędzie służące do przesyłania zmian do Gita, tak więc do utworzenia nowego pliku będziesz potrzebować edytora tekstowego albo innego narzędzia, a gotowy plik powinieneś zapisać w folderze projektu. Postąpiłem właśnie w taki sposób i zapisałem w tym folderze nowy plik o nazwie windows_feature.html. Gdy już utworzysz nowy plik przy użyciu edytora, zapisz go w folderze projektu i wróć do programu GitHub dla Windows. W oknie tego programu powinien widnieć komunikat Uncommitted changes (nieprzesłane zmiany). Po jego kliknięciu na ekranie pojawi się okno podobne do pokazanego na rysunku 6.32.

Rysunek 6.31. Tworzenie nowej gałęzi

Rysunek 6.32. Program GitHub w wersji dla Windows pokazuje zmiany do przesłania Kliknij w polu Summary (streszczenie) w sekcji Uncomitted changes (nieprzesłane zmiany), wpisz komentarz do zmiany, a potem kliknij przycisk Commit to... (prześlij do...), by zapisać

wprowadzone modyfikacje w historii repozytorium. Następnie kliknij przycisk Publish (publikuj), znajdujący się w prawym górnym rogu okna, by przesłać zmiany do GitHuba.

Konfigurowanie narzędzi do obsługi Gita z poziomu wiersza poleceń systemu Windows Czasami przydaje się możliwość korzystania z narzędzi Gita za pośrednictwem wiersza poleceń. Zanim ich użyjesz — są one domyślnie instalowane — kliknij przycisk Settings (ustawienia), znajdujący się w prawym górnym rogu okna programu GitHub dla Windows. Na ekranie pojawi się lista poleceń widoczna na rysunku 6.33. Wybierz polecenie Options (opcje).

Rysunek 6.33. Menu Settings w programie GitHub dla Windows Po wybraniu polecenia Options na ekranie pojawi się okno podobne do pokazanego na rysunku 6.34.

W oknie tym warto wprowadzić jedną zmianę, a mianowicie przełączyć domyślne środowisko wydawania poleceń z PowerShell na Git Bash. Dzięki temu po wydaniu polecenia Start/GitHub/GitHub Shell uruchomione zostanie środowisko dające dostęp do większej liczby przydatnych aplikacji, na przykład edytora tekstu vi. Po wprowadzeniu tej zmiany zapisz ją, klikając przycisk Update (aktualizuj), znajdujący się w lewej dolnej części strony.

Mam nadzieję, że dzięki podanym wskazówkom będziesz umiał w razie potrzeby — przy użyciu programu GitHub w wersji dla systemu Windows — klonować repozytoria i przesyłać

do zdalnego repozytorium lokalnie wprowadzone zmiany.

Rysunek 6.34. Opcje programu GitHub dla Windows

ROZDZIAŁ 7.

Kolejne kroki W tej książce omówiono wiele zagadnień. Na początku dowiedziałeś się, w jaki sposób przeglądać projekt, a następnie przeczytałeś o tworzeniu odgałęzień, edytowaniu plików i wspólnej pracy w ramach jednego repozytorium. Potem zaś nauczyłeś się tworzyć nowe repozytoria i konfigurować je, a także przeczytałeś o tym, jak można za pomocą klientów GitHuba klonować repozytoria i pracować nad nimi lokalnie.

Dla wielu osób ten zakres wiedzy będzie zupełnie wystarczający. Kolejny ważny krok polega na przećwiczeniu tych umiejętności do tego stopnia, aż wejdą Ci w krew, a praca zespołowa nad plikami tekstowymi za pośrednictwem GitHuba — czy będzie to kod źródłowy, czy innego rodzaju dokumenty — stanie się czymś naturalnym.

Pewne operacje najwygodniej realizuje się z poziomu wiersza poleceń. Choć wielu użytkowników nigdy nie będzie miało potrzeby wykonywania tego rodzaju czynności, to — jeśli pracujesz z projektami w Gicie przez cały czas, codziennie — nauka obsługi Gita za pośrednictwem wiersza poleceń może Ci się przydać. Jon Loelieger i Matthew McCullough napisali znakomitą książkę pod tytułem Kontrola wersji z systemem Git (Helion 2014), po którą mogą sięgnąć w następnej kolejności ci, którzy chcieliby dowiedzieć się więcej o obsłudze Gita z poziomu wiersza poleceń.

Także w serwisie GitHub można znaleźć wartościowe informacje dotyczące posługiwania się Gitem i GitHubem. Zainteresowanych odsyłam na stronę https://training.github.com.

Rola GitHuba w procesach projektowych wielu firm zapewne będzie rosnąć. To doskonały moment na zapoznanie się z tym narzędziem. Powodzenia!

Peter Bell Brooklyn, Nowy Jork Lipiec 2014

O autorach Peter Bell jest kontraktowym współpracownikiem zespołu szkoleniowego GitHuba i założycielem firmy Pragmatic Learning (http://www.praglearn.com/), zajmującej się organizowaniem szkoleń dla korporacji. Peter jest też organizatorem spotkań CTO Summit i założycielem CTO School. Regularnie prowadzi wykłady na konferencjach technologicznych, jest adiunktem na uczelni Columbia School of Business, gdzie prowadzi zajęcia (Digital Literacy) z zakresu posługiwania się nowoczesną technologią oraz poświęcone wielkim zbiorom danych (Big Data). Ponadto Peter Bell za pośrednictwem serwisu Learn to Speak Geek! (http://www.speakgeek.co/) szkoli przedstawicieli świata biznesu w zakresie skutecznego tworzenia oprogramowania.

Brent Beer od ponad pięciu lat posługuje się Gitem i GitHubem w ramach zajęć uniwersyteckich i projektów open source; korzysta z nich także w pracy zawodowej jako projektant stron internetowych. Obecnie pracuje w charakterze członka zespołu szkoleniowego GitHuba i uczy użytkowników skutecznego posługiwania się tymi narzędziami.

Kolofon Zwierzęta na okładce książki GitHub. Przyjazny przewodnik to oposy wełniste (Caluromys philander) — gatunek nadrzewnego torbacza znany też pod nazwą oposa białouchego.

Występują one wyłącznie w lasach deszczowych Brazylii, Boliwii, Gujany Francuskiej, Gujany, Surinamu, Trynidadu i Tobago oraz Wenezueli. Dzięki sprawnemu ogonowi, który umożliwia zwierzęciu wspinanie się, utrzymywanie równowagi i chwytanie, oposy wełniste niezmiernie rzadko schodzą na ziemię; w zasadzie nie spotyka się ich na poziomie podszytu.

Masa ciała oposów wełnistych wynosi od 140 do 390 gramów, przy czym samice na ogół osiągają mniejsze rozmiary niż samce. Zwierzęta te mają miękkie, grube futro, którego charakter ulega pewnym zmianom w zależności od środowiska i miejsca występowania.

Umaszczenie na grzbiecie i bokach oposa wełnistego jest rudobrązowe, natomiast na brzuchu — żółtopomarańczowe. Głowa tego zwierzęcia jest szara z charakterystycznymi, ciemnobrązowymi paskami biegnącymi od brązowej oprawy oczu do otworów nosowych oraz wzdłuż nasady nosa. Ogon na mniej więcej jednej czwartej długości jest pokryty futrem, pozostała jego część jest naga w kolorze kremowym do ciemnoszarego albo brązowym z brązowymi lub białymi cętkami.

Cykl rozrodczy oposa wełnistego nie jest zbyt dobrze znany. Większość osobników pędzi życie samotnie z wyjątkiem okresu godowego. Oposy wełniste mają do trzech miotów rocznie, w zależności od obfitości pokarmu. Miot może liczyć do siedmiu młodych; średnio w warunkach naturalnych rodzą się cztery osobniki — ich liczba również zależy od dostępności zasobów.

Ciąża u oposów wełnistych trwa stosunkowo krótko (24 dni), zaś okres usamodzielniania jest dość długi (młode są karmione nawet do 120 dni, a kolejne 30 – 45 dni spędzają w gnieździe matki). Opuszczenie gniazda matki jest bardzo ważnym etapem życia oposów wełnistych. W niewoli obserwowano przypadki zjadania matki przez młode, które nie zostały w odpowiednim momencie od niej odseparowane.

Oposy wełniste nie są wymieniane wśród gatunków zagrożonych, co przypisuje się ich niewielkiemu rozmiarowi oraz zdolnościom adaptacyjnym do różnych rodzajów lasów deszczowych. Ich status może jednak ulec zmianie wraz z postępującą wycinką lasów wiecznie zielonych.

Wiele zwierząt przedstawionych na okładkach książek wydawnictwa O’Reilly to gatunki zagrożone wyginięciem; każdy z nich jest bardzo cenny dla planety. Aby się dowiedzieć, jak możesz pomóc je chronić, odwiedź stronę http://animals.oreilly.com/.

Ilustracja na okładce pochodzi z książki Meyers Kleines Lexicon.

Przypisy Rozdział 1. Wstęp 1 Ze względu na popularność angielskich nazw narzędzi Gita i czynności wykonywanych w GitHubie polscy użytkownicy bardzo często używają takich nazw do opisywania konkretnych operacji. Z tego powodu osobom znającym choć trochę GitHub podane przykłady mogą wydać się sztuczne, użyłem ich jednak z myślą o uniknięciu nadmiaru anglicyzmów — przyp. tłum.

2 Angielskie określenie, w postaci fork, jest też najczęściej używane w tym kontekście przez polskich użytkowników — przyp. tłum.

Rozdział 4. Współpraca 1 Od ang. ship, czyli statek, ale także wysłać, dostarczyć — przyp. tłum.

2 Autorzy nawiązują do metodologii scrum — przyp. tłum.

3 Według tego schematu są tworzone wszystkie adresy stron WWW w GitHubie — przyp. tłum.

Rozdział 5. Tworzenie i konfigurowanie 1 GitHub nie obsługuje polskich znaków w nazwach organizacji, projektów itd. — przyp. tłum.

Skorowidz Każdemu elementowi indeksu odpowiada łącze prowadzące do sekcji, w której pojawia się dane pojęcie. Ponieważ w niektórych sekcjach znajduje się więcej niż jedno pole indeksowe dla tego samego pojęcia, niektórym elementom indeksu odpowiada więcej niż jedno łącze prowadzące do tej samej sekcji. Po kliknięciu łącza przeniesiesz się bezpośrednio do miejsca, w którym znajduje się dane pole indeksowe.

A akceptowanie zgłoszenia, 62 API, 88 automatyczne uzupełnianie nazwy, 86 automatyczny generator stron, 87 autoryzacja, 112 autoryzacja dwuetapowa, 116

B błąd autoryzacji, 112 Bootstrap, 17 branch, gałąź, 14

C changes, zmiany, 109 check out, weryfikacja, 15 clone, klonowanie, 16 commit message, komentarz do zmiany, 14 commit, zmiana, 14

D definiowanie nowego problemu, 65 dodawanie etykiety, 70 kamienia milowego, 68

klucza dostępu, 94 komentarza, 60 pliku, 34 stron, 74 usługi, 91 użytkownika, 99 współpracowników, 84 zespołu, 98 dokumentacja, 15 dostęp do repozytorium, 94

E edycja, 33 offline, 102 w IDE, 101 edytor tekstu vi, 123 edytowanie etykiety, 69 pliku, 44–47, 59 wielu plików, 102 ekran edytowania pliku, 47 podglądu zgłoszenia, 38 tworzenia zgłoszenia, 39 zgłoszeń, 38 emotikona, 58 etykiety, 15, 68

F feature branch, gałąź funkcji, 14 filtrowanie usług, 91 folder, 48 główny, 18 tworzenie, 49 zmiana nazwy, 49 fork, rozgałęzienie projektu, 16 forking, 11, 33 formatowanie, 74

formularz generowania stron, 76 nowego problemu, 66 repozytorium, 82

G gałąź, 14 base:master, 54 compare:master, 54 funkcji, 14 gh-pages, 78 główna, master, 14, 18, 78 new_feature, 110 tematyczna, 14 update_readme, 53, 54, 59 wydania, 14 generowanie stron WWW, 76 Git, 11 GitHub, 11 główny ekran programu, 118 GUI, 102

H historia zmian, 20, 44

I IDE, Integrated Development Environment, 101 informacje o zespole, 99 o zmianie, 41 informacyjne strony WWW, 75 inicjalizowanie repozytorium, 83 inicjowanie zgłoszenia, 54 instalacja programu, 115 w Mac OS, 104 integracja GitHuba

z Asaną, 93 z Basecampem, 92 interfejs graficzny, GUI, 102 interfejs programistyczny aplikacji, API, 88 issue, problem, zadanie, 11, 15, 22, 65

K kamienie milowe, 67, 68 karta perforowana, 29 klonowanie, 16 katalogu, 109 repozytorium, 101 klucz dostępu, 92–94 publiczny, 106, 118 komentarz, 58 do zmiany, 14, 60 z emotikonami, 58 komentowanie problemów, 70 zgłoszeń, 57 komunikat o błędzie autoryzacji, 112 konfigurowanie kluczy dostępu, 93 narzędzi, 123 repozytorium, 86 ustawień Gita, 105, 117 konto maszynowe, 94 kopia repozytorium, 34 kreator instalacji, 104 konfiguracji, 116

L liczba zgłoszeń, 23 lista Add service, 91

Contributions, 26 członków, 31 gałęzi, 52 Pages, 74 stron, 75 uczestników, 30 zmian, 20 logowanie, 105

M Mac OS, 103, 107, 112 master branch, gałąź główna, 14, 18, 78 menu Settings, 123 merge, scalanie, 15 merge commit, zatwierdzenie zgłoszenia, 42, 44 modyfikowanie zgłoszeń, 59

N narzędzie Bootstrap, 17 Issues, 70 Pages, 78 nazwa folderu, 49 nieprzesłane zmiany, 122 nowa zmiana, 61 nowe zgłoszenie, 55

O obsługa emotikonów, 58 Gita, 123 problemów i zadań, issues, 11 zdarzeń, 90, 91 odgałęzienia, 33, 34 odsyłacz 4 commits, 44 Graphs, 25

Issues, 23 Pull Requests, 20 Pulse, 23 Settings, 85, 86 Teams, 97 ograniczenia edytowania, 49 opcja Markdown, 73 opcje programu GitHub, 124 options, opcje, 123 organizacja, 95

P plik .gitkeep, 49 new_file.md, 38 README.md, 19, 44–46, 53, 83 windows_feature.html, 121 pobieranie, 101 podgląd, 73 gałęzi, 113 repozytorium, 121 strony, 74 ustawień, 113 zmian, 111 pole Edit Message, 74 Filter services, 91 Ignored files, 114 Summary, 111, 122 polecenie Options, 123 potwierdzenie usunięcia repozytorium, 89 powiadomienia o zgłoszeniach, 63 praca z folderami, 48 z wiki, 72 preview, podgląd, 73 problem, 15, 22–24, 65 program GitHub.app, 108 przeglądanie historii zmian, 20

projektu, 17 zgłoszeń, 22, 57 przenoszenie pliku, 47 przesyłanie repozytorium, 85 zmian, 110, 121 przycisk Add collaborator, 85 Add service, 91 Add webhook, 90 Automatic page generator, 87 branch:master, 51 cancel, 48 Clone, 109 Clone in Desktop, 107, 108, 118, 119 Comment, 57 Commit, 112 Create pull request, 55 Create repository, 83 Create team, 98 Delete this repository, 88 Done, 106 Download GitHub for Windows, 114 Edit, 45, 69, 74 Fork, 33 Install, 114 Install Command Line Tools, 106 Labels, 68 Launch Application, 109 Log in, 116 Merge pull request, 41, 62 Milestones, 67 New issue, 65, 66 New milestone, 67 New Page, 74 New pull request, 37 Remove, 99 Rename, 86 Settings, 76, 123 Submit new issue, 67 pull requests, zgłoszenia, 11, 15, 20, 33, 56

puls, 23, 24

R release branch, gałąź wydania, 14 repo, 34 repozytoria organizacji, 95 osobiste, 95 repozytorium, 81 Bootstrapa, 18 PeterBell, 40 single-repo-example, 52 root, 18 rozgałęzienie projektu, 16 rozwidlenie, 16 ruch sieciowy, 32

S scalanie, 15 sekcja Add a deploy key, 94 Danger Zone, 88 GitHub Pages, 78 Settings, 87 Uncomitted changes, 122 settings, ustawienia, 76 strona Add webhook, 90 główna organizacji, 97 Labels, 69 projektu, 17 Settings/Options, 87 Teams, 97, 99 wiki, 73 summary, streszczenie, 122 system kontroli wersji, 11 Mac OS, 102

szablon, 77

Ś środowiska programistyczne, 101

T tag, etykieta, 15 testowanie zgłoszenia, 61 tworzenie dokumentacji, wiki, 11 folderu, 49 gałęzi, 122 i konfigurowanie, 81 klucza dostępu, 94 kopii repozytorium, 34 kopii zapasowej, 101 nowego pliku, 35, 36 organizacji, 95, 96 repozytorium, 79, 81 rozgałęzień projektu, forking, 11 strony internetowej, 76, 78 strony w wiki, 73 zespołu, 98 zgłoszenia, 36, 39, 54

U uatrakcyjnianie komentarzy, 58 udział w projekcie, 33 umieszczanie odsyłacza, 74 uruchamianie programu, 102, 109, 119 usługi, 90, 91 ustawienia zespołu, 100 usuwanie repozytorium, 88

W

weryfikacja, 15 wiersz poleceń, 106, 123 wiki, 11, 15, 71 Windows, 114 właściciel repozytorium, 82 współpraca, 51 wykonywanie testów, 102 wykres aktywności, 27 częstotliwości zmian, 28, 29 liczby zmian, 28 ruchu sieciowego, 30–32 współpracowników, 25, 26 zmian, 27 WYSIWYG, 72 wysyłanie zgłoszeń, pull requests, 11 wyświetlanie pliku README.md, 19, 45 problemów, 22 pulsu, 23 wykresów, 25 zespołów, 98 zgłoszenia, 42, 43 zmian, 112

Z zadanie, 15 zakładka Changes, 109 Collaborators, 86 Deploy keys, 92 Issues, 67 Options, 86–88 Preview, 73 Pull Requests, 37, 54, 57 Settings, 113 z ustawieniami, 79 zalecenia dotyczące problemów, 70 zgłoszeń, 64

zalety Gita, 12 GitHuba, 13 zarządzanie etykietami, 68 kamieniami milowymi, 67 zespołami, 96 zatwierdzenie zgłoszenia, 42, 44 zdalne konto, 106 zespół, 96 zespół Owners, 97 zgłoszenia 15, 20–22, 33, 36–40, 54, 59 akceptowanie, 62 komentowanie, 57 modyfikowanie, 59 opinie, 56 powiadomienia, 63 przeglądanie, 57 testowanie, 61 tworzenie, 54 z gałęzi, 60 zalecenia, 64 zmian, 46 zmiana, 14 do przesłania, 122 nazwy folderu, 49 nazwy pliku, 47 początkowa, 53 w odgałęzieniu, 51 zmienianie kodu, 28 znaczniki, 73, 75 znak @, 56 krzyżyka, 70 ukośnika, 47 znaki ../, 48