Blog

W naszym ulubionym Open Source’owym programie brakuje nam funkcjonalności. Co zrobić? Odetchnąć z ulgą ;) w końcu to Open Source – możemy ją sobie po prostu dopisać. Wystarczy, że znajdziemy kod źródłowy naszego programu i dodamy niezbędną funkcję. Następnie możemy scalić ją do głównego nurtu projektu, aby inni użytkownicy także mogli korzystać z naszego programu.

W tej sytuacji z pewnością przyda się nam znajomość trójkątnego przepływu pracy w Git (ang. Git triangle workflow).

Trójkątny przepływ pracy w Git

Ideę trójkątnego przepływu pracy dobrze opisuje rysunek:

Repozytorium nadrzędne to główne repozytorium projektu. Nie mamy praw do zapisywania w nim. Jednak wciąż chcemy mieć dostęp do zmian (ang. commit), które są w nim wprowadzane.

Rozwidlenie to rozwidlenie repozytorium nadrzędnego (ang. fork). Nasza kopia, w której możemy zapisywać zmiany. Gdy skończymy naszą pracę, prosimy właścicieli repozytorium nadrzędnego o scalenie ich (wystawiamy pull request).

Ostatnim elementem jest repozytorium lokalne, które każdy ma na swojej stacji roboczej. Jest ono repliką rozwidlenia, ale ma także podłączone repozytorium nadrzędne, aby móc z niego pobierać zmiany.

Konfiguracja repozytoriów

Repozytorium nadrzędne

Nie wymaga żadnej dodatkowej konfiguracji – wystarczy, że jest dostępne z prawami odczytywania zawartości.

Rozwidlenie

Wystarczy, że utworzymy własną kopię nadrzędnego repozytorium. Można to osiągnąć między innymi, klikając przycisk „Fork” na stronie repozytorium nadrzędnego na GitHub czy GitLab.

Repozytorium lokalne

Tutaj dzieje się większość magii.

Zaczynamy klasycznie – kopiujemy repozytorium rozwidlenie

git clone ${ROZWIDLENIE_URL}

Następnie ustawiamy opcje:

git config remote.pushdefault origin 
git config push.default current

gdzie remote.pushdefault origin oznacza, że chcemy, aby domyślnie wszystkie gałęzie były wypychane do zdalnego repo „origin”, a push.default current sprawia, że gdy w poleceniu git push nie powiemy, jak lokalne gałęzie są mapowane do gałęzi w zdalnym repozytorium, to Git będzie próbował zmapować je po nazwie – połączy bieżącą lokalną gałąź z gałęzią w zdalnym repozytorium o tej samej nazwie.

W ten sposób mamy już ułożoną komunikację pomiędzy repozytorium lokalnym, a $ROZWIDLENIE.

Aby skończyć konfigurację, wystarczy już tylko jedno polecenie:

git remote add nadrzędne ${REPOZYTORIUM_NADRZĘDNE_URL}

Dodaliśmy zdalne repozytorium – aby się do niego odnieść, będziemy używać nazwy nadrzędne.

Możemy zweryfikować konfigurację poleceniem:

git remote -v

Jego wynik powinien wyglądać tak (oczywiście, zamiast zmiennych powinny być rzeczywiste wartości):

origin ${ROZWIDLENIE_URL} (fetch)
origin ${ROZWIDLENIE_URL} (push)
nadrzędne  ${REPOZYTORIUM_NADRZĘDNE_URL} (fetch)
nadrzędne  ${REPOZYTORIUM_NADRZĘDNE_URL} (push)

Codzienna praca

Zaciągamy zmiany z repozytorium nadrzędnego:

git fetch nadrzędne

Poleceniem:

git checkout -b nowa_gałąź nadrzędne/master

Tworzymy nową gałąź, która wywodzi się i śledzi gałąź master repozytorium nadrzędnego.

Dzięki czemu możemy bardzo łatwo scalać zmiany wprowadzone w repozytorium nadrzędnym za pomocą polecenia:

git pull

Dalej pracujemy już jak z każdą inną gałęzią.

Po wprowadzeniu zmian, możemy je wypchnąć do repozytorium ROZWIDLENIE poleceniem:

git push

Nie wymaga ono dodatkowych argumentów dzięki wcześniejszemu skonfigurowaniu remote.pushdefault oraz push.default current.

Zmienne te można nadpisać, więc jeśli mamy wątpliwości, gdzie zmiany zostaną wypchnięte, możemy je rozwiać, wywołując:

git push --dry-run

Jak widać skonfigurowanie trójkątnego przepływu pracy w git trwa chwilkę. Za to radość i satysfacja z dołożenia swojej cegiełki do ulubionego Open Source’owego programu trwa dużo, dużo dłużej. Mam nadzieję, że artykuł pomoże zacząć przygodę z Open Source od strony deweloperskiej ;)