Tworzenie gałęzi za pomocą Bitbucket Cloud
Cel
Z pomocą tego samouczka poznasz podstawy tworzenia, przeglądania i scalania gałęzi, a także pracy w gałęziach przy użyciu Git i Bitbucket Cloud.
Czas
35 minut
Publiczność
Znasz już podstawy zagadnienia przepływów pracy Git
Ten samouczek jest przeznaczony dla osób, które znają już podstawowe koncepcje przepływów pracy Git, w tym:
- Klonowanie: kopiowanie zdalnego repozytorium w usłudze Bitbucket Cloud do systemu lokalnego
- Dodawanie / przenoszenie do przechowalni: przygotowywanie wykonanych zmian w celu dodania ich do historii Git
- Zatwierdzanie: dodawanie nowych lub zmienionych plików do historii Git dla repozytorium
- Ściąganie: pobieranie do lokalnego repozytorium zmian dodanych przez inne osoby
- Wypychanie: przenoszenie zmian z systemu lokalnego do zdalnego repozytorium
Jeśli nie znasz podstaw Git, nie martw się — po prostu skorzystaj z naszego samouczka Poznaj środowisko Git z rozwiązaniem Bitbucket Cloud, a prędko będziesz na bieżąco.
Dlaczego tworzenie gałęzi ma znaczenie
Tworzenie gałęzi to jeden z najlepszych sposobów na wykorzystanie możliwości Git w zakresie kontroli wersji. Tworzenie gałęzi w Git umożliwia:
- Jednoczesną pracę kilku zespołów na bazie jednego repozytorium.
- Współpracę członków zespołu z dowolnego miejsca na świecie za pomocą Bitbucket Cloud.
- Jednoczesne prowadzenie wielu linii prac programistycznych niezależnie od siebie bez potrzeby zamrożeń kodu.
Poproś o konfigurację
Ponieważ chcemy Ci zapewnić poczucie pracy w zespole, we wspólnym repozytorium Bitbucket, proponujemy dokonanie podziału dostarczonego przez nas publicznego repozytorium.
Czym jest podział (fork)?
Podział to kolejny sposób zapisywania klonu lub kopii. Termin pochodzi od wywołania systemowego „fork” w Uniksie, które tworzy kopię istniejącego procesu. Efekt końcowy jest zatem, w przeciwieństwie do gałęzi, niezależny od oryginalnego repozytorium. W przypadku usunięcia oryginalnego repozytorium fork będzie istniał nadal. Dokonując podziału repozytorium, otrzymujesz je wraz z wszystkimi jego gałęziami.
1. Wejdź na stronę tutorials/tutorials.git.bitbucket.org
2. Kliknij + > Fork this repository (Podziel to repozytorium) po lewej stronie ekranu.
3. Zmodyfikuj pole Name tak, aby nazwa była unikatowa dla Twojego zespołu, a następnie kliknij Fork repository (Podziel repozytorium).
4. Utwórz dla repozytorium katalog o łatwym dostępie. Polecenie może wyglądać następująco:
POZNAJ ROZWIĄZANIE
Poznaj środowisko Git z rozwiązaniem Bitbucket Cloud
materiały pokrewne
Polecenia Git
$ mkdir test-repositories $ cd test-repositories/ $ test-repositoriesW powyższym przykładzie widzimy utworzenie katalogu test-repositories za pomocą polecenia mkdir (make directory) oraz przełączenie do tego katalogu za pomocą polecenia cd (change directory).
5. Sklonuj podzielone repozytorium do właśnie utworzonego katalogu. Widok powinien być mniej więcej następujący:
$ git clone https://dstevenstest@bitbucket.org/dstevenstest/mygittutorial.bitbucket.io.git Cloning into 'mygittutorial.bitbucket.io'... remote: Counting objects: 12392, done. remote: Compressing objects: 100% (12030/12030), done. remote: Total 12392 (delta 8044), reused 564 (delta 360) Receiving objects: 100% (12392/12392), 2.72 MiB | 701.00 KiB/s, done. Resolving deltas: 100% (8044/8044), done. $ cd mygittutorial.bitbucket.io/To powoduje sklonowanie repozytorium za pomocą polecenia git clone i utworzenie katalogu na podstawie klonu mygittutorial.git.bitbucket.io.
Tworzenie gałęzi i dokonywanie zmian przy użyciu przepływu pracy z gałęziami
W tej gałęzi dodamy cytat na stronę internetową.
1. Utwórz gałąź za pomocą polecenia git branch.
$ git branch test-12. Wyewidencjonuj utworzoną właśnie gałąź za pomocą polecenia git checkout.
$ git checkout test-1 Switched to branch 'test-1'3. Uzyskaj listę lokalnych gałęzi za pomocą polecenia git branch.
$ git branch main * test-14. Zaktualizuj plik editme.html, dodając do niego cytat. Możesz użyć np.:
This is a quote, and I like it.
A quote: The Art of Quoting 5. Dodaj tę zmianę.
git add editme.htmlUwaga: Twoja zmiana nie została zatwierdzona w historii Git — jest w stanie „oczekiwania”. Omawialiśmy tę kwestię w samouczku Zapisywanie zmian.
6. Zatwierdź zmianę za pomocą opisowego komunikatu commita.
git commit editme.html -m'added a new quote' [test-1 063b772] added a new quote 1 file changed, 3 insertions(+), 3 deletions(-)Uwaga: Teraz zmiany stają się częścią historii Git jako pojedynczy „commit”. Omawialiśmy tę kwestię w samouczku Zapisywanie zmian.
7. Wypchnij tę zmianę do Bitbucket za pomocą polecenia git push.
git push fatal: The current branch test-1 has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin test-1Pojawi się błąd, ponieważ przy pierwszym wypchnięciu nowej gałęzi utworzonej lokalnie musisz ją wyznaczyć.
8. Wypchnij gałąź i zmianę za pomocą polecenia git push branch.
$ git push origin test-1 Counting objects: 3, done. Delta compression using up to 8 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 363 bytes | 0 bytes/s, done. Total 3 (delta 2), reused 0 (delta 0) remote: remote: Create pull request for test-1: remote: https://bitbucket.org/dstevenstest/dans.git.bitbucket.org/pull-requests/new?source=test-1&t=1 remote: To https://bitbucket.org/dstevenstest/dans.git.bitbucket.org.git * [new branch] test-1 -> test-1Ten kod informuje system, że repozytorium źródłowe jest miejscem docelowym nowej gałęzi.
9. Otwórz repozytorium samouczka i kliknij Branches (Gałęzie). Powinny być teraz widoczne zarówno gałąź main, jak i test-1. Powinno to wyglądać mniej więcej tak:
Tworzenie, pobieranie i wyewidencjonowywanie zdalnej gałęzi
Jeżeli pracujesz w zespole, z pewnością zdarzy Ci się ściągać lub pobierać gałęzie stworzone przez innych członków zespołu i wypchnięte do Bitbucket. Na podstawie poniższego przykładu zapoznasz się z podstawami tworzenia i pracy z gałęziami tworzonymi przez innych.
1. Przejdź do repozytorium ćwiczeniowego w Bitbucket, a następnie kliknij Branches (Gałęzie). Widok powinien być mniej więcej następujący:
2. Wybierz opcję Create branch (Utwórz gałąź), nadaj gałęzi nazwę test-2, a następnie kliknij Create (Utwórz).
3. Skopiuj polecenie git fetch w oknie dialogowym wyewidencjonowania gałęzi. Będzie to wyglądało mniej więcej następująco:
$ git fetch && git checkout test-2 From https://bitbucket.org/dstevenstest/dans.git.bitbucket.org * [new branch] test-2 -> origin/test-2 Branch test-2 set up to track remote branch test-2 from origin. Switched to a new branch 'test-2'4. Użyj polecenia git branch w terminalu. Powinna się wyświetlić lista gałęzi:
$ git branch main test-1 * test-2Gałąź z gwiazdką * jest gałęzią aktywną. Należy o tym pamiętać podczas korzystania z dowolnego przepływu pracy z gałęziami.
5. Użyj polecenia git status, a wyświetli się mniej więcej następująca treść:
$ git status On branch test-2 Your branch is up-to-date with 'origin/test-2'. nothing to commit, working tree cleanTu widać, w której gałęzi się znajdujesz i czy jest ona obecnie aktualna względem gałęzi zdalnej (origin).
6. Użyj polecenia git checkout, aby przenieść się z powrotem do drugiej gałęzi. Polecenie będzie wyglądać mniej więcej następująco:
$ git checkout test-1 Switched to branch 'test-1' Your branch is ahead of 'origin/test-1' by 3 commits. (use "git push" to publish your local commits)Jedną z kluczowych spraw, o których należy pamiętać podczas pracy w gałęziach, jest upewnienie się, że dokonujemy zmian we właściwej z nich.
Wypchnięcie zmiany i utworzenie pull requestu
Teraz nadszedł czas, aby poddać pierwszą zmianę przeglądowi i scalić gałąź.
1. Kliknij przycisk +> Create a pull request (Utwórz pull request). Teraz widzisz swoją gałąź test-1 jako gałąź źródłową oraz main w gałęzi docelowej.
Ponieważ utworzyliśmy to repozytorium przez podział istniejącego, jako miejsce docelowe ustawiona jest gałąź main repozytorium, które podzieliliśmy.
Aby to poprawić, musisz zmienić gałąź docelową (gałąź, w ramach której chcesz scalić swoje zmiany) z tutorials/tutorials.git.bitbucket.org na swoje repozytorium.
Możesz również dodać recenzentów z Twojego zespołu do pull requestu. Dowiedz się więcej na temat pull requestów
2. Kliknij przycisk Create pull request (Utwórz pull request).
3. Dodaj komentarz do pull requestu, zaznaczając wiersz w wykazie różnic (obszar wyświetlający zmianę dokonaną w pliku editme.html).
4. Kliknij Approve (Zaakceptuj) w lewym górnym rogu strony. Oczywiście w prawdziwym pull requeście mielibyśmy recenzentów zgłaszających uwagi.
5. Kliknij opcję Merge (Scal).
6. (Opcjonalnie) Zaktualizuj komunikat commita (Commit message), podając więcej szczegółów.
7. Wybierz strategię scalania Merge commit (Commit scalenia) spośród dwóch opcji: Dowiedz się więcej na temat tych dwóch typów strategii scalania.
- Merge commit (Commit scalenia) — zachowuje wszystkie commity z gałęzi źródłowej i czyni je częścią gałęzi docelowej. Opcja ta daje ten sam efekt co wpisanie polecenia git merge --no-ff w wierszu poleceń.
- Squash (Squashowanie) — łączy commity podczas scalania gałęzi źródłowej z docelową. Opcja ta daje ten sam efekt co wpisanie polecenia git merge --squash w wierszu poleceń.
8. Kliknij przycisk Commits (Commity), a zobaczysz, jak scalona gałąź wpisuje się w szerszy zakres zmian.
Usuwanie gałęzi i ściąganie zawartości gałęzi main do lokalnej gałęzi roboczej
Udało Ci się przebrnąć przez podstawowy przepływ pracy z gałęziami, a Twoja zmiana znajduje się w gałęzi main. Ostatnią rzeczą, której się nauczymy, będzie usunięcie scalonej właśnie gałęzi, ściągnięcie zaktualizowanej gałęzi main i scalenie zaktualizowanej gałęzi main z gałęzią test-2.
Po co usuwać gałąź?
Pamiętaj, że praca z gałęziami w Git wygląda inaczej niż w SVN i podobnych systemach kontroli wersji, ponieważ gałęzie mogą mieć zarówno charakter długoterminowy, jak np. gałąź główna i programowania, jak i krótkoterminowy — zgodnie z przykładami przedstawionymi w tym samouczku. W związku z tym warto usuwać lokalne gałęzie, aby zapewnić porządek w lokalnym środowisku.
Dlaczego warto ściągnąć gałąź main i scalić ją z gałęzią test-2?
Używamy tego jako przykładu działania w repozytorium, w którym pracuje inny członek zespołu. Dobrze jest od czasu do czasu ściągać zmiany do swojej roboczej gałęzi, aby uniknąć konfliktów scalania w pull requestach.
1. Otwórz terminal i uruchom polecenie git status. Wynik powinien wyglądać mniej więcej następująco:
$ git status On branch test-1 nothing to commit, working tree cleanJak widać, znajdujesz się w gałęzi użytej do wprowadzenia zmian, a nie masz już żadnych zmian. Teraz, zakończywszy zadanie, możemy pozbyć się tej gałęzi.
2. Przełącz się na gałąź main za pomocą polecenia git checkout main. Wynik powinien wyglądać mniej więcej tak:
git checkout main Switched to branch 'main' Your branch is up-to-date with 'origin/main'.Zauważ, że według komunikatu gałąź jest aktualna. To dotyczy tylko Twojej lokalnej gałęzi. Wiemy to, ponieważ właśnie scaliliśmy zmianę w gałęzi main i jeszcze nie ściągnęliśmy tej zmiany ze zdalnego repozytorium do naszego lokalnego systemu. To właśnie zrobimy teraz.
3. Uruchom polecenie git pull. Wynik powinien wyglądać mniej więcej tak:
$ git pull remote: Counting objects: 1, done. remote: Total 1 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (1/1), done. From https://bitbucket.org/dstevenstest/dans.git.bitbucket.org 2d4c0ab..dd424cb main -> origin/main Updating 2d4c0ab..dd424cb Fast-forward editme.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
W momencie ściągania zmian ze zdalnego repozytorium Git wykonuje scalanie z przewijaniem celem zintegrowania wprowadzonych zmian. Wyświetla również liczbę plików i wierszy, które uległy zmianie.
4. Uruchom polecenie git branch -d {nazwa_gałęzi}, aby usunąć gałąź test-1. Wynik powinien wyglądać mniej więcej tak:
$ git branch -d test-1 Deleted branch test-1 (was 063b772)Widać tutaj, że gałąź została usunięta, oraz to, jaki był ostatni hash commitu dla tej gałęzi. Jest to bezpieczny sposób na usuwanie gałęzi, jako że Git nie pozwoli na usunięcie gałęzi z niezatwierdzonymi zmianami. Należy jednak pamiętać, że to nie zapobiegnie usunięciu zmian, które zostały zatwierdzone w historii git, ale nie zostały scalone z inną gałęzią.
5. Przełącz na gałąź test-2 za pomocą polecenia git checkout.
$ git checkout test-2 Switched to branch 'test-2' Your branch is up-to-date with 'origin/test-2'.6. Scal gałąź main z gałęzią roboczą za pomocą polecenia git merge main test-2. Wynik powinien wyglądać mniej więcej tak:
$ git merge main test-2 Updating 2d4c0ab..dd424cb Fast-forward editme.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
Należy koniecznie pamiętać o następujących kwestiach:
- Ma znaczenie, która gałąź jest aktywna. Jeśli chcesz scalić gałąź main z gałęzią test-2, gałąź test-2 musi być wyewidencjonowana (aktywna). To samo dotyczy sytuacji, gdy chcesz scalić gałąź test-2 z gałęzią main — gałąź main musi być wyewidencjonowana.
- Aby zobaczyć, która gałąź jest aktywna w danym momencie, użyj polecenia git branch, a aktywna gałąź zostanie oznaczona gwiazdką, albo użyj polecenia git status, aby się dowiedzieć, na której gałęzi się znajdujesz i czy są w niej oczekujące zmiany lokalne.
Mamy nadzieję, że zdołaliśmy skutecznie przybliżyć zagadnienie pracy z gałęziami i związanych z tym poleceń. Podsumujmy to, co właśnie omówiliśmy:
Przegląd przepływu pracy z gałęziami
Przepływ pracy gałęzi funkcji Git to skuteczny sposób na rozpoczęcie współpracy zespołowej w Bitbucket. W ramach tego przepływu cały rozwój funkcji odbywa się w gałęziach oddzielonych od głównej. Dzięki temu wielu programistów może pracować nad własnymi funkcjami bez dotykania głównego kodu.
Zacznijmy od gałęzi głównej
Ten przepływ pracy umożliwia współpracę nad kodem z co najmniej jedną osobą. Jeśli Twoje repozytoria Bitbucket i lokalne są aktualne, możesz zaczynać.
Tworzenie nowej gałęzi
Użyj oddzielnej gałęzi dla każdej funkcji lub problemu, nad którym pracujesz. Po utworzeniu gałęzi wyewidencjonuj ją lokalnie, aby wszelkie wprowadzone zmiany znajdowały się w tej gałęzi.
Aktualizacja, dodawanie, zatwierdzanie i wypychanie zmian
Pracuj nad funkcją i dokonuj zatwierdzeń tak, jak zazwyczaj, gdy używasz Git. Gdy nadejdzie właściwy moment, wypchnij commity, aktualizując gałąź funkcji w Bitbucket.
Przegląd kodu
Aby uzyskać opinię na temat kodu, utwórz pull request w Bitbucket. Za jego pośrednictwem możesz dodawać recenzentów i upewnić się, że wszystko jest w porządku przed scaleniem.
Zastosowanie uwag zwrotnych
Teraz współpracownicy komentują i aprobują stan kodu. Wprowadź sugerowane w komentarzach zmiany lokalnie, zatwierdź i wypchnij je do Bitbucket. Twoje aktualizacje pojawią się w pull requeście.
Scalenie gałęzi
Przed scaleniem może być konieczne rozwiązanie konfliktów scalania w wypadku, gdyby inne osoby wprowadziły zmiany w repozytorium. Gdy pull request zostanie zatwierdzony i będzie wolny od konfliktów, możesz dodać swój kod do gałęzi main. Wykonaj scalenie na podstawie pull requestu w Bitbucket.
W tym samouczku brak miejsca na pełne przedstawienie, w jaki sposób tworzenie gałęzi zwiększa efektywność zespołów. Istnieje kilka podejść do pracy z gałęziami i niektóre z nich omawiamy w sekcji Porównanie przepływów pracy.
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
