Git, Bitbucket. Narzędzia i środowiska programistyczne. Laboratorium 2. Prowadzący: Kierunek: Semestr: Rok: Tomasz Gądek Informatyka Zimowy 2

Transkrypt

1 Państwowa Wyższa Szkoła Zawodowa w Tarnowie Zakład Informatyki Laboratorium 2 Git, Bitbucket Prowadzący: Kierunek: Semestr: Rok: Informatyka Zimowy 2

2 Technologie Technologie będące przedmiotem laboratorium: Wstęp Jednym ze znanych i stosowanych systemów kontroli wersji do tworzenia oprogramowania jest Git. Jest to darmowy, na licencji open source, rozproszony system kontroli wersji przeznaczony do szybkiej i wydajnej obsługi różnorodnych projektów. Do przechowywania kodów źródłowych projektów i kontroli wersji wykorzystywane jest repozytorium Git. Repozytoria Git hostowane są w serwisie Bitbucket. Gitflow Z wykorzystaniem Git wiąże się określona struktura repozytorium oraz schemat pracy (workflow), który został przedstawiony na poniższym diagramie. Jest to tzw. Gitflow. Gitflow wykorzystuje 5 todzajów gałęzi (branch), które opisuje poniższa tabela: 1

3 Nazwa gałęzi master branch develop branch feature branch realease branch hotfix branch Opis Master branch odzwierciedla aktualną wersję systemu na środowisku produkcyjnym lub ma stan, który pozwala w każdej chwili wykonać upgrade na środowisko produkcyjne. Po każdym commicie/mergu do master brancha powinien być wykonany upgrade na środowisko produkcyjne oraz należy otagować brancha aktualną wersją. Develop branch zawiera wszystkie nowe funkcjonalności i zmiany, które będą wdrażane w kolejnej wersji systemu. Feature branche tworzone są na potrzeby implementacji nowych funkcjonalności. Zawsze są tworzone z brancha develop i nazywane zgodnie z konwencją feature-nazwa-nowej funkcjonalnosci. Feature branch jest mergowany do brancha develop po zakończeniu prac nad nową funkcjonalnością pod warunkiem, że ta nowa funkcjonalność ma zostać wdrożona na produkcję w następnej wersji systemu. Jeśli nowa funkcjonalność ma zostać wdrożona na produkcję w późniejszym terminie lub nie wiadomo kiedy to nie należy mergować feature brancha do brancha develop. Release branch jest tworzony w momencie gdy w branchu develop znajdują się już wszystkie nowe funkcjonalności zaplanowane do wdrożenia w kolejnej wersji systemu i jest nazywany zgodnie z konwencją release-numer-wersji. Release branch jest tworzony zawsze z brancha develop i ma służyć ustabilizowaniu nowej wersji przed wgraniem jej na produkcję (poprawa błędów) oraz ustawieniu metadanych (numer wersji, data wersji itp.). Do brancha release nie można już dodawać nowych funkcjonalności. Po utworzeniu brancha release można już mergować nowe funkcjonalności do brancha develop przewidziane na kolejny release Po ustabilizowaniu nowej wersji w branchu release zmiany są mergowane zarówno do brancha master jak i develop (aby błędy poprawione w branchu release nie pojawiły się w przyszłości). Hotfix branch jest tworzony z brancha master na potrzeby wprowadzenia poprawki (poprawek) do krytycznego błędu wykrytego na środowisku produkcyjnym. Hotfix branch nazywamy zgodnie z konwencją hotfix-numer-wersji. Po zakończeniu prac nad poprawkami hotfix branch jest mergowany do brancha master oraz do brancha develop (chyba, że jest aktualnie utworzony branch release to wtedy merge powinien być wykonany do brancha release a nie develop). 2

4 Numeracja wersji oprogramowania Określa kolejność powstawania nowych wersji oprogramowania. Dzięki numeracji możemy odróżnić wersje pomiędzy sobą. Zazwyczaj występuje jako zestawienie kilku liczb naturalnych oddzielonych najcześciej kropkami. instagram = instagram-[major].[minor].[release].[build] Nazwa Znaczenie Częstość zmian Kiedy zmieniamy? major numer główny bardzo rzadko Kiedy następuje zmiana koncepcji, podejścia lub API minor numer dodatkowy rzadko Po wdrożeniu nowej funkcjonalności release numer wydania często Po poprawie błędów oraz drobnych zmianach w projekcie build numer builda bardzo często Zmiana wartości z każdym nocnym buildem (nightly-builds) Bitbucket Bitbucket to platforma online, która umożliwia korzystanie z Git w najprostszy możliwy sposób. To wszystko dzięki interaktywnemu interfejsowi graficznemu, który jest łatwy i przystępny dla użytkownika. Poniższy screen przedstawia listę commitów na platformie systemowej Bitbucket. 3

5 Commitowanie zmian do repozytorium Git Każdy commit musi zawierać stosowny komentarz, Komentarz powinien dokładnie opisywać zakres wprowadzonych zmian, Kod wrzucony do repozytorium publicznego (push) nie może powodować problemów z budowaniem projektu. Wyjątkiem od reguły jest praca na gałęzi feature przez jedną osobę, kiedy to ewentualne błędy z komilacji projektu nie mają wpływu na pozostałych członków zespłu, Przed wrzuceniem kodu do repozytorium należy dokładnie przetestować funkcjonalność, której kod dotyczy oraz upewnić się, że zmiany nie wpływają na inne funkcjonalności, Kod wrzucany do repozytorium powinien spełniać standardy kodowania, komentowania, nazewnictwa obiektów oraz powinien być prawidłowo sformatowany, Przed wcommitowaniem zmian należy najpierw wykonać update aby nie nadpisać źródeł zmodyfikowanych międzyczasie przez innych członków zespołu i usunąć ewentualne konflikty, Zmiany w projekcie należy regularnie wrzucać do repozytorium publicznego wykonując komendę push, żeby zabezpieczyć się przed ewentualną utratą danych. Podstawowe polecenia Git a Polecenie git init git clone [adres repozytorium] git add [nazwa pliku z rozszerzeniem] / [-A] git commit -m KOMENTARZ git push origin [nazwa brancha] git remote add origin [adres repozytorium] git checkout -b [nazwa brancha] git checkout [nazwa brancha] git branch -d [nazwa brancha] git pull git merge [nazwa brancha] git log git status git show-branch Znaczenie Tworzenie nowego repozytorium Git Klonowanie repozytorium Git Zaproponowanie zmian (lokalnie) Zatwierdzenie zmian (lokalnie) Wysłanie zmian do zdalnego repozytorium Połączenie istniejącego repozytorium z serwerem Utworzenie nowej gałęzi i przełączenie się na nowego brancha Przełączenie się na brancha Usunięcie lokalnego brancha Aktualizacja lokalnego repozytorium to ostatniego commita Scalanie aktywnej gałęzi z wskazanym branchem Historia commitów Stan plików w lokalnym repozytorium Lista branchy Repozytorium Repozytorium - miejsce przechowywania zmian. 4

6 Ćwiczenia Praca z Bitbucket Proszę zarejestrować się w serwisie Bitbucket. Proszę zapoznać się z interfejsem użytkownika. Proszę utworzyć nowe prywatne repozytorium w następujący sposób: 5

7 Po utworzeniu repozytorium w serwisie Bitbucket proszę o utworzenie i wcommitowanie pliku.gitignore, proszę postępować zgodnie z poniższymi screenami: Plik.gitignore powinien zawierać wpis: *.class - wszystkie pliki z rozszerzeniem *.class nie będą śledzone przez system kontroli wersji. 6

8 Historia wszystkich naszych operacji na repozytorium dostępna jest w menu Commits: Klonowanie repozytorium Proszę utworzyć na dysku własnego komputera lokalizacji dla nowego projektu (przykładowa lokalizacja: /Users/tomaszgadek/Documents/projects). Następnie proszę o uruchomienie konsoli (terminala) systemowej i przejście do utworzonej w poprzednim kroku lokalizacji. W serwisie Bitbucket w menu Source znajduje się button Clone, który posłuży nam za wyświetlenie popupu z linkiem do repozytorium. 7

9 Kopiujemy adres repozytorium i wklejamy go do konsoli / terminala. Po sklonowaniu repozytorium zostanie utworzony folder z identyczną nazwę jak Nasze repozytorium. Po przejęciu do wygenerowanego folderu (cd [nazwa sklonowanego repozytorium]) proszę sprawdzić polecenia git status i git log. 8

10 Wysyłanie zmian do zdalnego repozytorium W obecnej lokalizacji tworzymy plik Main.java. Implementujemy klasę Main, której statyczna metoda main będzie wyświetlała na standardowym wyjściu dowolny komunikat. public class Main { public static void main(string[] args) { System.out.println("Git"); } } Proszę skompilować projekt (po kompilacji zostanie utworzony plik Main.class, który nie powinien być brany pod uwagę podczas wysyłania zmian na serwer. Wykonujemy polecenie git status (plik nie znajduje się jeszcze w poczekalni - Main.java). Dodajemy plik do poczekalni przy pomocy polecenia git add Main.java. Wykonaj polecenie git status (plik znajduje się w poczekalni - Main.java). Następnie wykonujemy commit do lokalnego repozytorium git commit -m my first commit. Proszę wykonać polecenie git status. Po wykonaniu polecenia dostaniemy informację, że commit jest w HEAD. Zostaniemy poproszeni o wysłanie zmian do zdalnego repozytorium w celu opubli- 9

11 kowania lokalnych commitów: git push origin master. Sprawdzamy historię commitów oraz źródła w systemi Bitbucket (pliki powinny się zsynchronizować). Rozgałęzianie i scalanie Z brancha master utworzymy branch hotfix: git checkout -b hotfix-1.0. Opublikujmy branch hotfix: git push origin hotfix-1.0. W systemie Bitbucket w menu Source przełączając się pomiędzy branchami można zauważyć, że zawartości plików Main.java są identyczne. Proszę dodać komentarz nad klasą Main. Następnie wykonujemy polecenia: git add Main.java, git commit -m add comment, git push origin hotfix-1.0. W systemie Bitbucket można zauważyć różnicę w zawartości pliku Main.java podczas przełączania się pomiędzy branchami. Aby scalić branch hotfix z branchem master musimy przełączyć się na branch do którego chcemy mergować: git checkout master, a następnie musimy wykonać merge: git merge hotfix-1.0 oraz wypchnąć dane na serwer: git push origin master. Można sprawdzić w systemie Bitbucket, że gałąź master została zaktualizowana. Aktualizacja lokalnego repozytorium do ostatniego commita Modyfikujemy komentarz pliku Main.java (branch master) w systemie Bitbucket (w menu Source proszę kliknąć na liście plików w Main.java a następnie Edit). Po dokonaniu zmian klikamy Commit. Przełączamy się na konsole, zmieniamy branch na master: git checkout master oraz pobieramy zmiany ze zdalnego repozytorium: git pull origin master. Praca zespołowa Ostatnie zadanie polega na dodaniu do repozytorium kolejnego członka zespołu (kolegę z grupy laboratoryjnej). Darmowe konto w systemie Bitbucket dopuszcza maksymalnie 5 członków zespołu. Wyszukujemy użytkownika w polu Combo następnie nadajemy wybranemu użytkownikowi uprawnienia Admin. Klikamy button Add. 10

12 Został utworzony dwuosobowy zespół. Od tego momentu zaproszony użytkownik ma dostęp do repozytorium. Repozytorium jest wspólne dla obojga programistów. 11