Git(hub) – tagi i bugi

Ostatnio powiązaliśmy nasz „projekt” z GitHubem a dzisiaj rozwiniemy tą „przyjaźń” o tagi (wersjonowanie projektu) i rozwiązywanie problemów/bugów (czy też próśb o nowe funkcjonalności).

 

Tworzenie tagów

Tagi służą do oznaczania (etykietowania) ważnych commitów w repozytorium. Np. możemy utworzyć tag „beta” jeśli nasz projekt wszedł w fazę bety (beta testów) a kiedy projekt będzie „stabilny” i chcemy to zakomunikować tworzymy np. tag „1.0”. Korzystając z tagów możemy potem w łatwy sposób pobrać konkretną wersję projektu. zacznijmy od początku.

Nasz „ambitny” projekt jest gotowy do wydania i chcemy go oznaczyć jako wersję „1.0”. W takiej sytuacji wystarczy użyć polecenia

Zostanie utworzona tzw. etykieta lekka która nie zawiera żadnych dodatkowych informacji. Natomiast jeśli chcemy aby nasza etykieta miała np. opis i informacje o autorze etykiety i dacie jej utworzenia musimy użyć

 

Utwórzmy sobie zatem taką etykietę opisową

Teraz wpisując

otrzymamy listę wszystkich tagów (u nas tylko jeden tag)

Możemy wyświetlić szczegóły danej etykiety wpisując

Otrzymamy informacje o utworzonym tagu oraz o ostatnim commicie.

 

Tagowanie „historii”

Oczywiście jeśli jakiś czas pracowaliście nad projektem i nie macie etykiet a chcielibyście utworzyć kilka dla wcześniejszych commitów to nic nie stoi na przeszkodzie. Zacznijmy może od wyświetlenia listy naszych commitów

Użycie „–pretty=oneline” pozwoli pominąć wszystkie informacje poza sumą kontrolną (którą potrzebujemy) i opisem commita.

Załóżmy, że chcemy otagować „Pierwszy commit” tagiem „beta”. Wystarczy dodać do polecenia, które tworzy tag sumę kontrolą (lub jej część) tego commita (w przykładzie użyjemy tylko części sumy kontrolnej):

 

Wypychanie tagów

Aby wypchnąć tag (przesłać) do naszego GitHuba możemy użyć polecenia

gdzie „origin” to skrót do naszego repozytorium a „beta” to nazwa tagu, który chcemy wypchnąć.

Możemy wysłać od razu wszystkie tagi jednym poleceniem i tak też zrobimy:

 

Jeśli wejdziecie sobie teraz do waszego repozytorium na GitHubie to zobaczycie, że dodały się dwie „wersje” projektu

Po wejściu zakładkę mamy podgląd

  1. Nazwa tagu
  2. Po rozwinięciu pokaże nam się 3.
  3. Opis tagu
  4. Część sumy kontrolnej z commita, którego dotyczy tag
  5. Możliwość bezpośredniego pobrania plików z tego tagu

 

Bugi

Co w sytuacji jeśli ktoś nam zgłosi za pomocą GitHuba jakiś błąd? Oczywiście powinniśmy to naprawić 🙂

Zacznijmy od utworzenia nowego „problemu”.

  1. Przechodzimy do zakładki „Issues” (w tym wpisie zajmiemy się tylko bugami pomimo, że w tej zakładce można tworzyć wiele różnych „zagadnień”)
  2. Klikamy na „New Issue”

 

Otworzy nam się formularz, który musimy uzupełnić.

  1. Wpisujemy tytuł (tak wiem ale przypuśćmy, że to jest naprawdę poważny bug 😉 )
  2. A tutaj szczegółowy opis problemu
  3. Z prawej strony mamy możliwość przypisania kilku rzeczy ale my skupimy się tylko na „labels” (4) – więcej o tym może w przyszłych wpisac
  4. Labels (etykiety) pozwalają określić jakiego „typu” jest zagadnienie (aby łatwo oddzielić bugi od np. zwykłych zapytać czy próśb o nowe funkcje)
  5. Klikamy na zębatkę aby otworzyć listę etykiet i wybieramy „Bug”
  6. Zapisujemy

Zostaniemy przekierowani na stronę z utworzonym zagadnieniem (tutaj bugiem) gdzie „najważniejszą” informacją jest numer zagadnienia, który znajduje się za nazwą tematu (tutaj „#1”)

Do tego zagadnienia jeszcze wrócimy a dzisiaj skupimy się tylko na rozwiązaniu problemu.

 

Naprawa bugów

Zaczniemy od utworzenia nowej gałęzi „issue_1”:

 

Edytujemy plik „plik.txt” do takiej postaci:

 

Jako, że „problem” rozwiązany to commitujemy naszą zmianę

Dlaczego taki opis? Otóż GitHub wyłapuje commity, które mają w opisie słowa “Fixes”, “Fixed”, “Fix”, “Closes”, “Closed”, lub “Close” i automatycznie oznacza zagadnienia o podanym numerze jako wykonane/naprawione.

Teraz wystarczy wrócić na „mastera”

 

Następnie zmergować (scalić) zmiany

 

Dobrze byłoby też oznaczyć tą wersję tagiem

Jako, że nie jest to nowa „pełna” wersja „tylko” poprawka użyliśmy oznaczenia „1.1” zamiast „2.0”.

 

Teraz wystarczy wypchnąć zmiany z „mastera”

oraz nasz nowy tag

 

I na koniec usuwamy niepotrzebną już gałąź

 

Wchodzą teraz do tematu z naszym bugiem widać zmiany

  1. Mamy informację, że zagadnienie zostało zamknięte
  2. Klikając w linki możemy przejść do poglądu zmian jakie zostały wprowadzone

 

I gotowe. Od teraz możecie łatwo wersjonować swój projekt i „zarządzać” bugami 🙂 Jeśli chcecie podejrzeć repozytorium na którym pokazywałem przykłady to można zerknąć tutaj

Na dzisiaj to koniec ale jeśli macie jakieś pytania czy chcecie abym napisał o czymś konkretnie to piszcie w komentarzach.


Post 5 z 5 z serii Git