Wysyłanie polecenia pull request
Pull requests are a feature that makes it easier for developers to collaborate using Bitbucket. They provide a user-friendly web interface for discussing proposed changes before integrating them into the official project.
W najprostszej formie pull requesty są mechanizmem powiadamiania członków zespołu przez programistę, że ukończyli funkcję. Gdy gałąź funkcji będzie gotowa, programista wykona pull request za pośrednictwem swojego konta Bitbucket. Dzięki temu wszyscy zaangażowani wiedzą, że muszą przejrzeć kod i scalić go z gałęzią main.
Jednak pull request to coś więcej niż tylko powiadomienie — to dedykowane forum do omawiania proponowanej funkcji. Jeśli wystąpią jakiekolwiek problemy ze zmianami, członkowie zespołu mogą publikować opinie w pull requestach, a nawet modyfikować tę funkcję, wypychając kolejne commity. Cała ta aktywność jest śledzona bezpośrednio w pull requestach.
W porównaniu z innymi modelami współpracy to formalne rozwiązanie do udostępniania commitów zapewnia znacznie sprawniejszy przepływ pracy. SVN i Git mogą automatycznie wysyłać e-maile z powiadomieniami za pomocą prostego skryptu. Jednak w przypadku omawiania zmian programiści zazwyczaj muszą polegać na wątkach e-mail. To może być ryzykowne — zwłaszcza gdy w grę wchodzą kolejne commity. Pull requesty zbierają wszystkie te funkcje w przyjaznym interfejsie internetowym tuż obok repozytoriów Bitbucket.
Jak działa pull request?
Gdy wykonujesz pull request, wysyłasz jedynie prośbę o ściągnięcie kodu przez innego programistę (np. opiekuna projektu) z gałęzi Twojego repozytorium do repozytorium tej osoby. Oznacza to, że musisz podać 4 informacje, aby wykonać pull request: repozytorium źródłowe, gałąź źródłową, repozytorium docelowe i gałąź docelową.
Wiele z tych wartości Bitbucket rozpozna i ustawi domyślnie. Jednak w zależności od przepływu współpracy zespół może wymagać określenia różnych wartości. Na powyższym schemacie przedstawiono pull request z prośbą o scalenie gałęzi funkcji w oficjalną gałąź główną, ale istnieje wiele innych sposobów korzystania z operacji pull request.
Jak to działa
Pull requestów można używać w połączeniu z przepływem pracy gałęzi funkcji, przepływem pracy Gitflow lub przepływem pracy Forking. Pull request wymaga jednak dwóch odrębnych gałęzi lub repozytoriów, więc nie będzie działać ze scentralizowanym przepływem pracy. Używanie pull requestów z każdym z tych przepływów pracy przebiega nieco inaczej, ale ogólny proces wygląda następująco:
1. Programista tworzy funkcję w dedykowanej gałęzi w lokalnym repozytorium.
2. The developer pushes the branch to a public Bitbucket repository.
3. The developer files a pull request via Bitbucket.
4. The rest of the team reviews the code, discusses it, and alters it.
5. The project maintainer merges the feature into the official repository and closes the pull request.
W dalszej części tej sekcji opisano sposób wykorzystywania pull requestów w różnych przepływach współpracy.
materiały pokrewne
Zaawansowany dziennik Git
POZNAJ ROZWIĄZANIE
Poznaj środowisko Git z rozwiązaniem Bitbucket Cloud
Przepływ pracy gałęzi funkcji z pull requestami
Przepływ pracy gałęzi funkcji korzysta z udostępnionego repozytorium Bitbucket do zarządzania współpracą, a programiści mogą tworzyć funkcje w odizolowanych gałęziach. Jednak zamiast natychmiast łączyć je z gałęzią main, programiści powinni wykonać pull request, aby zainicjować dyskusję na temat funkcji, zanim zostanie ona zintegrowana z główną bazą kodu.
W przepływie pracy gałęzi funkcji jest tylko jedno publiczne repozytorium, więc docelowe repozytorium pull requesta i repozytorium źródłowe będą zawsze takie same. Zwykle programista określa swoją gałąź funkcji jako gałąź źródłową, a gałąź main jako gałąź docelową.
Po otrzymaniu pull requesta opiekun projektu musi zdecydować, co zrobić. Jeśli funkcja jest gotowa, może po prostu scalić ją z gałęzią main i zamknąć pull request. Jednak w przypadku problemów z proponowanymi zmianami może skomentować pull request. Kolejne commity pojawią się tuż obok odpowiednich komentarzy.
Można również utworzyć pull request dla funkcji, która jest niekompletna. Jeśli na przykład programista ma problemy z wdrożeniem określonego wymogu, może utworzyć pull request zawierający prace w toku. Inni programiści mogą następnie dodać sugestie w ramach pull requesta, a nawet samodzielnie rozwiązać problem za pomocą dodatkowych commitów.
Przepływ Gitflow z pull requestami
Przepływ pracy Gitflow jest podobny do przepływu pracy gałęzi funkcji, ale definiuje ścisły model rozgałęzienia zaprojektowany wokół wersji projektu. Dodanie pull requesta do przepływu pracy Gitflow zapewnia programistom wygodne miejsce do rozmowy o gałęzi wydania lub gałęzi serwisowej podczas pracy nad nią.
Działanie pull requestów w przepływie pracy Gitflow wygląda tak samo jak w poprzedniej sekcji — programista po prostu tworzy pull request, gdy funkcja, wydanie lub gałąź poprawek wymaga oceny, a reszta zespołu otrzymuje powiadomienie w Bitbucket.
Funkcje są generalnie scalane z gałęzią develop, a gałęzie wydania i poprawek są scalane zarówno z gałęziami develop, jak i main. Pull requestów można używać do formalnego zarządzania wszystkimi tymi scaleniami.
Przepływ pracy Forking z pull requestami
W przepływie pracy Forking (podział) programista wypycha ukończoną funkcję do własnego repozytorium publicznego zamiast do udostępnionego. Następnie przesyła pull request, aby poinformować opiekuna projektu, że jest gotowy do sprawdzenia.
Aspekt powiadamiania o pull requestach jest szczególnie przydatny w tym przepływie pracy, ponieważ opiekun projektu nie wie, kiedy inny programista dodaje commity do swojego repozytorium Bitbucket.
Każdy programista ma swoje własne publiczne repozytorium, dlatego repozytorium źródłowe pull requesta będzie się różnić od repozytorium docelowego. Repozytorium źródłowe jest publicznym repozytorium programisty, a gałąź źródłowa to ta, która zawiera proponowane zmiany. Jeśli programista próbuje scalić tę funkcję z główną bazą kodu, repozytorium docelowe jest oficjalnym projektem, a gałąź docelowa to main.
Pull requesty mogą być również służyć do współpracy z innymi programistami spoza oficjalnego projektu. Jeśli na przykład programista pracował nad funkcją z kolegą z zespołu, mógł utworzyć pull request za pomocą repozytorium Bitbucket kolegi z zespołu dla miejsca docelowego zamiast oficjalnego projektu. Następnie mogą użyć tej samej gałęzi funkcji dla gałęzi źródłowych i docelowych.
Dwaj programiści mogą omówić i rozwinąć tę funkcję w ramach pull requesta. Kiedy skończą, jeden z nich może utworzyć kolejny pull request z prośbą o scalenie funkcji z oficjalną główną gałęzią. Ta elastyczność sprawia, że pull requesty są potężnym narzędziem do współpracy w przepływie pracy podziału.
Przykład
W poniższym przykładzie pokazano, jak można używać pull requestów w przepływie pracy Forking. Dotyczy to zarówno programistów pracujących w małych zespołach, jak i zewnętrznego programisty współtworzącego projekt open source.
W tym przykładzie Mary jest programistką, a John opiekunem projektu. Oboje mają własne publiczne repozytoria Bitbucket, a repozytorium Johna zawiera oficjalny projekt.
Mary dzieli oficjalny projekt
Aby rozpocząć pracę w projekcie, Mary najpierw musi podzielić repozytorium Bitbucket Johna. Może to zrobić, logując się do Bitbucket, przechodząc do repozytorium Johna i klikając przycisk [Fork].
Po wprowadzeniu nazwy i opisu repozytorium utworzonego przez podział Mary będzie miała kopię projektu po stronie serwera.
Mary klonuje swoje repozytorium Bitbucket
Następnie Mary musi sklonować repozytorium Bitbucket, które właśnie podzieliła. Dzięki temu będzie mieć kopię roboczą projektu na swoim komputerze lokalnym. W tym celu może uruchomić następujące polecenie:
git clone https://user@bitbucket.org/user/repo.gitPamiętaj, że polecenie git clone automatycznie tworzy zdalną lokalizację źródłową, która wskazuje podzielone repozytorium Mary.
Mary tworzy nową funkcję
Zanim Mary zacznie pisać kod, musi utworzyć nową gałąź funkcji. Użyje jej jako gałęzi źródłowej pull requesta.
git checkout -b some-feature
# Edit some code
git commit -a -m "Add first draft of some feature"Mary może użyć tylu commitów, ile potrzebuje, aby utworzyć tę funkcję. Jeśli historia tej funkcji jest mniej uporządkowana, niż Mary by sobie życzyła, może użyć funkcji interaktywnej zmiany bazy, aby usunąć lub połączyć niepotrzebne commity. W przypadku większych projektów czyszczenie historii funkcji znacznie ułatwia opiekunowi projektu sprawdzenie, co dzieje się w pull requeście.
Mary wypycha funkcję do swojego repozytorium Bitbucket
Po zakończeniu tworzenia funkcji Mary wypycha gałąź funkcji do własnego repozytorium Bitbucket (nie do oficjalnego repozytorium) za pomocą prostego polecenia git push:
git push origin some-branchDzięki temu jej zmiany są dostępne dla opiekuna projektu (lub współpracowników, którzy też mogą potrzebować dostępu).
Mary tworzy pull request
Po utworzeniu gałęzi funkcji w Bitbucket Mary może utworzyć pull request przy użyciu swojego konta Bitbucket, przechodząc do podzielonego repozytorium i klikając przycisk [Pull request] w prawym górnym rogu. Wynikowy formularz automatycznie ustawia repozytorium Mary jako źródłowe i prosi ją o określenie gałęzi źródłowej, repozytorium docelowego oraz gałęzi docelowej.
Mary chce scalić funkcję z główną bazą kodu, więc gałęzią źródłową jest jej gałąź funkcji, repozytorium docelowym jest publiczne repozytorium Johna, a gałąź docelowa to main. Mary musi również podać tytuł i opis pull requesta. Jeśli są inne osoby, które oprócz Johna muszą zatwierdzić kod, może wprowadzić je w polu [Reviewers].
Po utworzeniu pull requesta powiadomienie zostanie wysłane do Johna za pośrednictwem jego kanału Bitbucket i (opcjonalnie) pocztą e-mail.
John sprawdza pull request
John może uzyskać dostęp do wszystkich pull requestów zgłoszonych przez użytkowników, klikając kartę [Pull request] we własnym repozytorium Bitbucket. Kliknięcie pull requesta Mary spowoduje wyświetlenie jego opisu i historii zatwierdzania funkcji oraz porównanie różnicowe wszystkich zawartych w nim zmian.
Jeśli John uzna, że funkcja jest gotowa do scalenia z projektem, musi jedynie kliknąć przycisk [Merge], aby zatwierdzić pull request i scalić funkcję Mary ze swoją gałęzią main.
Jednak w tym przykładzie załóżmy, że John znalazł mały błąd w kodzie Mary i chce, żeby go ona poprawiła przed scaleniem kodu. Może opublikować komentarz do pull requesta jako całości lub wybrać konkretny commit w historii funkcji, aby go skomentować.
Mary dodaje kolejny commit
Jeśli Mary ma jakiekolwiek pytania dotyczące opinii, może odpowiedzieć w ramach pull requesta, traktując go jako forum dyskusyjne dla swojej funkcji.
Aby poprawić błąd, Mary dodaje kolejny commit do gałęzi funkcji i wypycha go do swojego repozytorium Bitbucket, tak jak zrobiła to za pierwszym razem. Ten commit jest automatycznie dodawany do oryginalnego pull requesta, a John może ponownie przejrzeć zmiany, widząc tuż obok swój pierwotny komentarz.
John akceptuje pull request
Na koniec John zaakceptuje zmiany, scali gałąź funkcji z gałęzią main i zamknie pull request. Ta funkcja jest teraz zintegrowana z projektem, a wszyscy inni programiści pracujący nad nim mogą ściągnąć ją do swoich lokalnych repozytoriów za pomocą standardowego polecenia git pull.
Co dalej
Teraz masz wszystkie narzędzia potrzebne do rozpoczęcia integracji pull requestów z istniejącym przepływem pracy. Pamiętaj, że pull requesty nie zastępują żadnego z przepływów współpracy opartych na Git, ale są raczej wygodnym dodatkiem do nich, który ułatwia współpracę wszystkim członkom zespołu.
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
