Pastwowa Wysza Szkoa Zawodowa w TarnowieZakad Informatyki

Narzdzia i rodowiska programistyczneNarzdzia i rodowiska programistyczne

Laboratorium 2Laboratorium 2

Git, Bitbucket

Prowadzcy:Kierunek:Semestr:Rok:

Tomasz GdekInformatykaZimowy2

Narzdzia i rodowiska programistyczne Tomasz Gdek

Technologie

Technologie bdce przedmiotem laboratorium:

Wstp

Jednym ze znanych i stosowanych systemw kontroli wersji do tworzenia oprogramowania jestGit. Jest to darmowy, na licencji open source, rozproszony system kontroli wersji przeznaczonydo szybkiej i wydajnej obsugi rnorodnych projektw. Do przechowywania kodw rdowychprojektw i kontroli wersji wykorzystywane jest repozytorium Git. Repozytoria Git hostowane sw serwisie Bitbucket.

Gitflow

Z wykorzystaniem Git wie si okrelona struktura repozytorium oraz schemat pracy (workflow),ktry zosta przedstawiony na poniszym diagramie. Jest to tzw. Gitflow.

Gitflow wykorzystuje 5 todzajw gazi (branch), ktre opisuje ponisza tabela:

1

https://bitbucket.org/product

Narzdzia i rodowiska programistyczne Tomasz Gdek

Nazwa gazi Opis

master branch Master branch odzwierciedla aktualn wersj systemu na rodowiskuprodukcyjnym lub ma stan, ktry pozwala w kadej chwili wykona upgradena rodowisko produkcyjne.Po kadym commicie/mergu do master brancha powinien by wykonanyupgrade na rodowisko produkcyjne oraz naley otagowa branchaaktualn wersj.

develop branch Develop branch zawiera wszystkie nowe funkcjonalnoci i zmiany, ktre bdwdraane w kolejnej wersji systemu.

feature branch Feature branche tworzone s na potrzeby implementacji nowychfunkcjonalnoci. Zawsze s tworzone z brancha develop i nazywane zgodniez konwencj feature-nazwa-nowej funkcjonalnosci. Feature branchjest mergowany do brancha develop po zakoczeniu prac nad nowfunkcjonalnoci pod warunkiem, e ta nowa funkcjonalno ma zostawdroona na produkcj w nastpnej wersji systemu. Jeli nowafunkcjonalno ma zosta wdroona na produkcj w pniejszym terminielub nie wiadomo kiedy to nie naley mergowa feature brancha dobrancha develop.

realease branch Release branch jest tworzony w momencie gdy w branchu developznajduj si ju wszystkie nowe funkcjonalnoci zaplanowane do wdroenia wkolejnej wersji systemu i jest nazywany zgodnie z konwencjrelease-numer-wersji. Release branch jest tworzony zawsze z branchadevelop i ma suy ustabilizowaniu nowej wersji przed wgraniem jej naprodukcj (poprawa bdw) oraz ustawieniu metadanych (numer wersji,data wersji itp.). Do brancha release nie mona ju dodawa nowychfunkcjonalnoci. Po utworzeniu brancha release mona ju mergowanowe funkcjonalnoci do brancha develop przewidziane na kolejny releasePo ustabilizowaniu nowej wersji w branchu release zmiany s mergowanezarwno do brancha master jak i develop (aby bdy poprawione wbranchu release nie pojawiy si w przyszoci).

hotfix branch Hotfix branch jest tworzony z brancha master na potrzeby wprowadzeniapoprawki (poprawek) do krytycznego bdu wykrytego na rodowiskuprodukcyjnym. Hotfix branch nazywamy zgodnie z konwencjhotfix-numer-wersji. Po zakoczeniu prac nad poprawkami hotfix branchjest mergowany do brancha master oraz do brancha develop (chyba, ejest aktualnie utworzony branch release to wtedy merge powinien bywykonany do brancha release a nie develop).

2

Narzdzia i rodowiska programistyczne Tomasz Gdek

Numeracja wersji oprogramowania

Okrela kolejno powstawania nowych wersji oprogramowania. Dziki numeracji moemy odrniwersje pomidzy sob. Zazwyczaj wystpuje jako zestawienie kilku liczb naturalnych oddzielonychnajczeciej kropkami.

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

Nazwa Znaczenie Czsto zmian Kiedy zmieniamy?

major numer gwny bardzo rzadko Kiedy nastpuje zmiana koncepcji, podejcialub API

minor numer dodatkowy rzadko Po wdroeniu nowej funkcjonalnoci

release numer wydania czsto Po poprawie bdw oraz drobnychzmianach w projekcie

build numer builda bardzo czsto Zmiana wartoci z kadym nocnym buildem(nightly-builds)

Bitbucket

Bitbucket to platforma online, ktra umoliwia korzystanie z Git w najprostszy moliwy sposb.To wszystko dziki interaktywnemu interfejsowi graficznemu, ktry jest atwy i przystpny dlauytkownika. Poniszy screen przedstawia list commitw na platformie systemowej Bitbucket.

3

https://bitbucket.org/producthttps://bitbucket.org/product

Narzdzia i rodowiska programistyczne Tomasz Gdek

Commitowanie zmian do repozytorium Git

Kady commit musi zawiera stosowny komentarz,

Komentarz powinien dokadnie opisywa zakres wprowadzonych zmian,

Kod wrzucony do repozytorium publicznego (push) nie moe powodowa problemw z bu-dowaniem projektu. Wyjtkiem od reguy jest praca na gazi feature przez jedn osob,kiedy to ewentualne bdy z komilacji projektu nie maj wpywu na pozostaych czonkwzespu,

Przed wrzuceniem kodu do repozytorium naley dokadnie przetestowa funkcjonalno, kt-rej kod dotyczy oraz upewni si, e zmiany nie wpywaj na inne funkcjonalnoci,

Kod wrzucany do repozytorium powinien spenia standardy kodowania, komentowania, na-zewnictwa obiektw oraz powinien by prawidowo sformatowany,

Przed wcommitowaniem zmian naley najpierw wykona update aby nie nadpisa rdezmodyfikowanych midzyczasie przez innych czonkw zespou i usun ewentualne konflikty,

Zmiany w projekcie naley regularnie wrzuca do repozytorium publicznego wykonujc ko-mend push, eby zabezpieczy si przed ewentualn utrat danych.

Podstawowe polecenia Gita

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] Wysanie zmian do zdalnego repozytorium

git remote add origin [adres repozytorium] Poczenie istniejcego repozytorium z serwerem

git checkout -b [nazwa brancha] Utworzenie nowej gazi i przeczenie si na nowego brancha

git checkout [nazwa brancha] Przeczenie si na brancha

git branch -d [nazwa brancha] Usunicie lokalnego brancha

git pull Aktualizacja lokalnego repozytorium to ostatniego commita

git merge [nazwa brancha] Scalanie aktywnej gazi z wskazanym branchem

git log Historia commitw

git status Stan plikw w lokalnym repozytorium

git show-branch Lista branchy

Repozytorium

Repozytorium - miejsce przechowywania zmian.

4

Narzdzia i rodowiska programistyczne Tomasz Gdek

wiczenia

Praca z Bitbucket

Prosz zarejestrowa si w serwisie Bitbucket.Prosz zapozna si z interfejsem uytkownika.Prosz utworzy nowe prywatne repozytorium w nastpujcy sposb:

5

https://bitbucket.org/account/signup/

Narzdzia i rodowiska programistyczne Tomasz Gdek

Po utworzeniu repozytorium w serwisie Bitbucket prosz o utworzenie i wcommitowanie pliku.gitignore, prosz postpowa zgodnie z poniszymi screenami:

Plik .gitignore powinien zawiera wpis: *.class - wszystkie pliki z rozszerzeniem *.class nie bdledzone przez system kontroli wersji.

6

Narzdzia i rodowiska programistyczne Tomasz Gdek

Historia wszystkich naszych operacji na repozytorium dostpna jest w menu Commits:

Klonowanie repozytorium

Prosz utworzy na dysku wasnego komputera lokalizacji dla nowego projektu (przykadowa loka-lizacja: /Users/tomaszgadek/Documents/projects). Nastpnie prosz o uruchomienie konsoli(terminala) systemowej i przejcie do utworzonej w poprzednim kroku lokalizacji.

W serwisie Bitbucket w menu Source znajduje si button Clone, ktry posuy nam za wywie-tlenie popupu z linkiem do repozytorium.

7

Narzdzia i rodowiska programistyczne Tomasz Gdek

Kopiujemy adres repozytorium i wklejamy go do konsoli / terminala.

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

8

Narzdzia i rodowiska programistyczne Tomasz Gdek

Wysyanie zmian do zdalnego repozytorium

W obecnej lokalizacji tworzymy plik Main.java. Implementujemy klas Main, ktrej statycznametoda main bdzie wywietlaa na standardowym wyjciu 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, ktry nie powi-nien by brany pod uwag podczas wysyania 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).

Nastpnie 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 wysanie zmian do zdalnego repozytorium w celu opubli-

9

Narzdzia i rodowiska programistyczne Tomasz Gdek

kowania lokalnych commitw: git push origin master.

Sprawdzamy histori commitw oraz rda w systemi Bitbucket (pliki powinny si zsynchroni-zowa).

Rozgazianie 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 przeczajc sipomidzy branchami mona zauway, e zawartoci plikw Main.java s identyczne.

Prosz doda komentarz nad klas Main. Nastpnie wykonujemy po