Najpierw rzecz niezwią­zana z tema­tem: Używa­cie Google Plus? Dodaj­cie mnie do swoich kręgów. Jak ktoś nie ma zapro­sze­nia to napi­sać maila — podeślę.

Od kilku dobrych miesięcy GitHub jest moim ulubio­nym serwi­sem z dzie­dziny progra­mo­wa­nia. Najlep­sze w nim jest to, że możemy za całko­witą darmo­chę tworzyć nowe projekty Open Source i obser­wo­wać rozwój istnie­ją­cych. A co, jeżeli chcemy dorzu­cić do kodu coś od siebie? Wtedy musimy prze­strze­gać pewnych proce­dur, 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 GitHu­bie. Przy­znam, że trzeba się trochę pomę­czyć z konsolą żeby to ustroj­stwo zaczęło nas słuchać. Jest oczy­wi­ście kilka nadbu­dó­wek graficz­nych, jednak aby dobrze poznać Gita, trzeba używać konsoli (analo­gicz­nie do stuka­nia HTML i CSS w notat­niku, bez żadnych podpo­wia­da­czek). Nie będę w tym miej­scu zasu­wał wam porad­nika obsługi Gita, zamiast tego skie­ruję do książki Pro Git o Gicie, rozwi­ja­nej… w Gicie Pierw­sze trzy rozdziały są ładnie prze­tłu­ma­czone na polski, ja trochę tłuma­czę kawałki czwartego.

Zakła­dam, że macie zało­żone konto na GitHub.com. Zakła­dam również, że na swojej lokal­nej maszy­nie macie zain­sta­lo­wa­nego Gita. W Ubuntu proces składa się z wpisa­nia w terminalu

sudo apt-get install git-core

na Window­sie nie wiem, nie znam się, nie chcę wiedzieć, nie używam

Do rzeczy:
1. Znaj­du­jąc się w projek­cie, który chcemy wspo­móc, klikamy przy­cisk Fork, co utwo­rzy naszą osobi­stą wersję projektu, nad którą mamy całko­witą władzę.

2. Tworzymy na naszym kompu­te­rze jakiś kata­log, w którym trzy­mana będzie kopia projektu. Następ­nie inicju­jemy Gita i klonu­jemy naszego forka na lokalną maszynę.

git init
git clone https://nasz_login@github.com/nasz_login/forkowany_projekt.git

3. Przy­jęło się, że repo­zy­to­rium, z którego forku­jemy nazywa się upstream, a nasz fork nazywa się origin. Repo­zy­to­rium origin tworzy się auto­ma­tycz­nie przy klono­wa­niu. Upstream musimy sobie stwo­rzyć sami.

git remote add upstream https://github.com/projekt_glowny/projekt_glowny.git

4. Tworzymy sobie gałąź zwią­zaną z proble­mem, którym chcemy się zająć (np. tłuma­cze­niem, zgło­szo­nym bugiem itp.) i prze­cho­dzimy do niej (w moim przy­padku polish-translation). Nigdy nie wpro­wa­dzamy zmian w kodzie gałęzi master!

git branch polish-translation
git checkout polish-translation

W tym momen­cie możemy dziel­nie walczyć z kodem. Pamię­tamy jednak, że inni w tym samym czasie również pracują nad projek­tem i wpro­wa­dzają zmiany. Musimy co jakiś czas zsyn­chro­ni­zo­wać się z tym co wytwo­rzyli. Proce­dura składa się z kilku czyn­no­ści:
– pobra­nie aktu­al­nej wersji repo­zy­to­rium upstream
– przej­ście do naszej głęzi master i synchro­ni­za­cja jej z upstream
– synchro­ni­za­cja naszej gałęzi robo­czej z naszym masterem

git fetch upstream
git checkout master
git rebase upstream/master
git checkout polish-translation
git rebase master

Do synchro­ni­za­cji zawsze używamy pole­ce­nia rebase, nigdy merge! Rebase opisany w podręcz­niku.

5. Zbijamy nasze cząst­kowe zatwier­dze­nia zmian (brzydko zwane commi­tami) w jeden. Osoba, która będzie włączała naszą gałąź do głów­nego projektu nie będzie miała raczej ochoty wrzu­cać 10-ciu naszych commi­tów w stylu WTF it isn’t working?, fancy addi­tion here, maybe this one will work itp. Wystar­czy poje­dyn­cze Fixed issue #5.
Począt­ku­ją­cym może spra­wić nieco trud­no­ści, dlatego krok po kroku wytłu­ma­czę:
Powiedzmy, że nasze tłuma­cze­nie składa się z 5 commi­tów. Jeżeli nie wiemy to używamy pole­ce­nia git log. Musimy cofnąć się o te 5 zmian i skleić je w jedną. Wpisu­jemy w terminalu

git rebase -i HEAD~5

W edyto­rze pick zosta­wiamy tylko w pierw­szym naszym commi­cie. Resztę zamie­niamy na squash. Zapi­su­jemy zmiany poprzez Ctrl+O, Enter i Ctrl+X. Następ­nie w pierw­szej linijce wpisu­jemy ładny komu­ni­kat, a resztę lini­jek możemy poprze­dzić haszem # Znowu Ctr+O, Enter, Ctrl + X. Spraw­dzamy czy komu­ni­kat jest taki jak trzeba poprzez git log. Jeżeli nie, zawsze możemy użyć

git commit --amend

i popra­wić treść ostat­niego commita.

6. Na wszelki wypa­dek wyko­nu­jemy ponow­nie proce­durę synchro­ni­za­cji z upstream. Jeżeli wszystko poszło dobrze, jeste­śmy gotowi do prze­sła­nia naszych zmian na serwer origin (nasz fork na GitHubie).

git push origin polish-translation

7. Wcho­dzimy na stronę ze swoim forkiem i spraw­dzamy czy w sekcji Switch Bran­ches poja­wiła się nasza gałąź. Jeżeli tak to klikamy na pull requ­est, wybie­ramy naszą gałąź i zatwier­dzamy prośbę o połą­cze­nie z gałę­zią master forko­wa­nego projektu.
Teraz pozo­staje tylko cier­pli­wie czekać i mieć nadzieję, że auto­rom się spodoba i zatwier­dzą zmiany. Jeżeli nie, w sekcji pull requ­ests głów­nego projektu na pewno dosta­niemy komu­ni­kat co jest nie tak.