Przepływ pracy z podziałem
Przepływ pracy oparty na podziałach różni się zasadniczo od innych popularnych przepływów pracy Git. W miejsce korzystania z jednego repozytorium po stronie serwera, które pełniłoby funkcję „centralnej” bazy kodu, sprawia, że każdy programista ma do dyspozycji własne repozytorium po stronie serwera. Oznacza to, że każdy autor kodu dysponuje nie jednym, tylko dwoma repozytoriami Git: prywatnym repozytorium lokalnym i publicznym repozytorium po stronie serwera. Przepływ pracy oparty na podziałach jest najczęściej widoczny w publicznych projektach open source.
Główną zaletą przepływu pracy opartego na podziałach jest to, że nowy kod może być integrowany bez potrzeby wypychania go przez wszystkich do jednego centralnego repozytorium. Programiści wypychają kod do własnych repozytoriów po stronie serwera, a tylko opiekun projektu może wypchnąć zmiany do oficjalnego repozytorium. Pozwala to opiekunowi akceptować commity od dowolnego programisty, nie dając mu dostępu do oficjalnej bazy kodu.
Przepływ pracy oparty na podziałach zazwyczaj jest zgodny z modelem tworzenia gałęzi opartym na przepływie pracy Gitflow. Oznacza to, że kompletne gałęzie obiektów będą przeznaczone do scalenia w repozytorium opiekuna oryginalnego projektu. Rezultatem jest rozproszony przepływ pracy, który zapewnia elastyczny sposób bezpiecznej współpracy dużych, organicznych zespołów (w tym niezaufanych stron trzecich). To również sprawia, że jest to idealny przepływ pracy dla projektów open source.
Jak to działa
Podobnie jak w innych przepływach pracy Git, przepływ pracy oparty na podziała zaczyna się od oficjalnego publicznego repozytorium przechowywanego na serwerze. Natomiast kiedy nowy programista chce rozpocząć pracę nad projektem, nie klonuje bezpośrednio oficjalnego repozytorium.
Zamiast tego dzieli oficjalne repozytorium, aby utworzyć jego kopię na serwerze. Ta nowa kopia służy jako osobiste publiczne repozytorium tej osoby — żadni inni programiści nie mogą wypychać do niej kodu, ale mogą pobierać z niej zmiany (za chwilę zobaczymy, dlaczego jest to ważne). Po utworzeniu kopii po stronie serwera programista wykonuje polecenie git clone, aby uzyskać kopię na swoim lokalnym komputerze. Służy ona jako prywatne środowisko programistyczne, podobnie jak w innych przepływach pracy.
Gdy programista jest gotowy do opublikowania lokalnego commitu, wypycha go do swojego publicznego, a nie do oficjalnego repozytorium. Następnie zgłasza pull request w repozytorium głównym, dzięki czemu opiekun projektu wie, że aktualizacja jest gotowa do zintegrowania. Pull request służy również jako wygodny wątek dyskusyjny, jeśli istnieją problemy z dodanym kodem. Poniżej przedstawiono przykładowy przepływ pracy krok po kroku.
materiały pokrewne
Zaawansowany dziennik Git
POZNAJ ROZWIĄZANIE
Poznaj środowisko Git z rozwiązaniem Bitbucket Cloud
1. Programista tworzy podział „oficjalnego” repozytorium po stronie serwera. W ten sposób tworzy własną kopię po stronie serwera.
2. Nowa kopia po stronie serwera jest klonowana do systemu lokalnego.
3. Do lokalnego klonu dodawana jest zdalna ścieżka Git dla „oficjalnego” repozytorium.
4. Zostanie utworzona nowa, lokalna gałąź funkcji.
5. Programista wprowadza zmiany w nowej gałęzi.
6. Tworzone są nowe commity dla zmian.
7. Gałąź zostaje wypchnięta do własnej kopii po stronie serwera programisty.
8. Programista tworzy pull request z nowej gałęzi do „oficjalnego” repozytorium.
9. Pull request zostaje zatwierdzony do scalenia i jest scalany z oryginalnym repozytorium po stronie serwera
Aby zintegrować tę funkcję z oficjalną bazą kodu, opiekun pobiera zmiany współtwórcy do lokalnego repozytorium, sprawdza, czy nie uszkodzi projektu, łączy go z lokalną gałęzią main, a następnie wypycha gałąź main do oficjalnego repozytorium na serwerze. Dodany kod jest teraz częścią projektu, a inni programiści powinni ściągnąć zmiany z oficjalnego repozytorium, aby zsynchronizować swoje repozytoria lokalne.
Ważne jest, aby zrozumieć, że pojęcie „oficjalnego” repozytorium w przepływie pracy opartym na podziałach jest jedynie konwencją. Tak naprawdę dane repozytorium jest oficjalne tylko dlatego, że jest publicznym repozytorium opiekuna projektu.
Różnice między tworzeniem podziału i klonowaniem
Należy pamiętać, że repozytoria „podzielone” i „tworzenie podziału” nie są operacjami specjalnymi. Podział repozytoriów odbywa się za pomocą standardowego polecenia git clone. Podzielone repozytoria są zazwyczaj „klonami po stronie serwera” i zwykle są zarządzane i hostowane przy użyciu zewnętrznej usługi Git, takiej jak Bitbucket. Nie ma unikalnego polecenia Git do tworzenia podziałów repozytoriów. Operacja klonowania powoduje zasadniczo skopiowanie repozytorium i jego historii.
Tworzenie gałęzi w przepływie pracy podziału
Wszystkie te osobiste repozytoria publiczne są tak naprawdę tylko wygodnym sposobem udostępniania gałęzi innym programistom. Każdy powinien nadal używać gałęzi do izolowania poszczególnych funkcji, tak jak w przepływie pracy gałęzi funkcji i przepływie pracy Gitflow. Jedyna różnica polega na tym, jak te gałęzie są udostępniane. W przepływie pracy podziału są ściągane do lokalnego repozytorium innego programisty, a w przepływie pracy gałęzi funkcji i przepływie pracy Gitflow są wypychane do oficjalnego repozytorium.
Podział repozytorium
Wszyscy nowi programiści w projekcie opartym na przepływie pracy podziału muszą podzielić oficjalne repozytorium na mniejsze części. Jak już wspomniano, podział jest standardową operacją git clone. Można to zrobić, nawiązując połączenie SSH z serwerem i uruchamiając polecenie git clone, aby skopiować repozytorium do innej lokalizacji na serwerze. Popularne usługi hostingowe Git, takie jak Bitbucket, oferują funkcje dzielenia repozytorium, które automatyzują ten krok.
Klonowanie podziału
Wszyscy nowi programiści w projekcie opartym na przepływie pracy podziału muszą podzielić oficjalne repozytorium na mniejsze części. Jak już wspomniano, podział jest standardową operacją git clone. Można to zrobić, nawiązując połączenie SSH z serwerem i uruchamiając polecenie git clone, aby skopiować repozytorium do innej lokalizacji na serwerze. Popularne usługi hostingowe Git, takie jak Bitbucket, oferują funkcje dzielenia repozytorium, które automatyzują ten krok.
Zakładając użycie Bitbucket do hostowania tych repozytoriów, programiści w projekcie powinni mieć własne konto Bitbucket i sklonować podzieloną kopię repozytorium za pomocą polecenia:
git clone https://user@bitbucket.org/user/repo.gitDodawanie repozytorium zdalnego
Podczas gdy inne przepływy pracy Git używają jednego źródła zdalnego, które odwołuje się do centralnego repozytorium, przepływ pracy podziału wymaga dwóch zdalnych lokalizacji — jednej dla repozytorium oficjalnego oraz jednej dla osobistego repozytorium programisty po stronie serwera. Chociaż możesz nazwać te zdalne lokalizacje jak chcesz, powszechną konwencją jest używanie origin jako lokalizacji zdalnej podzielonego repozytorium (zostanie utworzone automatycznie, gdy uruchomisz polecenie git clone) i upstream dla repozytorium oficjalnego.
git remote add upstream https://bitbucket.org/maintainer/repoMusisz samodzielnie utworzyć zdalną lokalizację upstream za pomocą powyższego polecenia. Umożliwi to łatwe aktualizowanie lokalnego repozytorium w miarę postępu prac w oficjalnym projekcie. Zauważ, że jeśli Twoje repozytorium upstream ma włączone uwierzytelnianie (tzn. nie jest open source), musisz podać nazwę użytkownika, w ten sposób:
git remote add upstream https://user@bitbucket.org/maintainer/repo.gitWymaga to od użytkowników podania prawidłowego hasła przed klonowaniem lub ściągnięciem danych z oficjalnej bazy kodu.
Praca w gałęzi: wprowadzanie i wypychanie zmian
W lokalnej kopii podzielonego repozytorium programista może edytować kod, wprowadzać zmiany i tworzyć gałąź, tak jak w innych przepływach pracy Git:
git checkout -b some-feature # Edit some code git commit -a -m "Add first draft of some feature"Wszystkie ich zmiany będą całkowicie prywatne, dopóki nie wypchną ich do publicznego repozytorium. A jeśli oficjalny projekt posunął się do przodu, mogą uzyskać dostęp do nowych commitów za pomocą git pull:
git pull upstream mainProgramiści powinni pracować w dedykowanej gałęzi funkcji, dlatego powinno to generalnie skutkować scalaniem z przewijaniem.
Wykonywanie polecenia pull request
Gdy programista będzie gotowy do udostępnienia swojej nowej funkcji, musi zrobić dwie rzeczy. Po pierwsze, musi udostępnić swój kod innym programistom, wypychając go do swojego publicznego repozytorium. Jego zdalna lokalizacja źródłowa powinna być już skonfigurowana, więc wystarczy, że wykona polecenie:
git push origin feature-branchTen przepływ pracy różni się od innych tym, że zdalne źródło wskazuje na osobiste repozytorium programisty po stronie serwera, a nie na główną bazę kodu.
Po drugie programista musi powiadomić opiekuna projektu, że chce włączyć swoją funkcję do oficjalnej bazy kodu. Bitbucket udostępnia przycisk „pull request”, który prowadzi do formularza z prośbą o określenie, którą gałąź chcesz połączyć z oficjalnym repozytorium. Zazwyczaj integrowana jest gałąź feature z gałęzią main w zdalnej lokalizacji upstream.
Podsumowanie
Podsumowując, proces podziału jest powszechnie stosowany w publicznych projektach open-source. Podział jest operacją git clone wykonywaną na kopii repozytorium projektu na serwerze. Przepływ pracy z podziałem jest często używany w połączeniu z usługą hostingową Git, taką jak Bitbucket. Przykład wysokiego poziomu przepływu pracy z podziałem:
1. Chcesz dodać kod do biblioteki open source hostowanej pod adresem bitbucket.org/userA/open-project
2. Używając Bitbucket, tworzysz podział repozytorium pod adresem Bitbucket.org/twoja-nazwa/open-project
3. W lokalnym systemie wykonujesz polecenie git clone na repozytorium https://bitbucket.org/TwojaNazwa/open-project, aby utworzyć jego kopię lokalną
4. Tworzysz nową gałąź feature w repozytorium lokalnym
5. Pracujesz nad nową funkcją i wykonujesz polecenie git commit, aby zapisać zmiany
6. Następnie wypychasz nową gałąź feature do zdalnego repozytorium utworzonego przez podział
7. Przy użyciu Bitbucket otwierasz pull request dla nowej gałęzi pierwotnego repozytorium pod adresem bitbucket.org/userA/open-project
Przepływ pracy oparty na podziale projektu pomaga opiekunowi projektu otworzyć repozytorium na wkład innych programistów bez konieczności ręcznego zarządzania ustawieniami autoryzacji dla każdego współpracownika. Daje to opiekunowi większe możliwości pracy w stylu „pull”. Przepływy pracy oparty na podziale są najczęściej stosowane w projektach open source, ale mogą być również używane w prywatnych projektach biznesowych, aby zapewnić większą kontrolę nad scaleniami w wydaniu. Może to być przydatne w zespołach, które mają menedżerów ds. wdrożeń lub ściśle ustalone cykle wydań.
Nie wiesz, jaki przepływ pracy jest dla Ciebie odpowiedni? Sprawdź naszą obszerną stronę z porównaniem przepływów pracy Git.
Udostępnij ten artykuł
Następny temat
Zalecane lektury
Dodaj te zasoby do zakładek, aby dowiedzieć się więcej na temat rodzajów zespołów DevOps lub otrzymywać aktualności na temat metodyki DevOps w Atlassian.
Blog Bitbucket
Ścieżka szkoleniowa DevOps
