Najpierw rzecz niezwiązana z tematem: Używacie Google Plus? Dodajcie mnie do swoich kręgów. Jak ktoś nie ma zaproszenia to napisać maila — podeślę.
Od kilku dobrych miesięcy GitHub jest moim ulubionym serwisem z dziedziny programowania. Najlepsze w nim jest to, że możemy za całkowitą darmochę tworzyć nowe projekty Open Source i obserwować rozwój istniejących. A co, jeżeli chcemy dorzucić do kodu coś od siebie? Wtedy musimy przestrzegać pewnych procedur, o których dzisiaj będzie wpis.
Zanim jednak to nastąpi, musimy nauczyć się obsługi Gita, czyli systemu kontroli wersji, który obowiązuje na GitHubie. Przyznam, że trzeba się trochę pomęczyć z konsolą żeby to ustrojstwo zaczęło nas słuchać. Jest oczywiście kilka nadbudówek graficznych, jednak aby dobrze poznać Gita, trzeba używać konsoli (analogicznie do stukania HTML i CSS w notatniku, bez żadnych podpowiadaczek). Nie będę w tym miejscu zasuwał wam poradnika obsługi Gita, zamiast tego skieruję do książki Pro Git o Gicie, rozwijanej… w Gicie :-D Pierwsze trzy rozdziały są ładnie przetłumaczone na polski, ja trochę tłumaczę kawałki czwartego.
Zakładam, że macie założone konto na GitHub.com. Zakładam również, że na swojej lokalnej maszynie macie zainstalowanego Gita. W Ubuntu proces składa się z wpisania w terminalu
sudo apt-get install git-core
na Windowsie nie wiem, nie znam się, nie chcę wiedzieć, nie używam ;-)
Do rzeczy:
1. Znajdując się w projekcie, który chcemy wspomóc, klikamy przycisk Fork, co utworzy naszą osobistą wersję projektu, nad którą mamy całkowitą władzę.
2. Tworzymy na naszym komputerze jakiś katalog, w którym trzymana będzie kopia projektu. Następnie inicjujemy Gita i klonujemy naszego forka na lokalną maszynę.
git init
git clone https://nasz_login@github.com/nasz_login/forkowany_projekt.git
3. Przyjęło się, że repozytorium, z którego forkujemy nazywa się upstream, a nasz fork nazywa się origin. Repozytorium origin tworzy się automatycznie przy klonowaniu. Upstream musimy sobie stworzyć sami.
git remote add upstream https://github.com/projekt_glowny/projekt_glowny.git
4. Tworzymy sobie gałąź związaną z problemem, którym chcemy się zająć (np. tłumaczeniem, zgłoszonym bugiem itp.) i przechodzimy do niej (w moim przypadku polish-translation). Nigdy nie wprowadzamy zmian w kodzie gałęzi master!
git branch polish-translation
git checkout polish-translation
W tym momencie możemy dzielnie walczyć z kodem. Pamiętamy jednak, że inni w tym samym czasie również pracują nad projektem i wprowadzają zmiany. Musimy co jakiś czas zsynchronizować się z tym co wytworzyli. Procedura składa się z kilku czynności:
– pobranie aktualnej wersji repozytorium upstream
– przejście do naszej głęzi master i synchronizacja jej z upstream
– synchronizacja naszej gałęzi roboczej z naszym masterem
git fetch upstream
git checkout master
git rebase upstream/master
git checkout polish-translation
git rebase master
Do synchronizacji zawsze używamy polecenia rebase, nigdy merge! Rebase opisany w podręczniku.
5. Zbijamy nasze cząstkowe zatwierdzenia zmian (brzydko zwane commitami) w jeden. Osoba, która będzie włączała naszą gałąź do głównego projektu nie będzie miała raczej ochoty wrzucać 10-ciu naszych commitów w stylu WTF it isn’t working?, fancy addition here, maybe this one will work itp. Wystarczy pojedyncze Fixed issue #5.
Początkującym może sprawić nieco trudności, dlatego krok po kroku wytłumaczę:
Powiedzmy, że nasze tłumaczenie składa się z 5 commitów. Jeżeli nie wiemy to używamy polecenia git log. Musimy cofnąć się o te 5 zmian i skleić je w jedną. Wpisujemy w terminalu
W edytorze pick zostawiamy tylko w pierwszym naszym commicie. Resztę zamieniamy na squash. Zapisujemy zmiany poprzez Ctrl+O, Enter i Ctrl+X. Następnie w pierwszej linijce wpisujemy ładny komunikat, a resztę linijek możemy poprzedzić haszem # Znowu Ctr+O, Enter, Ctrl + X. Sprawdzamy czy komunikat jest taki jak trzeba poprzez git log. Jeżeli nie, zawsze możemy użyć
i poprawić treść ostatniego commita.
6. Na wszelki wypadek wykonujemy ponownie procedurę synchronizacji z upstream. Jeżeli wszystko poszło dobrze, jesteśmy gotowi do przesłania naszych zmian na serwer origin (nasz fork na GitHubie).
git push origin polish-translation
7. Wchodzimy na stronę ze swoim forkiem i sprawdzamy czy w sekcji Switch Branches pojawiła się nasza gałąź. Jeżeli tak to klikamy na pull request, wybieramy naszą gałąź i zatwierdzamy prośbę o połączenie z gałęzią master forkowanego projektu.
Teraz pozostaje tylko cierpliwie czekać i mieć nadzieję, że autorom się spodoba i zatwierdzą zmiany. Jeżeli nie, w sekcji pull requests głównego projektu na pewno dostaniemy komunikat co jest nie tak.
O autorze