Git branch | git branch create, rename, delete, checkout, merge

Git jako najpopularniejszy rozproszony system kontroli wersji – może się pochwalić rozbudowanym zbiorem funkcjonalności oraz różnego rodzaju integracji – co pozwala wykorzystać go swobodnie w wielu codziennych zadaniach.
W ramach tego materiału dowiesz się jak tworzyć gałęzie (ang. git branches) i jak z nimi pracować.

Git branch – wprowadzenie

Z tego materiału dowiesz się:

• Czym jest git branch?
• Jak tworzyć nowe gałęzie w git?
• Jak zmienić nazwę branch'a?
• Jak przełączać się między branch'ami?
• Jak sprawdzić listę dostępnych branch'y?
• Jak wypchnąć lokalne zmiany na zdalnego branch'a?

Git install – Instalacja Git

Jeżeli nie masz jeszcze Gita zainstalowanego lokalnie – szybko możesz to nadrobić.
W poniższym materiale znajdziesz instrukcję, jak można to zrobić.

→ ZOBACZ 👉: Install Git – Instalacja Git, Windows, Ubuntu – Bash, GUI

Git

W ramach tego materiału zajmiemy się przede wszystkim pracą z gałęziami (git branch) – natomiast kompletny tutorial Git znajdziesz poniżej.

→ ZOBACZ 👉: Git tutorial | stash, rebase, commit, merge, checkout, push i clone

Git branch, branching, branches

Git branch jest jedną z kluczowych funkcjonalności Gita, dzięki której stał się on tak popularny.
Większość systemów kontroli wersji ma możliwość rozgałęziania kodu – ale to właśnie w Gicie ten mechanizm jest zrobiony wyjątkowo dobrze i przejrzyście oraz „lekko”.
W praktyce oznacza to, że Git pozwala robić rozgałęzienia lokalnie bez konieczności ręcznego kopiowania kodu. W starszych systemach często trzeba było mieć dostęp do internetu lub skopiować całe repozytorium, by osiągnąć podobny efekt. Co nie brzmi już tak zachęcająco.

Co równie ważne, praca z gałęziami jest bardzo szybka, w odróżnieniu od innych podobnych rozwiązań. Gałąź w Gicie została zaimplementowana jako lekki, przesuwalny wskaźnik na konkretne miejsce w historii.

Git branch

Gałąź (ang. Git branch) w Git jest podobna do gałęzi drzewa. Analogicznie z centralnej części drzewa, zwanej pniem, wyrastają gałęzie. Podczas gdy gałęzie mogą się tworzyć i odpadać – pień pozostaje zwarty i jest jedyną częścią, dzięki której można powiedzieć, że drzewo jest żywe.
Podobnie gałąź w Git (ang. Git branch) to sposób na ciągłe rozwijanie nowej funkcjonalności lub modyfikacji już istniejącego oprogramowania – jednocześnie nie wpływając na główną część projektu. Można też powiedzieć, że gałęzie (ang. Git branches) wyznaczają kolejną linię rozwoju w projekcie.

Główną lub domyślną gałęzią w Git jest gałąź master – odnosząc się do drzewa, jest jego centralną częścią.
W chwili stworzenia repozytorium powstaje główna gałąź (ang. master). Repozytorium może mieć tylko jedną gałąź główną (zazwyczaj master lub main).

Kiedy zaczynasz dokonywać zmian (i commitujesz je do głównej gałęzi), wskaźnik gałęzi głównej automatycznie przesuwa się do przodu – i przez to wskazuje na najnowsze zmiany.

Git clone branch – klonowanie istniejącego repozytorium

Dołączasz do projektu, który jest już tworzony od wielu lat. Oprócz przygotowanego lokalnie środowiska nie posiadasz jeszcze nic na swoim komputerze. Cały projekt znajduję się na zdalnym repozytorium. Wyobraź sobie, że projekt ten ma tysiące klas i plików. Kopiowanie ręczne to byłby dosłownie koszmar, który trwałby bez końca. Git przygotował dla nas gotowe i szybkie rozwiązanie w postaci sklonowania istniejącego już repozytorium za pomocą git clone.

W tym celu musisz wywołać poniższą komendę, gdzie url możesz podmienić na dowolne inne repozytorium.

 
Git clone https://github.com/dagmararaczak/stormItBlog.git

Podczas klonowania, Git pobiera wszystkie pliki przechowywane w repozytorium oraz całą ich historię. Od tego momentu na lokalnym komputerze przechowujemy prawie idealny backup zdalnego repozytorium. W przypadku jego awarii wystarczy odtworzyć repozytorium z lokalnej wersji. Utracone zostaną tylko specyficzne konfiguracje przechowywane na serwerze.

Na poniższym przykładzie widać, że operacja git clone utworzyła nowy katalog o nazwie repozytorium, w tym wypadku jest to stormItBlog. Wygenerowany został również podkatalog .git z metadanymi repozytorium, a kopia robocza została ustawiona na najbardziej aktualną wersję.

Git clone branch – klonowanie pojedynczej gałęzi

Nie zawsze potrzebujemy całego repozytorium. W przypadku kiedy chcesz sklonować pojedynczy branch, jedyne co musisz zrobić to zastosować komendę git clone –single-branch –branch

 
Git clone --single-branch --branch hotFix https://github.com/dagmararaczak/stormItBlog.git 

Na poniższym przykładzie widać, że operacja git clone ponownie utworzyła nowy katalog o nazwie repozytorium, w tym wypadku jest to stormItBlog.

Kiedy jednak użyjesz git status zobaczysz, że znajdujesz się na sklonowanym branch'u hotFix.

Git create branch – git new branch

Git sprawia, że tworzenie branch'y jest bardzo proste.

Istnieje kilka różnych sposobów tworzenia branch'a w Gicie. Przyjrzyjmy się kolejno każdemu z nich.

Git branch | git create branch

Nowy branch z aktualnej gałęzi

Aby utworzyć nową gałąź, która jest oparta na aktualnym HEAD'zie gałęzi, po prostu użyj:

git branch .

Git branch testowy-branch 
Git checkout testowy-branch 

Na powyższym przykładzie komenda git branch nowy-branch – utworzyła nową gałąź na podstawie tej, na której się obecnie znajduję. W tym przypadku jest to master – oczywiście może to być dowolna gałąź, w zależności od Twoich potrzeb.

Utworzony nowy-branch jest dokładną kopią obecnego stanu mastera. Aby zacząć pracę na nim wystarczy się przełączyć stosując git checkout nowy-branch. Od tego momentu wszystko, co tak naprawdę stworzymy na tym branch'u nie ma wpływu na inne branch'e – tak długo, jak sami nie zdecydujemy, że chcemy go połączyć z inną gałęzią.

Nowy branch z wybranej (innej niż aktualna) gałęzi

Niekoniecznie zawsze musisz chcieć odbić się z aktualnego branch'a, na którym się znajdujesz. Przełączanie się na konkretnego branch'a tylko w celu stworzenia nowego, wydaje się dosyć męczące, obarczone dodatkowym czasem. A tak samo, jak mój domyślam się, że i Twój czas jest na wagę złota. Dlatego i tutaj git wychodzi z gotową propozycją stworzenia nowego branch'a z innego bez konieczności przełączania się na niego:

git branch .

 
Git branch testowy-branch glowny-branch

Git checkout testowy-branch 

Znajdując się na branch'u nowy-branch udało mi się w szybki sposób stworzyć nowy branch bazujący na masterze.

Nowy branch z hash'a commit'a

Pracując nad swoim kodem, może zdarzyć się sytuacja, że commit'ując kolejną zmianę, kod, który stworzyłeś wcześniej działa nie do końca tak, jakbyśmy tego chcieli i ciekawi Cię czy to ostatnie zapisane zmiany na to wpłynęły, czy może już wcześniej kod tak działał, a Ty tego nie zauważyłeś. Oczywiście jest to tylko przykład i powodów, dla których chciałbyś wrócić do konkretnego commit'a może być wiele. Nie ma sensu jednak cofać zmian, jeżeli nie wiesz gdzie leży przyczyna twoich wątpliwości. Możesz jednak stworzyć nowego branch'a z konkretnego commita, który będzie stanowił punkt początkowy dla nowej gałęzi:

git branch .

 
Git branch testowy-branch ed0b538de12
Git checkout testowy-branch 

Spójrzmy na przykład. Mamy klasę TestClass na branch'u master. Zmiany te zostały zapisane za pomocą kilku commit'ów na lokalnym repozytorium.

Teraz możemy wybrać konkretny commit, z którego stworzymy nowego branch'a.

W tym przypadku jest to commit o hash'u 782a4f26f996090b5b991c70680de3d5030276fa, który zapisywał w lokalnym repozytorium zmianę, jaką było stworzenie metody getName().

Nowy branch z-commita posiada wszystkie zmiany z bazowego commit'a 782a4f26f996090b5b991c70680de3d5030276fa.

Nowy branch z tagu

Jedną z ciekawych możliwości, jakie oferuje nam git, jest możliwość tworzenia nowej gałęzi na konkretnym tagu, który posiadasz już w swoim repozytorium za pomocą polecenia:

git branch .

 
Git branch testowy-branch v2.3
Git checkout testowy-branch 

Tworzenie branch'a z gałęzi ze zdalnego repozytorium

Oczywiście często zdarzy się sytuacja, że zaistnieje potrzeba stworzenia branch'a na lokalnym repozytorium, z już istniejącego na zdalnym repozytorium, wykorzystaj wtedy polecenie:

git branch origin/.

Przykładem tego może być np. praca nad feature'm. W momencie, kiedy nad jednym feature'm pracuje więcej niż jedna osoba, ktoś tworzy zdalnego branch'a, a reszta na podstawie tej konkretnej gałęzi tworzy swojego lokalnego branch'a.

 
Git branch testowy-branch origin/testowy-branch
Git checkout testowy-branch 

Tworzenie branch'a na zdalnym repozytorium

Stworzyłeś lokalnie nowego branch'a, ale Twoje zdalne repozytorium nie wie jeszcze o jego istnieniu.
Czas je o nim poinformować 🙂

Użyj komendy:

git push -u origin .

Teraz możesz już na swoim zdalnym repozytorium zobaczyć Twojego branch'a i podzielić się efektami swojej pracy z innymi.

Git checkout -b – git create branch

Chcąc przełączyć się z jednego na drugiego branch'a możesz użyć komendy git checkout.
Komenda może przyjąć też parametr -b, który jest dosyć wygodny, ponieważ sprawia, że:
git checkout -b  od razu tworzy i przełącza się na nowo utworzonego branch'a.

git branch + git checkout
== git checkout -b

 
Git checkout -b testowy-branch

Git checkout -b tak samo, jak git branch możesz użyć również do stworzenia nowej gałęzi:

• Na innej istniejącej gałęzi za pomocą git checkout .
• W oparciu o konkretnego commit'a (nie gałąź), możesz podać hash commit'a jako punkt początkowy –
  git checkout -b  .
• Na konkretnym tagu, który posiadasz już w swoim repozytorium – git checkout -b .
• Z gałęzi ze zdalnego repozytorium – git checkout -b origin/.

Git checkout – przełączanie się między branch'ami

Pracując często na kilku branch'ach, zdecydowanie przydaje się polecenie git checkout.
We wcześniejszym akapicie pokazałam Ci, jak szybko dzięki git checkout -b  możesz jednocześnie utworzyć gałąź i przełączyć się nią. Przyjrzyjmy się bliżej temu, co git checkout nam jeszcze umożliwia.

Git checkout pozwala nam:

• Przełączać aktualnie aktywną gałąź.
• Tworzyć nowego branch'a.
• Przywracać pliki.

Najczęstszym przypadkiem użycia git checkout jest przełączenie się na inną gałąź, co czyni ją nową gałęzią HEAD. Przeskakiwanie między gałęziami jest częstą praktyką w codziennym życiu programisty, dlatego polecenie git checkout  należy dobrze znać.

 
Git checkout inny branch

Git checkout | Git switch

W ramach tego materiału zajmujemy się przede wszystkim gałęziami i poznajemy ich możliwości. Jeżeli chcesz bliżej zapoznać się z tematem git checkout oraz poznać alternatywę dla tego polecenia (git switch) – to zapraszam do dodatkowych materiałów:

→ ZOBACZ 👉: Git checkout | Git switch

Git rename branch – zmiana nazwy branch'a

Ile razy zdarzy Ci się coś pisać i popełnić błąd? Mogła się wkraść literówka albo po prostu po chwili stwierdzasz, że to nie tak ma być napisane. Nie będę ukrywać – mi zdarza się to regularnie. Tworząc branch'e i tutaj nie trudno o pomyłkę albo zmianę zdania jak dany branch ma się nazywać. Usuwanie branch'a i tworzenie nowego tylko przez literówkę wydaję się dosyć absurdalnym pomysłem. Całe szczęście, że i w tym przypadku mamy szybkie rozwiązanie, jakim jest polecenie:
git branch -m .

Efektem będzie zmiana nazwy gałęzi, którą wskazano w poleceniu.

Spójrzmy na to, co wydarzyło się na powyższym przykładzie.

• Na początku sprawdziłam jakie gałęzie są dostępne w moim repozytorium (git branch -a). Gwiazda przy gałęzi wskazuję na gałąź, na której się obecnie znajdujemy. W tym przypadku jest to moj-branch.
• Następnie zmieniłam nazwę gałęzi nowy-branch na kopia-master i ponownie sprawdziłam listę branchy dostępnych w repozytorium. Jak widzisz nazwa nowy-brach została zastąpiona na kopia-master.

Warto też wiedzieć, że nie musisz określać starej nazwy branch'a, jeśli chcesz zmienić nazwę gałęzi, na której się aktualnie znajdujesz git branch -m .

Na powyższym przykładzie chciałam zmienić nazwę branch'a, na którym się znajdowałam kopia-master.
W tej sytuacji podczas zmieniania nazwy nie ma potrzeby podawania gałęzi, której nazwę zmieniamy, dlatego podałam tylko nową nazwę moj-branch.

Git rename remote branch – zmiana nazwy zdalnego branch'a

Istnieją sytuację, kiedy zdarza się potrzeba zmiany nazwy lokalnego branch'a. A co w przypadku, gdy niechciana nazwa już znajduję się na zdalnym repozytorium? Git jest przygotowany również na taką okoliczność – pozwala nam „skorygować nazwę” branch'a również na zdalnym repozytorium. Chociaż jest to trochę bardziej złożony proces niż w przypadku zmiany nazwy lokalnie. Złożoność wynika z faktu, że tak naprawdę nie zmieniamy nazwy istniejącego zdalnego branch'a a usuwamy gałąź ze starą nazwą i tworzymy nową ze skorygowaną nazwą. Aby zmienić nazwę zdalnego branch'a musisz wykonać kilka kroków:

1. Zmień nazwę branch'a lokalnie → git branch -m .
2. Usuń zdalną gałąź, której nazwa została poprawiona → git push origin ––delete .
3. Stwórz zdalną gałąź z nową nazwą → git push -u origin .

 
git branch -m zielony-branch czerwony-branch
git push --delete zielony-branch
git push -u czerwony-branch

Git list branches – sprawdzenie listy lokalnych branch'y

Często, kiedy opowiadam o branch'ach, mówię o nich w liczbie mnogiej. Jest tak dlatego, że niejednokrotnie potrzebujemy więcej niż jednego branch'a do pracy nad kodem. W codziennej pracy programisty praca na różnych branch'ach to chleb powszedni. Wyobraź sobie sytuację gdzie masz przełączyć się na jakiegoś branch'a, ale nie pamiętasz całej nazwy. W takiej chwili warto sprawdzić listę dostępnych lokalnych branch'y używając git branch.

Poniżej możesz zobaczyć, że w obecnej chwili na lokalnym repozytorium znajdują się 3 gałęzie:

• kopia-master,
• master (gwiazdka wskazuję na to, że obecnie znajdujemy się na danym branch'u),
• moj-branch.

Dostępne jest także inne polecenie: git branch -a. Komenda ta wyświetli zarówno listę lokalnych, jak i zdalnych branchy (oznaczenie remotes).

Powyżej widać 3 lokalne branch'e:

• kopia-master,
• master (gwiazdka wskazuję na to, że obecnie znajdujemy się na danym branch'u),
• moj-branch.

Oraz jeden zdalny (remotes):

• origin/master

Kolory i oznaczenia takie jak remotes lub gwiazdka, w przejrzysty sposób pozwalają nam czytać listę dostępnych gałęzi.

Git branch list | Git list remote branches – sprawdzenie listy zdalnych branch'y

Git udostępnia nam dwie opcję na sprawdzenie listy zdalnych branchy:

• Jedną z nich jest opcja opisana we wcześniejszym akapicie, która pokazuje zarówno lokalne, jak i zdalne gałęzie:
  git branch -a,
• Druga komenda sprawdza tylko zdalne branch'e: git branch -r.

Powyżej widać, że na zdalnym repozytorium znajduje się tylko jeden branch: origin/master.
W przypadku zastosowania polecenia git branch -r nie pokazują nam się dostępne lokalne gałęzie.

Git push branch | git push to remote branch – wypychanie branch'a na zdalne repozytorium

Opowiadam Ci o różnych opcjach powiązanych z git branch, a jest ich naprawdę dużo. Jedną z nich – naprawdę istotną jest git push. Pracując w projekcie, nie wyobrażam sobie pracy bez zdalnego repozytorium. Czy potrafisz sobie to wyobrazić, że wszystkie zmiany, które wprowadzasz do siebie lokalnie, trzeba byłoby ręcznie łączyć w jednym miejscu? Te błędy i niekończące się konflikty. Jednym słowem rozegrałby się chaos 😱 Całe szczęście, że nie musimy się o to martwić, bo Git nas od tego chroni. Możemy pracować sobie nad swoimi zmianami i kiedy są gotowe wypychać je do zdalnego repozytorium, tak aby inni też mogli te zmiany zobaczyć i np. dalej z nimi pracować. To wszystko jest możliwe dzięki poleceniu git push.

Istnieje kilka różnych sytuacji, w których używamy tej komendy w trochę inny sposób.

1. Git push new branch – wypychanie nowej gałęzi

Pierwszą z nich jest wypychanie nowego lokalnego branch'a, który jeszcze nie występuje na zdalnym repozytorium.

Spójrzmy na taką sytuację:
Naprawiasz bug'a i w tym celu tworzysz lokalnie nowego branch'a na bugFix'a. Na zdalnym repozytorium jeszcze nie ma takiej gałęzi.
Poprawki zostały wprowadzone – bug już nie występuje.
Tak, ale na tę chwilę nie występuje on tylko u Ciebie, bo zdalne repozytorium nic jeszcze nie wie o zmianach w kodzie na Twoim nowym branch'u.

Czas wypchnąć je ku światu.
Aby to zrobić, musisz zastosować polecenie:

git push -u origin .

Teraz Twój branch, znajduję się na zdalnym repozytorium i ktoś inny z teamu może np. zrobić review Twoich zmian w kodzie.

Na powyższym przykładzie widać utworzenie nowego branch'a bugFix. Branch ten jest dostępny na lokalnym repozytorium. Nie występuje on jednak jeszcze na zdalnym. Po zastosowaniu git push -u origin bugFix, widać, że gałąź ta pojawiła się również na zdalnym repozytorium.

Innym rozwiązaniem na wypchnięcie nowego branch'a jest zastosowanie git push -u origin HEAD.

HEAD to odniesienie do początku bieżącej gałęzi, więc jest to łatwy sposób na przeniesienie lokalnej gałęzi o tej samej nazwie na zdalne repozytorium. Dzięki temu nie musisz wpisywać dokładnej nazwy gałęzi.

2. Git push branch – wypychanie zmian na istniejącą na zdalnym repozytorium gałąź

A co w przypadku gdy istnieje już gałąź na zdalnym repozytorium i chcemy dodać do niej kolejne zmiany?

Załóżmy, że wypchnięta wcześniej gałąź bugFix już jest na zdalnym repo. Reviewer dopatrzył się kilku błędów, które musisz poprawić. Nie tworzysz nowej gałęzi, tylko chcesz nanieść poprawki na branch'a bugFix. Jedyne co musisz zrobić to lokalnie nanieść wszystkie poprawki, a następnie wypchnąć je stosując git push.

W tym przypadku nie trzeba już dodawać nazwy branch'a ani żadnych dodatkowych informacji – Git już wie, że na zdalnym repozytorium istnieje gałąź o takiej samej nazwie.

Warto też przyjrzeć się niektórym dostępnym flagom (opcjom), które oferuje nam git push:

• ––delete – git push możesz nie tylko używać do wypychania nowych utworzonych zmian. Może Ci on posłużyć również do usuwania zdalnego branch'a. Git push origin ––delete bugFix usunie zdalnie branch'a bugFix.

Przeanalizujmy razem powyższy przykład. Co zadziało się krok po koku:

1. Sprawdziłam listę dostępnych zdalnych branch'y (git branch -r). Wśród nich znalazł się branch bugFix.
2. Usunęłam zdalnego branch'a bugFix (git push origin ––delete bugFix)
3. Sprawdziłam ponownie listę dostępnych zdalnych branch'y (git branch -r). Nie występuje już wśród nich branch bugFix.
4. Sprawdziłam listę dostępnych lokalnych branch'y (git branch). Zrobiłam to, bo warto zauważyć, że git push origin ––delete bugFix usunął tylko zdalnego branch'a. Lokalny branch bugFix pozostał bez zmian na lokalnym repo.

• ––all – może zdarzyć się taka sytuacja, w której zajdzie potrzeba wypchnięcia wszystkich dostępnych lokalnych branch'y na zdalne repozytorium. Żeby nie pushować każdego branch'a osobno możesz po prostu użyć opcji ––all i wszystkie lokalne branch'e znajdą się na zdalnym repo. Aby wszystkie lokalne gałęzie znalazły się na zdalnym repozytorium, zastosuj: git push ––all.

Na przykładzie widać, że na początku na zdalnym repozytorium dostępna była gałąź master.
Po wykonaniu git push ––all wszystkie lokalne gałęzie pojawiły się na zdalnym repo.

• -u – flaga ta tworzy upstream (śledzącą) referencję i jest szczególnie przydatne podczas pushowania lokalnego branch'a na zdalne repozytorium po raz pierwszy.

Git push

W ramach tego materiału zajmiemy się przede wszystkim poleceniem git push z punktu widzenia branch'a. Jeżeli chcesz bliżej zapoznać się z tematem git push (wypychaniem zmian) – to zapraszam do dodatkowych materiałów:

→ ZOBACZ 👉: Git tutorial | stash, rebase, commit, merge, checkout, push i clone

→ ZOBACZ 👉: Git push – git integracja ze zdalnym repozytorium, git push, ssh, remote

Git delete branch | remove branch git – usuwanie branch'a

W projektach tworzymy dużo, różnych branch'y. Część z nich istnieje bardzo długo, ale inne są nam potrzebne tylko na tzw. przysłowiową chwilę.

Wyobraź sobie 10-letni projekt, w którym każda osoba zostawia utworzony branch zarówno na lokalnym i zdalnym repozytorium. Myślę, że można by było przewijać u niektórych listę gałęzi przez wiele minut.

Dla utrzymania ogólnego porządku i niezaśmiecania pamięci branch'ami, do których już nigdy nie powrócimy, powinno się je regularnie usuwać. To trochę jak w codziennym życiu – sprzątamy i pozbywamy się niepotrzebnych rzeczy, aby dać miejsce nowym i aby była przestrzeń w domu. Nie chcemy przecież dojść do momentu, kiedy nie bylibyśmy w stanie wejść do domu, bo byłoby w nim tyle rzeczy. Tak samo jest w przypadku repozytoriów i gałęzi.

Wyobraź sobie, że pracujesz na osobnych branch'u nad hotfixem. Dochodzisz do momentu, kiedy zmiany już są na zdalnym repozytorium i połączone z główną gałęzią. Nadchodzi ten moment, aby pożegnać się z tą gałęzią i ją usunąć. Aby to zrobić, musisz wykonać dwa kroki:

1. Przełączenie się na innego branch'a (git checkout)

Pierwszą ważną rzeczą, którą musisz wiedzieć i o której musisz pamiętać, to to, że Git nie pozwoli Ci usunąć gałęzi, na której się znajdujesz. Trochę jakby siedziało się na prawdziwej gałęzi na drzewie. Zdecydowanie średnim pomysłem byłoby piłowanie gałęzi na, której się znajdujemy. Dlatego w pierwszej kolejności przełączamy się na gałąź (git checkout) inną niż tę, którą chcemy usunąć.

Powyższy przykład pokazuje, że git nawet nie pozwoli nam usunąć gałęzi na, której się obecnie znajdujemy.

2. Usunięcie branch'a – remove branch git

Git sprawia, że zarządzanie branch'ami jest naprawdę łatwe – a usuwanie lokalnych gałęzi nie jest wyjątkiem. Wystarczy, że zastosujesz polecenie: git branch -d . Ważne, aby przed usunięciem zastanowić się, czy w na pewno w 100% nie potrzebujemy danej gałęzi. Ponieważ nie chcielibyśmy usunąć czegoś, co będzie nam jeszcze potrzebne.

 git branch -d bugFix

Opcjonalnie możesz również wykonać dłuższą wersję powyższej komendy git branch ––delete w celu usunięcia lokalnego branch'a.

Powyżej widać następujące kroki, które wykonałam:

• Sprawdzenie listy dostępnych lokalnie branch'y (git branch). Gwiazdka przy branch'u hotFix oznacza, że to na nim się w danym momencie znajdowałam.
• Usunęłam branch bugFix za pomocą git branch -d bugFIx.
• Ponownie przejrzałam listę dostępnych lokalnie branch'y (git branch), aby upewnić się, że gałąź bugFix została usunięta.

W niektórych przypadkach Git może odmówić usunięcia Twojej lokalnej gałęzi – na przykład, gdy zawiera ona commit'y, które nie zostały scalone z żadnymi innymi lokalnymi gałęziami lub przekazane do zdalnego repozytorium.
Jest to bardzo rozsądna zasada, która chroni przed nieumyślną utratą danych.

Jeśli mimo wszystko chcesz usunąć taką gałąź (np. dlatego, że zaprogramowałeś się w ślepym zaułku i stworzyłeś commit'y, których nie warto trzymać), możesz to zrobić z flagą "-D".

Na powyższym przykładzie widać, że znajdując się na branch'u hotFix próbuje usunąć branch bugFix. Na gałęzi bugFix znajdują się zmiany zapisane na lokalnym repozytorium, które nie zostały zmergowane z inną lokalną lub też zdalną gałęzią. Git nie pozwala mi wykonać tej czynności, informując mnie o tym. Warto zauważyć, że Git to narzędzie, które w dosyć dobry sposób informuje i nakierowuję na konkretne działania. Powyższa próba usunięcia branch'a bugFix jest na to świetnym przykładem.

Git nie zostawia nas tylko z informacją: Nie możesz usunąć, ale pokazuje jakie polecenie powinno się wykonać, jeżeli faktycznie chcemy usunąć branch'a z niezmergowanymi zmianami.

Git delete remote branch | remove branch git – usuwanie zdalnego branch'a

Nie chcemy zaśmiecać swojego lokalnego repozytorium i to samo powinno się tyczyć zdalnego repozytorium.
Dobrą praktyką jest, aby gałęzie nieużywane i niepotrzebne były usuwane. Aby usunąć zdalnego branch'a należy użyć polecenia:

git push ––delete origin .

Na poniższym przykładzie widać dostępny na zdalnym repozytorium (git branch -r) branch bugFix, który jest następnie usuwany (git push ––delete origin bugFix).

W efekcie nie można już znaleźć gałęzi bugFix na liście dostępnych zdalnych branch'y.

Git merge | git merge branch – scalanie gałęzi

Pracując na osobnych branch'ach dochodzimy do punktu, w którym chcemy złączyć nasze zmiany z resztą projektu. Wyobraź sobie pracę nad nową funkcjonalnością aplikacji. Cały kod tworzysz na specjalnie dedykowanej temu gałęzi. Jednak nie chcesz, aby twoja praca była już na zawsze wolnym elektronem. Zgadza się? 🙂 Dlatego przychodzi ten ważny moment połączenia go z innym wiodącym branch'em (git merge). Nie zawsze musi być to od razu master. W zależności od potrzeb i specyfikacji projektu może to być branch o innej nazwie.

Git merge

W ramach tego materiału zajmujemy się przede wszystkim gałęziami i poznajemy ich możliwości. Jeżeli chcesz bliżej zapoznać się z tematem git merge (scalanie gałęzi) – to zapraszam do dodatkowych materiałów:

→ ZOBACZ 👉: Git merge | git merge conflicts

Git fetch remote branch – pobieranie danych ze zdalnego repozytorium

Git fetch jest to narzędzie pobierające zmiany ze zdalnego repozytorium, wszystkie nowe dane z commitów, które zostały wykonane od czasu ostatniej synchronizacji ze zdalnym repozytorium, są pobierane do kopii lokalnej. Nowo pobrane dane nie są integrowane z plikami lokalnymi, a zmiany nie są mergowane z naszym kodem.

Git pull remote branch – pobieranie i integrowanie zmian

Git pull służy do pobierania (git fetch) i integrowania (git merge) zdalnych zmian.

Domyślne git pull używa git merge, istnieje jednak możliwość skonfigurowania go tak, aby używał git rebase. Jeżeli odczujesz potrzebę, aby zrobić taką podmiankę, użyj flagi ––rebase.

Git fetch | Git pull | Git fetch vs. pull

W ramach tego materiału zajmujemy się przede wszystkim gałęziami i poznajemy ich możliwości. Jeżeli chcesz bliżej zapoznać się z tematem git fetch oraz git pull – to zapraszam do dodatkowych materiałów:

→ ZOBACZ 👉: Git fetch | Git pull

Git branch – praca z gałęziami – git merge, checkout, push, clone – podsumowanie

W ramach tego materiału przećwiczyliśmy pracę z branch'ami. Zapoznaliśmy się z wieloma niezwykle przydatnymi opcjami – m.in. dowiedzieliśmy się jak tworzyć, usuwać, łączyć, odświeżać oraz klonować gałęzie.

Jeżeli chcesz kontynuować swoją przygodę z gitem – to zapraszam do dodatkowych materiałów:

→ ZOBACZ 👉: Git tutorial | stash, rebase, commit, merge, checkout, push i clone