Państwowa Wyższa Szkoła Zawodowa w TarnowieZakład Informatyki

Narzędzia i środowiska programistyczneNarzędzia i środowiska programistyczne

Laboratorium 2Laboratorium 2

Git, Bitbucket

Prowadzący:Kierunek:Semestr:Rok:

Tomasz GądekInformatykaZimowy2

Narzędzia i środowiska programistyczne Tomasz Gądek

Technologie

Technologie będące przedmiotem laboratorium:

Wstęp

Jednym ze znanych i stosowanych systemów kontroli wersji do tworzenia oprogramowania jestGit. Jest to darmowy, na licencji open source, rozproszony system kontroli wersji przeznaczonydo szybkiej i wydajnej obsługi różnorodnych projektów. Do przechowywania kodów źródłowychprojektó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

Narzędzia i środowiska programistyczne Tomasz Gądek

Nazwa gałęzi Opis

master branch Master branch odzwierciedla aktualną wersję systemu na środowiskuprodukcyjnym lub ma stan, który pozwala w każdej chwili wykonać upgradena środowisko produkcyjne.Po każdym commicie/mergu do master brancha powinien być wykonanyupgrade na środowisko produkcyjne oraz należy otagować branchaaktualną wersją.

develop branch Develop branch zawiera wszystkie nowe funkcjonalności i zmiany, które będąwdrażane w kolejnej wersji systemu.

feature branch Feature branche tworzone są na potrzeby implementacji nowychfunkcjonalności. Zawsze są tworzone z brancha develop i nazywane zgodniez konwencją feature-nazwa-nowej funkcjonalnosci. Feature branchjest 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 nowafunkcjonalność ma zostać wdrożona na produkcję w późniejszym terminielub nie wiadomo kiedy to nie należy mergować feature brancha dobrancha develop.

realease branch Release branch jest tworzony w momencie gdy w branchu developznajdują się już wszystkie nowe funkcjonalności zaplanowane do wdrożenia wkolejnej wersji systemu i jest nazywany zgodnie z konwencjąrelease-numer-wersji. Release branch jest tworzony zawsze z branchadevelop i ma służyć ustabilizowaniu nowej wersji przed wgraniem jej naprodukcję (poprawa błędów) oraz ustawieniu metadanych (numer wersji,data wersji itp.). Do brancha release nie można już dodawać nowychfunkcjonalności. Po utworzeniu brancha release można już mergowaćnowe funkcjonalności do brancha develop przewidziane na kolejny releasePo ustabilizowaniu nowej wersji w branchu release zmiany są mergowanezarówno do brancha master jak i develop (aby błędy poprawione wbranchu release nie pojawiły się w przyszłości).

hotfix branch Hotfix branch jest tworzony z brancha master na potrzeby wprowadzeniapoprawki (poprawek) do krytycznego błędu wykrytego na środowiskuprodukcyjnym. Hotfix branch nazywamy zgodnie z konwencjąhotfix-numer-wersji. Po zakończeniu prac nad poprawkami hotfix branchjest mergowany do brancha master oraz do brancha develop (chyba, żejest aktualnie utworzony branch release to wtedy merge powinien byćwykonany do brancha release a nie develop).

2

Narzędzia i środowiska programistyczne Tomasz Gądek

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 oddzielonychnajcześciej kropkami.

instagram-1.2.3.34 = instagram-[major].[minor].[release].[build]

Nazwa Znaczenie Częstość zmian Kiedy zmieniamy?

major numer główny bardzo rzadko Kiedy następuje zmiana koncepcji, podejścialub API

minor numer dodatkowy rzadko Po wdrożeniu nowej funkcjonalności

release numer wydania często Po poprawie błędów oraz drobnychzmianach 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 dlaużytkownika. Poniższy screen przedstawia listę commitów na platformie systemowej Bitbucket.

3

Narzędzia i środowiska programistyczne Tomasz Gądek

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 bu-dowaniem 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ówzespł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, na-zewnictwa 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 ko-mendę push, żeby zabezpieczyć się przed ewentualną utratą danych.

Podstawowe polecenia Git’a

Polecenie Znaczenie

git init Tworzenie nowego repozytorium Git

git clone [adres repozytorium] Klonowanie repozytorium Git

git add [nazwa pliku z rozszerzeniem] / [-A] Zaproponowanie zmian (lokalnie)

git commit -m ”KOMENTARZ” Zatwierdzenie zmian (lokalnie)

git push origin [nazwa brancha] Wysłanie zmian do zdalnego repozytorium

git remote add origin [adres repozytorium] Połączenie istniejącego repozytorium z serwerem

git checkout -b [nazwa brancha] Utworzenie nowej gałęzi i przełączenie się na nowego brancha

git checkout [nazwa brancha] Przełączenie się na brancha

git branch -d [nazwa brancha] Usunięcie lokalnego brancha

git pull Aktualizacja lokalnego repozytorium to ostatniego commita

git merge [nazwa brancha] Scalanie aktywnej gałęzi z wskazanym branchem

git log Historia commitów

git status Stan plików w lokalnym repozytorium

git show-branch Lista branchy

Repozytorium

Repozytorium - miejsce przechowywania zmian.

4

Narzędzia i środowiska programistyczne Tomasz Gądek

Ć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

Narzędzia i środowiska programistyczne Tomasz Gądek

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

Narzędzia i środowiska programistyczne Tomasz Gądek

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 loka-lizacja: /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świe-tlenie popupu z linkiem do repozytorium.

7

Narzędzia i środowiska programistyczne Tomasz Gądek

Kopiujemy adres repozytorium i wklejamy go do konsoli / terminala.

Po sklonowaniu repozytorium zostanie utworzony folder z identyczną nazwę jak Nasze repozy-torium. Po przejęciu do wygenerowanego folderu (cd [nazwa sklonowanego repozytorium])proszę sprawdzić polecenia git status i git log.

8

Narzędzia i środowiska programistyczne Tomasz Gądek

Wysyłanie zmian do zdalnego repozytorium

W obecnej lokalizacji tworzymy plik Main.java. Implementujemy klasę Main, której statycznametoda 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 powi-nien 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 gitstatus (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 commitjest w HEAD. Zostaniemy poproszeni o wysłanie zmian do zdalnego repozytorium w celu opubli-

9

Narzędzia i środowiska programistyczne Tomasz Gądek

kowania lokalnych commitów: git push origin master.

Sprawdzamy historię commitów oraz źródła w systemi Bitbucket (pliki powinny się zsynchroni-zować).

Rozgałęzianie i scalanie

Z brancha master utworzymy branch hotfix: git checkout -b hotfix-1.0. Opublikujmy branchhotfix: 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żnazauważ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 chcemymergować: git checkout master, a następnie musimy wykonać merge: git merge hotfix-1.0 orazwypchnąć dane na serwer: git push origin master. Można sprawdzić w systemie Bitbucket, żegałąź master została zaktualizowana.

Aktualizacja lokalnego repozytorium do ostatniego commita

Modyfikujemy komentarz pliku Main.java (branch master) w systemie Bitbucket (w menu So-urce proszę kliknąć na liście plików w Main.java a następnie Edit). Po dokonaniu zmian klikamyCommit.

Przełączamy się na konsole, zmieniamy branch na master: git checkout master oraz pobieramyzmiany ze zdalnego repozytorium: git pull origin master.

Praca zespołowa

Ostatnie zadanie polega na dodaniu do repozytorium kolejnego członka zespołu (kolegę z grupylaboratoryjnej). Darmowe konto w systemie Bitbucket dopuszcza maksymalnie 5 członków ze-społu. Wyszukujemy użytkownika w polu Combo następnie nadajemy wybranemu użytkownikowiuprawnienia Admin. Klikamy button Add.

10

Narzędzia i środowiska programistyczne Tomasz Gądek

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

11