Programowanie w jezykach skryptowych - Python i Linux...

Programowanie w jezykachskryptowych - Python i Linux Bash

Maciej Wielgosz

Wydział Informatyki, Elektroniki i Telekomunikacji

2015, semestr zimowy

M. Wielgosz (AGH - IET) Programowanie w jezykach skryptowych - Python i Linux Bash 2015 1 / 138

Czesc II

Git


Git

1 Systemy kontroli wersji2 Systemy scentralizowane a

rozproszone3 Git jako system lokalny

InicjalizacjaStany plikówZapis stanuHistoriaPraca z branchami

4 Git jako system rozproszony

Zdalne repozytoriumPodstawowa synchronizacjaModel pracy oparty o wielerepozytoriów

5 Inne mozliwosciIgnorowanie plikówKonfiguracjaWiecej o komendach iopcjachDodatkowa dokumentacja

6 Organizacja pracy


VCS

System kontroli wersji (ang. Version Control System)Program słuzacy do sledzenia zmian w kodzie/dokumencie zródłowymoraz ułatwiajacy łaczenie modyfikacji pochodzacych z wielu zródeł.

Obecnie VCS stały sie standardem przy pracy nad róznego typuprojektami informatycznymi, ale za VCS mozna uznac takze np.sledzenie zmian w systemach typu Wiki czy pakietach biurowych.


Dlaczego warto uzywac VCS?

Do najwazniejszych zalet VCS mozna zaliczyc:

z proste przegladanie i przywracanie poprzednich wersji plików,z łatwosc synchronizacji zródeł pomiedzy róznymi maszynami i

członkami zespołu,z mozliwosc rozwijania projektu w wielu kierunkach jednoczesnie

(np. naprawianie błedów z ostatniej wersji przy równoczesnejpracy nad nowa funkcjonalnoscia),

z opcje integracji z automatycznymi narzedziami do np. testowaniaczy deploymentu.


Popularne systemy

W chwili obecnej najczesciej mozna spotkac sie z nastepujacymisystemami:

z Apache Subversion (SVN) – stworzony w roku 2000 jako (wwiekszosci kompatybilny) nastepca Concurrent Version System(CVS),

z Mercurial (Hg) – pojawił sie w roku 2005; jego zamierzonympierwotnym zastosowaniem była praca nad rozwojem jadraLinuksa, jednak w tym celu ostatecznie wybrano Git,

z Git – stworzony kilka dni przed Mercurialem i w tym samym celu;obecnie prawdopodobnie najpopularniejszy system kontroli wersji.


Git







6 Organizacja pracy


Systemy lokalne

z Proste bazy danych, która przechowuja wszystkie zmiany wplikach jako kolejne wersje,

z jednym z pierwszych systemów tego typu był RCS (RevisionControl System),

z systemy te działaja na zasadzie przechowywania róznic pomiedzyplikami tzw. patchy,

z mozna odtworzyc jak plik wygladał w dowolnym momencie czasupoprzez zsumowanie wszystkich patchy.


Systemy scentralizowane

z Systemy scentralizowane powstały z potrzeby współdzieleniakodu pomiedzy róznymi developerami i maszynami,

z oparte sa na idei głównego serwera przechowujacego całahistorie i dowolnej ilosci klientów, którzy kopiuja z centralnegoserwera pliki,

z jednym z najpopularniejszych przykładów takich systemów jestApache Subversion (SVN),

z przez wiele lat systemy scentralizowane były standardem wobszarze kontroli wersji.


Zalety i wady systemów scentralizowanych

Zalety (w stosunku do systemów lokalnych):

z kazdy do pewnego stopnia orientuje sie, co robia inni członkowiezespołu,

z szczegółowa kontrola uprawnien uzytkowników,z łatwiejsze zarzadzanie (łatwiej zarzadzac jednym repozytorium niz

wieloma lokalnymi).


Zalety i wady systemów scentralizowanych

Wady:

z niedostepnosc centralnego repozytorium powoduje paraliz pracycałego zespołu, ze wzgledu na brak komunikacji z baza danych,

z awaria centralnego serwera powoduje utrate całej historii pracy(chyba ze były tworzone kopie zapasowe).


Systemy rozproszone

Zasada działaniaSystemy rozproszone przechowuja lokalnie cała historie zmian, copozwala uzytkownikowi na prace niezaleznie od dostepnosci innychwezłów.


Zalety systemów rozproszonych

Zalety:

z kazda kopia repozytorium słuzy jednoczesnie jako kompletnerepozytorium,

z istnieje mozliwosc uzywania kilku zdalnych („centralnych”)serwerów,

z taka architektura umozliwia stosowanie wielu modeli organizacjipracy,

z obecnie najpopularniejszym przykładem systemu rozproszonegojest git.


Podsumowanie

Systemy scentralizowane sa tworzone z załozeniem, ze istnieje jednowłasciwe (absolutne) zródło.

Systemy rozproszone:

z zostały stworzone z załozeniem, ze kazde repozytorium jest taksamo dobre jak inne,

z dzielenie i scalanie repozytoriów jest po prostu forma komunikacji,z decyzja o znaczeniu danego repozytorium jest podejmowania

indywidualnie i nie jest kontrolowana przez oprogramowanie.


Git







6 Organizacja pracy


Git jako system lokalny

Główna zaleta systemów rozproszonych jest ich autonomicznosc:

z aby z nich korzystac, nie jest potrzebny zaden serwer,z w podstawowej wersji wszystko moze odbywac sie tak, jak przy

stosowaniu najprostszego lokalnego systemu.


Git CLI

Program git działa na zasadzie komend (podprogramów), z którychniemal kazda ma odrebny zestaw argumentów.

Liste wspólnych opcji oraz najczesciej uzywanych komend moznazobaczyc wpisujac:

$ git --help

Szczegółowe opcje poszczególnych komend mozna zobaczycuzywajac:

$ git <command> --help



InicjalizacjaStany plików

Zapis stanuHistoriaPraca z branchami


Nowe repozytorium

Załozenie nowego, lokalnego repozytorium w wybranym katalogu(moga wczesniej istniec w nim jakies pliki; w przykładach uzywanybedzie katalog acai):

$ cd acai$ git initInitialized empty Git repository in

↪→ /[...]/acai/.git/


Dodanie istniejacych plików

Stworzone w ten sposób repozytorium nie sledzi jeszcze zadnychzmian w plikach. Aby rozpoczac kontrolowanie wersji dla juzistniejacych w katalogu plików nalezy wydac dwa polecenia. Pierwszez nich to:

$ git add .

Powoduje ono dodanie do kontroli wersji wszystkich plików zbiezacego (.) katalogu. Co dokładnie zostało dodane moznasprawdzic wydajac polecenie git status.


Dodanie istniejacych plików

$ git statusOn branch master

Initial commit

Changes to be committed:(use "git rm --cached <file>..." to unstage)

new file: .gitignorenew file: LICENSE.txtnew file: README.md...


Pierwszy commit

Druga komenda instruuje gita, aby „zapamietał ten punkt w historii”. Wwersji podstawowej wyglada ono tak:

$ git commit

Po wykonaniu polecenia otwierany jest domyslnie skonfigurowanyedytor tekstowy w którym nalezy podac opis własnie tworzonego„punktu”.

Standardowo opis ten musi zostac dodany – w przeciwnym razietworzenie punktu zostanie anulowane.


Pierwszy commit

Czesto opis (wiadomosc, ang. message) podaje sie bezposrednio zlinii polecen:

$ git commit -m "Project skeleton"[master (root-commit) 6048090] Project skeleton19 files changed, 718 insertions(+)create mode 100644 .gitignorecreate mode 100644 LICENSE.txtcreate mode 100644 README.md...


Pełna inicjalizacja

Podsumowujac, rozpoczecie lokalnej pracy z gitem najczesciejprzebiega nastepujaco:

$ cd <project_dir>$ git init...$ git add .$ git commit -m "Initial commit"...


Mozliwe stany plików

Pliki w gicie moga znajdowac sie w jednym z 2 stanów:

z niesledzone (ang. untracked) – pliki, których stanu git nieprzechowuje

z sledzone (ang. tracked) – takie, o których git „wie”

Aby plik był sledzony, nalezy go dodac do gita, np. uzywajac poleceniagit add.

Usuniecie pliku z listy sledzonych (i z dysku!) po stworzeniu commitaodbywa sie za pomoca git rm.


Sledzenie zmian

Sledzone pliki moga byc:

z niezmodyfikowane (ang. unmodified) – takie, które nie zmieniłysie od czasu ostatniego zapisu stanu

z zmodyfikowane (ang. modified) – takie, w których sawprowadzone jakies zmiany


Sledzenie zmian

Kazdy zmodyfikowany plik zawiera jedna lub wiecej zmian. Wartopamietac, ze git ma mozliwosc zapisu stanu kazdej zmiany z osobna.

Kazda zmiana moze byc zatwierdzona (w nomenklaturze gita staged)lub nie. Zwykle jednak nie rozpatruje sie kazdej zmiany pojedynczo,tylko zatwierdza wszystkie w danym pliku.

To, na jakim etapie „cyklu zycia” jest dana zmiana mozna podejrzecuzywajac komendy git status.


Status pliku

$ git statusOn branch masterChanges not staged for commit:

(use "git add <file>..." to update what will be↪→ committed)

(use "git checkout -- <file>..." to discard↪→ changes in working directory)

modified: LICENSE.txtmodified: README.md

no changes added to commit (use "git add" and/or↪→ "git commit -a")


Zatwierdzenie zmian

Zatwierdzenie (wszystkich) zmian w danych plikach odbywa sie przyuzyciu polecenia git add:

$ git add LICENSE.txt README.md$ git statusOn branch masterChanges to be committed:

(use "git reset HEAD <file>..." to unstage)

modified: LICENSE.txtmodified: README.md


Zatwierdzenie zmian

Do zatwierdzenie wszystkich zmian we wszystkich zmodyfikowanychplikach, a takze dodania do kontroli wersji nowych (i usuniecia z niejjuz nieistniejacych), przydatna jest opcja -A:

$ git add -A

Oznacza ona w skrócie „zatwierdz wszystko”.


Wycofanie zmian

Jesli któras z zatwierdzonych zmian jednak nie powinna zostaczapisana, mozna uzyc git reset, aby ja wycofac:

$ git reset README.mdUnstaged changes after reset:M README.md

Polecenie to (w tej formie) nie powoduje zadnych zmian w pliku –informuje tylko gita, ze dana zmiana (zmiany) maja jeszcze nie byczapisywane.


Podejrzenie zmian

Do podgladania, co zostało zmienione od ostatniego zapisu stanu(ogólnie lub w danym pliku) słuzy polecenie git diff:

$ git diff README.md

Otworzy ono edytor, w którym zaznaczone beda miejsca wystapieniazmian.

W najprostszym przypadku lista róznic bedzie miała postac plikutekstowego, zawierajacego informacje o tym, które linie i w jakichplikach zostały zmienione.


git diff

1 diff --git a/README.md b/README.md2 index e69de29..1edb8e1 1006443 --- a/README.md4 +++ b/README.md5 @@ -0,0 +1,3 @@6 +ACAI - ACcelerated AI7 +8 +Suite of Artificial Intelligence algorithms

↪→ implemented with future hardware↪→ acceleration (via OpenCL) in mind.

git diff README.md


Podwójny status pliku

Czasami moze zdarzyc sie, ze plik znajduje sie zarówno na lisciezmian zatwierdzonych do zapisu (staged), jak i na liscie zmian jeszczenie zatwierdzonych (unstaged).

Wynika to ze wspomnianego wczesniej sledzenia pojedynczych zmian– jesli zatwierdzony był cały plik, to tak naprawde zatwierdzone byływszystkie zmiany znajdujace sie w nim w danym momencie.

Jesli uległ on dalszej modyfikacji (nawet nadpisujacej zatwierdzonezmiany), to nowe modyfikacje równiez trzeba zatwierdzic, by mogłybyc zapisane.


Komenda commit

Zatwierdzone zmiany zapamietuje sie uzywajac poleceniagit commit. Tworzy ono opisany punkt na osi czasu, do któregomozna powracac.

Kazdy commit identyfikowany jest przez unikalny hash, automatyczniegenerowany na podstawie danych takich jak biezacy czas, autorcommita czy wprowadzony opis.

Hash ten pozwala stwierdzic, czy dwa commity posiadajace ten samopis faktycznie sa takie same.

Wiele polecen gita przyjmuje hash jako jeden ze swoich argumentów.Cały identyfikator jest jednak kłopotliwy w uzyciu (SHA1 generuje ciagio długosci 40 znaków), wiec czesto stosuje sie tylko 7 pierwszych jegoznaków.


Always commit, you must

Stworzony commit zabezpiecza przed utrata wyników pracy.

Czesto okazuje sie, ze poprzednie rozwiazanie było tym własciwym...

Jezeli zapisany został tylko stan po wszystkich poprawkach, nie ma jakpodejrzec i/lub wykorzystac w tym celu pierwotnego rozwiazania –trzeba napisac je od nowa.


Always commit, you must

Jezeli natomiast stan był zapisywany po kazdym etapie pracy, to złatwoscia mozna przywrócic plik do poprzedniego stanu – czy to wcelu zastapienia obecnej wersji, czy tylko „podejrzenia” i ekstrakcjipotrzebnych fragmentów.

Miedzy innymi z tego powodu warto jest wyrobic sobie nawyktworzenia czestych i dobrze opisanych commitów. Przyda sie to takzew pózniejszej, zespołowej pracy z gitem – a czasami moze okazac siejedyna deska ratunku w przypadku wystapienia jakichs problemów.


Podstawowe uzycie

$ git commit

Uruchomienie powyzszej komendy otworzy domyslny edytor (vim), wktórym nalezy wprowadzic opis. Standardowo plik ten zawierakomentarz, dostarczajacy dodatkowych informacji o tworzonymwłasnie commicie.


Podstawowe uzycie

1

2 # Please enter the commit message for your↪→ changes. Lines starting

3 # with ’#’ will be ignored, and an empty message↪→ aborts the commit.

4 # On branch master5 # Changes to be committed:6 # modified: LICENSE.txt7 #8 # Changes not staged for commit:9 # modified: README.md

10 #

Domyslna zawartosc pliku z opisem


Podstawowe uzycie

Domyslnie, jesli nie wpiszemy tresci opisu, commit zostanieanulowany:

Aborting commit due to empty commit message.


Opis z linii polecen

Czesto uzywa sie parametru -m, aby wprowadzic opis bezposrednio zlinii polecen:

$ git commit -m "Change license to MIT"[master 3278ed2] Change license to MIT1 file changed, 21 insertions(+), 1 deletion(-)rewrite LICENSE.txt (100%)


Zatwierdzenie wszystkich zmian przy zapisie

Aby nie dodawac recznie zmian w kazdym sledzonym juz pliku, moznauzyc opcji -a:

$ git commit -a -m "Add basic repo description"[master fc13f88] Add basic repo description1 file changed, 3 insertions(+)

Opcja ta dotyczy tylko juz sledzonych plików. Jezeli w repo zostałystworzone nowe, nalezy dodac je „normalnie”, uzywajac np.git add -A.


Edycja commita

Zdarza sie, ze przy tworzeniu commita nastapiła pomyłka, np.literówka w opisie czy pominiety plik. Z pomoca przychodzi wtedyopcja --amend, pozwalajaca na łatwa edycje ostatniego commita:

$ git commit --amend -m "Add basic project↪→ description"

[master bb3823f] Add basic project descriptionDate: Wed Oct 14 13:45:38 2015 +02001 file changed, 3 insertions(+)


Edycja commita

To, co tak naprawde git robi, to usuwa ostatni commit i w jego miejscetworzy nowy, zawierajacy wszystkie zmiany z tego usunietego oraznowo zatwierdzone. Mozna to zaobserwowac porównujac ichidentyfikatory.

W wyniku edycji powstaje nowy commit. Nie ma to wielkiegoznaczenia w przypadku lokalnego uzycia gita, jest jednak wazne przybardziej zaawansowanych zastosowaniach.


Ostatni commit

Opis i zmiany zapisane w ostatnim commicie mozna zobaczyckorzystajac z polecenia git show. Analogicznie jak git diff otworzyono edytor z plikiem zawierajacym liste zmian i dodatkowoinformacjami o commicie:

1 commit bb3823f63f1254108238951a60b319fcc3a1b1a72 Author: Maciej Wielgosz <[email protected]>3 Date: Wed Oct 14 13:45:38 2015 +02004

5 Add basic project description6

7 diff --git a/README.md b/README.md


Ostatni commit

8 index e69de29..8dd37ac 1006449 --- a/README.md

10 +++ b/README.md11 @@ -0,0 +1,3 @@12 +ACAI - ACcellerated AI13 +14 +Suite of Artificial Intelligence algorithms

↪→ implemented with future hardware↪→ acceleration (via OpenCL) in mind.

git show


Przeglad historii

Skrócona historie commitów mozna przegladac przy uzyciu poleceniagit log. Bedzie ona otworzona w domyslnym edytorze.

1 commit bb3823f63f1254108238951a60b319fcc3a1b1a72 Author: Maciej Wielgosz <[email protected]>3 Date: Wed Oct 14 13:45:38 2015 +02004

5 Add basic project description6

7 commit 3278ed255627fa64ede6ab587e0d2c8c2711d2038 Author: Maciej Wielgosz <[email protected]>9 Date: Wed Oct 14 13:23:57 2015 +0200

10

11 Change license to MIT


Przeglad historii

13 commit 6048090a0ce0997025957d5fd88224d9582aaa0a14 Author: Maciej Wielgosz <[email protected]>15 Date: Mon Oct 12 22:28:43 2015 +020016

17 Project skeleton

git log

Pełna informacje o zmianach mozna wyswietlic podajac argument wpostaci hasha do polecenia git show, np. git show 3278ed2.


Historyczne wersje pliku

Aby zobaczyc, jak wygladał dany plik w konkretnym punkcie historii lubprzywrócic go do tego stanu, mozna uzyc komendy git checkout

podajac hash interesujacego commita i sciezke do pliku.

$ git checkout 6048090 LICENSE.txt

Przywrócenie go do biezacej wersji (z najnowszego commita) odbywasie analogicznie (HEAD odpowiada ostatniemu commitowi):

$ git checkout HEAD LICENSE.txt


Historyczne wersje pliku

Dostepne sa równiez pewne skróty, np.

$ git checkout HEAD~2 LICENSE.txt

cofa plik LICENSE.txt o 2 wersje.

Nalezy zauwazyc, ze wynikiem polecenia git checkout nie jest tylkopodglad – dokonywane sa faktyczne zmiany w pliku, które w raziepotrzeby mozna zatwierdzic i zapisac.


Podglad historycznej wersji pliku

Jezeli pozadany jest tylko podglad, bez wprowadzania zmian do pliku,mozna skorzystac z wariantu polecenia git show:

$ git show HEAD~2:./LICENSE.txt

Jako separatora pomiedzy identyfikatorem wersji, a sciezka do plikuuzywa sie : (bez spacji!).


Znaczace opisy

Dobre opisy commitów znaczaco ułatwiaja prace z historia zmian.

Moga pomóc znacznie zawezic przeszukiwany przedział czasu wprzypadku np. pojawienia sie nowych błedów czy ułatwic znalezieniekonkretnej wersji pliku.

Czytelne opisy sa istotne zwłaszcza w przypadku pracy w grupie orazkorzystania z narzedzi automatycznie generujacych liste zmian(changelog) w projekcie.



InicjalizacjaStany plikówZapis stanuHistoria

Praca z branchamiTworzenieŁaczenieKonfliktyUsuwanieRebase


Branch

BranchOdgałezienie projektu, zwykle wydzielone w celu realizacji konkretnejfunkcjonalnosci.

Wszystkie repozytoria git maja domyslny, główny branch o nazwie’master’. Zwykle stanowi on baze, na podstawie której tworzy sie innebranche.


Istniejace branche

Sprawdzenie, jakie branche istnieja w projekcie odbywa sie za pomocapolecenia git branch.

$ git branch

* master

W momencie stworzenia nowego repozytorium branch ’master’ nie jestwidoczny na liscie branchy – pojawia sie on tam dopiero po pierwszymcommicie.

Aktywny branch (czyli ten, do którego „przynaleza” wersje plikówznajdujace sie obecnie na dysku) oznaczony jest *. W danej chwiliaktywny moze byc tylko jeden branch.


Tworzenie

Jednym ze sposobów stworzenia nowego brancha jest:

git branch <branch_name>

Polecenie to tworzy nowy branch, ale go nie aktywuje. Aby zaczacprace nalezy sie na niego przełaczyc:

git checkout <branch_name>

Jest to standardowy sposób przełaczania sie miedzy branchami.


Tworzenie

Wygodniejszym sposobem jest stworzenie nowego brancharównoczesnie z jego aktywacja, przy uzyciu opcji -b:

$ git checkout -b documentationSwitched to a new branch ’documentation’

Nowo stworzony branch domyslnie poczatkowo znajduje sie w tymsamym punkcie, co obecnie aktywny. Mozna takze podac, którybranch ma stanowic „baze” nowo tworzonego:

$ git checkout -b docs masterSwitched to a new branch ’docs’


Merge

Po zakonczeniu pracy nad dana funkcjonalnoscia i jej przetestowaniuprzychodzi czas na właczenie jej do głównego brancha. Jednym zesposobów, by to zrobic, jest uzycie polecenia git merge. Abypołaczyc branche za jego pomoca, nalezy najpierw przełaczyc sie nadocelowy branch (zwykle ’master’).

$ git checkout masterSwitched to branch ’master’$ git merge docsUpdating 0903642..48e8690Fast-forwardREADME.md | 5 +++++1 file changed, 5 insertions(+)


Merge


Konflikty

Nie zawsze merge przebiega bez problemów. Jesli dany plik zostałzmieniony zarówno w branchu, który chcemy dołaczyc, jak i w branchudocelowym, moga pojawic sie konflikty, z którymi git nie poradzi sobieautomatycznie.

$ git checkout documentationSwitched to branch ’documentation’$ git merge docsAuto-merging README.mdCONFLICT (content): Merge conflict in README.mdAutomatic merge failed; fix conflicts and then

↪→ commit the result.


Konflikty

W takim wypadku dostepne sa dwie opcje postepowania:

1 anulowanie operacji:

$ git merge --abort

2 manualne rozwiazanie konfliktów i stworzenie commita łaczacegokonfliktowe zmiany w pozadany sposób. Wykorzystywane w tymcelu sa polecenia git add i git commit.


Rozwiazywanie konfliktów

Git dodaje do pliku charakterystyczne znaczniki w miejscach, wktórych nastapił konflikt:

1 ACAI - ACcellerated AI2 ======================3

4 <<<<<<< HEAD5 Lorem ipsum dolor sit amet, consectetur [...]6 =======7 Suite of Artificial Intelligence algorithms [...]

12 >>>>>>> docs

Plik README.md z konfliktami



Przy wystapieniu konfliktu jako pierwsze wyswietlane sa zmiany, którebyły zapisane na aktywnym branchu. Nastepnie (po =======)wyswietlane sa zmiany, które pochodza z dołaczanego brancha.

Rozwiazywanie konfliktów polega na wyszukania wszystkichwystapien takich alternatyw i zastapieniu ich (łacznie z markeramiograniczajacymi) pozadana zawartoscia.



1 ACAI - ACcellerated AI2 ======================3

4 Suite of Artificial Intelligence algorithms [...]5

6 Lorem ipsum dolor sit amet, consectetur [...]7

8 ## Idea9

10 [...]

README.md z rozwiazanymi konfliktami



Rozwiazanie konfliktu oznaczamy uzywajac git add.

$ git add README.md

Jesli wszystkie konflikty zostały rozwiazane, to mozna zakonczycmerge:

$ git commit[documentation 33693fc] Merge branch ’docs’ into

↪→ documentation


Usuwanie

Jesli chcemy usunac jakis branch, nie moze on byc aktywny.

Aby usunac branch, który został dołaczony do biezacego („bezpieczneusuniecie”), uzywa sie opcji -d:

$ git checkout masterSwitched to branch ’master’$ git branch -d docsDeleted branch docs (was 48e8690).


Usuwanie

Aby usunac branch, który juz nie jest potrzebny, a nie jest dołaczonydo biezacego (np. w miedzyczasie powstała zupełnie inna koncepcjarozwiazania danego problemu), nalezy skorzystac z opcji -D (-dzwróci bład):

$ git branch -d documentationerror: The branch ’documentation’ is not fully

↪→ merged.If you are sure you want to delete it, run ’git

↪→ branch -D documentation’.$ git branch -D documentationDeleted branch documentation (was 33693fc).


Rebase

Alternatywnym podejsciem do scalania zmian jest stosowaniekomendy git rebase.

Jej działanie polega na edycji kolejnosci commitów (a co za tym idzie,na edycji zawartosci samych commitów) tak, by commity z branchapodlegajacego operacji rebase wydawały sie stworzonechronologicznie po wszystkich commitach brancha bazowego.

Pozwala to na pózniejsze bezkonfliktowe zastosowanie poleceniagit merge.


Rebase

Załózmy, ze przed merge brancha ’docs’ został na bazie brancha’master’ stworzony branch ’setup’. Porównanie historii commitów wbranchach ’master’ i ’setup’ pozwala stwierdzic, ze róznia sie onejednym commitem.

$ git checkout setupSwitched to branch ’setup’$ git log


Rebase

1 commit 8e4bd6bf762a577795c42a33fb5ca27f9d2d43d72 Author: Maciej Wielgosz <[email protected]>3 Date: Wed Oct 14 22:28:05 2015 +02004

5 Correctly configure console entry point6

7 commit 0903642a4b1118f7a75e10dad7f8271d2d28e4ed8 Author: Maciej Wielgosz <[email protected]>9 [...]

git log dla brancha ’setup’


Rebase

1 commit 48e8690b2f7019dfc811bcc6f88e6d197198f7962 Author: Maciej Wielgosz <[email protected]>3 Date: Wed Oct 14 19:42:20 2015 +02004

5 Added some formatting & idea description6


git log dla brancha ’master’


Rebase

Chcielibysmy, by docelowa kolejnosc commitów w branchu masterzawierała najpierw commit 48e8690, a nastepnie 8e4bd6b – bezzadnych dodatkowych commitów wynikajacych z merge (tzw. mergefast-forward).


Rebase


Rebase

Oznacza to, ze przed właczeniem brancha ’setup’ do ’master’ musimyzawrzec wszystkie commity z ’master’ (bedacego baza) w ’setup’.Innymi słowy: ustalic nowa baze dla ’setup’ (branch ’setup’ musi bycaktywny):

$ git rebase masterFirst, rewinding head to replay your work on top

↪→ of it...Applying: Correctly configure console entry point


Rebase


Rebase

Po rebase historia brancha ’setup’ wyglada nastepujaco:

1 commit 3fe7e9e09628669e39f17c8cef6e4031326b42232 Author: Maciej Wielgosz <[email protected]>3 Date: Wed Oct 14 22:28:05 2015 +02004

5 Correctly configure console entry point6

7 commit 48e8690b2f7019dfc811bcc6f88e6d197198f7968 Author: Maciej Wielgosz <[email protected]>


Rebase

9 Date: Wed Oct 14 19:42:20 2015 +020010

11 Added some formatting & idea description12


git log dla brancha ’setup’ po rebase

Warto zwrócic uwage na identyfikatory commitów – nawet wprzypadku braku konfliktów (które rozwiazuje sie analogicznie jak przyuzyciu merge) git tak naprawde zastepuje wszystkie unikatowecommity stworzone w branchu podlegajacemu rebase nowymi.


Rebase

Ostatnim krokiem jest właczenie brancha ’setup’ do ’master’:

$ git checkout masterSwitched to branch ’master’$ git merge setupUpdating 48e8690..3fe7e9eFast-forwardacai/main.py | 2 +-setup.cfg | 11 ++++-------2 files changed, 5 insertions(+), 8 deletions(-)


Uzywanie rebase

Zalety:

z bardziej przejrzysta historia (unika sie potencjalnie sporej ilosci„merge commitów”),

z poniewaz rebase de facto tworzy nowe commity, moze on zostacwykorzystany do uporzadkowania historii brancha podlegajacegotej operacji (np. edycja starych opisów, łaczenie i rozdzielaniecommitów). Aby skorzystac z tej mozliwosci uzywa sie trybuinteraktywnego (git rebase -i <base_branch>).


Uzywanie rebase

Wady i niebezpieczenstwa:

z w przeciwienstwie do merge, rebase jest potencjalniedestrukcyjna operacja. Oznacza to, ze w razie pomyłki moznazaprzepascic wyniki pracy,

z nigdy nie powinno sie uzywac rebase na tzw. publicznychbranchach – czyli takich, których w jakims celu uzywa tez ktosinny (albo na podstawie którego powstały inne branche). Z punktuwidzenia gita commity przepisane po rebase i oryginalne commityto dwie zupełnie rózne rzeczy (nawet jesli prowadza do tegosamego rezultatu). W efekcie próba połaczenia oryginalnych i„nowych” zmian wygeneruje ogromna ilosc konfliktów.


Uzywanie rebase

Przydatne uwagi:

z nigdy nie powinno sie przeprowadzac operacji rebase na branchu’master’,

z przed nieudanym rebase mozna sie w pewnym stopniuzabezpieczyc, tworzac tymczasowy branch:

$ git checkout feature-branch$ git checkout -b temporary-branch$ git rebase -i master$ git checkout master$ git merge temporary-branch


Git







6 Organizacja pracy


Git jako system rozproszony

Zdalne repozytoriumPodstawowa synchronizacja

Model pracy oparty o wielerepozytoriów


Zdalne repozytorium

W wiekszosci zastosowan jedno z repozytoriów dostepne dla całegozespołu słuzy jako repozytorium centralne, analogicznie jak wsystemach scentralizowanych.

Repozytorium takie zwykle tworzone jest zanim zacznie siejakakolwiek praca na kodem lub tuz po stworzeniu minimalnegoszkieletu projektu. Pozwala to na zminimalizowanie pózniejszegokonfigurowania lokalnych kopii.


Remote

RemoteRepozytorium, najczesciej zdalne, które jest powiazane z danainstancja repo (nie musi byc to repozytorium centralne, moze to bycnp. kopia na maszynie innego developera).

Przyjeło sie, ze domyslny remote dla danego repozytorium nosi nazwe’origin’.


Ustawienie remote w istniejacym repo

Aby dodac remote do istniejacego repo (przykładowo, gdy cała pracaodbywała sie lokalnie, a teraz została podjeta decyzja o upublicznieniuwyników) nalezy posłuzyc sie wariantem komendy git remote:

$ git remote add origin↪→ [email protected]:maciekwielgosz/acai.git

Aby zobaczyc dostepne remote’y wraz z ich URLami, mozna uzyc:

$ git remote -vorigin [email protected]:maciekwielgosz/acai.git

↪→ (fetch)origin [email protected]:maciekwielgosz/acai.git

↪→ (push)


Ustawienie remote w istniejacym repo

Samo dodanie remote jednak nie wystarczy. Dla wygody uzytkowaniapowinno sie takze ustawic dodany własnie remote jako domyslny przyzadaniu synchronizacji pomiedzy repozytoriami (tzw. upstream). Wprzeciwnym razie bedzie trzeba go podawac przy kazdym tego typuzadaniu.

Dalsze postepowanie zalezy od tego, czy zdalne repozytorium (’origin’)zawiera juz jakies dane, czy tez jest puste.


Puste zdalne repozytorium

Jesli uzyte ma byc puste repozytorium, to pierwsza czynnoscia pododaniu remote do istniejacego projektu powinno byc powielenieistniejacej lokalnej struktury w zdalnym repozytorium. Równoczesniew trakcie tej operacji mozna ustawic nowy remote jako domyslny dosynchronizacji dla istniejacych branchy (opcja -u lub--set-upstream).


Puste zdalne repozytorium

Wysłanie (push) na remote ’origin’ wszystkich (--all) istniejacychlokalnie branchy:

$ git push -u origin --allCounting objects: 50, done.Delta compression using up to 8 threads.Compressing objects: 100% (41/41), done.Writing objects: 100% (50/50), 12.84 KiB | 0

↪→ bytes/s, done.Total 50 (delta 13), reused 0 (delta 0)To [email protected]:maciekwielgosz/acai.git

* [new branch] master -> masterBranch master set up to track remote branch

↪→ master from origin.


Zdalne repozytorium z zawartoscia

Jesli w zdalnym repozytorium juz istnieje branch, który ma bycustawiony jako domyslny przy synchronizacji, mozna zastosowac tosamo polecenie (wysłanie lokalnych zmian z równoczesnymzapamietaniem remote):

$ git push -u origin masterBranch master set up to track remote branch



Zdalne repozytorium z zawartoscia

Alternatywa jest skorzystanie z wariantu polecenia git branch (niedokonuje ono równoczesnie synchronizacji):

$ git branch -u origin/masterBranch master set up to track remote branch


Warto zwrócic uwage na róznice w składni powyzszych polecen.git branch przyjmuje jako argument tylko nazwe brancha(origin/master traktowane jest jako całosc). Pozwala ono naustawienie jako upstream zdalnego brancha o nazwie innej niz lokalna,podczas gdy przy uzyciu push nazwy musza sie zgadzac.


Klonowanie

Jezeli chcemy dopiero zaczac prace z repo, które juz gdzies zdalnieistnieje, najprostszym sposobem jest uzycie git clone.

Pobierze ono automatycznie wszystkie istniejace branche, pozwalajacna natychmiastowe rozpoczecie pracy (beda one domyslnieskonfigurowane, by pobierac i wysyłac zmiany na ’origin’, czyli repo, zktórego sklonowano instancje).


Klonowanie

$ git clone↪→ [email protected]:maciekwielgosz/acai.git↪→ acai-clone

Cloning into ’acai-clone’...remote: Counting objects: 50, done.remote: Compressing objects: 100% (41/41), done.remote: Total 50 (delta 13), reused 0 (delta 0)Receiving objects: 100% (50/50), 12.84 KiB | 0

↪→ bytes/s, done.Resolving deltas: 100% (13/13), done.Checking connectivity... done.

Dodatkowy argument ustawia nazwe lokalnego katalogu na acai-clone.


Wysyłanie zmian

Zmiany wysyłane sa do zdalnego repo przy uzyciu znanego juzgit push.

To, jakie branche git bedzie próbował wysłac na serwer zalezy odkonfiguracji. Od wersji 2.0 git domyslnym zachowaniem (przy brakuinnych parametrów) jest wysyłanie zmian tylko z aktywnego brancha.Branch ten musi miec ustawiony upstream i ta sama nazwe lokalnie,jak i w zdalnym repo.

Wczesniejsze wersje wysyłały zmiany do wszystkich branchy, którychnazwy lokalne pokrywały sie ze zdalnymi. Mogło prowadzic to doopublikowania niechcianych zmian, wiec zachowanie to zostałozmienione.


Wysyłanie zmian

$ cd ~/acai$ git statusOn branch masterYour branch is ahead of ’origin/master’ by 1

↪→ commit.(use "git push" to publish your local commits)

nothing to commit, working directory clean$ git --no-pager show --no-patchcommit 3c7730e1860259cd79daf925a568e36c8fca06c8Author: Maciej Wielgosz <[email protected]>Date: Thu Oct 15 20:13:30 2015 +0200

Add acai ASCII art


Wysyłanie zmian

$ git pushCounting objects: 5, done.Delta compression using up to 8 threads.Compressing objects: 100% (5/5), done.Writing objects: 100% (5/5), 1.17 KiB | 0

↪→ bytes/s, done.Total 5 (delta 2), reused 0 (delta 0)To [email protected]:maciekwielgosz/acai.git

3fe7e9e..3c7730e master -> master


Pobieranie zmian

Zmiany ze zdalnego repozytorium pobiera sie poleceniem git fetch.Aby jednak zostały one zaaplikowane (faktycznie wprowadzone wplikach), nalezy nastepnie uzyc git merge.

$ cd ~/acai-clone$ git fetchremote: Counting objects: 5, done.remote: Compressing objects: 100% (5/5), done.remote: Total 5 (delta 2), reused 0 (delta 0)Unpacking objects: 100% (5/5), done.From bitbucket.org:maciekwielgosz/acai

3fe7e9e..3c7730e master -> origin/master


Pobieranie zmian

$ git mergeUpdating 3fe7e9e..3c7730eFast-forwardacai/acai.txt | 31

↪→ +++++++++++++++++++++++++++++++acai/main.py | 13 ++++++++-----2 files changed, 39 insertions(+), 5 deletions(-)create mode 100644 acai/acai.txt


Pobieranie zmian

Czesciej uzywany jest git pull, bedacy ich połaczeniem:

$ git pullremote: Counting objects: 3, done.remote: Compressing objects: 100% (2/2), done.remote: Total 3 (delta 1), reused 0 (delta 0)Unpacking objects: 100% (3/3), done.From bitbucket.org:maciekwielgosz/acai

3c7730e..6c207ea master -> origin/masterUpdating 3c7730e..6c207eaFast-forward.env | 1 +1 file changed, 1 insertion(+)create mode 100644 .env


Mozliwosci fetch/pull

z fetch pobiera zmiany dla wszystkich branchy istniejacych nadomyslnym remote,

z domyslny remote dla polecenia fetch moze róznic sie oddomyslnego remote’a dla polecenia push,

z pull moze zostac tak skonfigurowany, by opierac swoje działaniena rebase zamiast na merge. Nalezy wtedy wziac pod uwage tesame punkty, które dotycza rebase.


Fork

ForkKopia repozytorium, zwykle stworzona w tym samym serwisie corepozytorium „centralne”. Moze posłuzyc do rozwijania odrebnej wersjiprojektu, jako sposób kontroli uprawnien uzytkowników czy tezdodatkowy poziom zabezpieczenia głównego repozytorium przedbłedami.


Kontrola dostepu

Czesto, zwłaszcza w wiekszych projektach, kazdy z pracujacychdeveloperów ma uprawnienia do pobrania zmian z głównegorepozytorium (read access), ale tylko czesc z nich moze bezposredniodokonywac w nim zmian (write access).

Kazdy z członków zespołu pracuje na swoim forku (jest to jego ’origin’),co jakis czas synchronizujac go z głównym repozytorium (remote tenprzyjeto nazywac ’upstream’). Gdy zakonczy implementowac danafunkcjonalnosc, stworzone przez niego zmiany sa zatwierdzane iwłaczane do głównego repozytorium przez kogos posiadajacegoodpowiednie uprawnienia.


Pull request

Proces zgłaszania, akceptowania (badz odrzucania) i właczania zmiando głównego repozytorium zazwyczaj odbywa sie przy pomocy tzw.pull requestów.

Pull requesty pozwalaja na łatwe przegladanie zmian, ichkomentowanie, automatyczne testy kodu czy tez prosta synchronizacjez główna wersja kodu.

W mozliwosc łatwego tworzenia forków i pull requestów wyposazonajest obecnie wiekszosc serwisów udostepniajacych usługeprzechowywania repozytoriów.


Tworzenie forka


Praca z forkiem

$ git clone [email protected]:yuijim/acai.git↪→ acai-fork

Cloning into ’acai-fork’...[...]$ cd acai-fork$ git remote add upstream

↪→ [email protected]:maciekwielgosz/acai.git$ git remoteoriginupstream$ git branch

* master


Praca z forkiem

W czasie pracy z forkiem zwykle nie robi sie zmian bezposrednio nabranchu ’master’. Ma on słuzyc jako branch referencyjny, który moznałatwo synchronizowac z głównym repozytorium (’upstream’) przedrozpoczeciem kodowania.

$ git pull upstream masterremote: Counting objects: 4, done.remote: Compressing objects: 100% (4/4), done.remote: Total 4 (delta 3), reused 0 (delta 0)Unpacking objects: 100% (4/4), done.From bitbucket.org:maciekwielgosz/acai

* branch master -> FETCH_HEAD

* [new branch] master -> upstream/master[...]


Praca z forkiem

Wszystkie zmiany wprowadzane sa na dedykowanych branchach. Wten sposób mozna pracowac nad kilkomapoprawkami/funkcjonalnosciami jednoczesnie, zawsze majac jakobaze aktualna wersje kodu z głównego repozytorium. Dzieki takiemupostepowaniu nie ma problemów, jesli np. czesc zmian zostaniezaakceptowana, a czesc odrzucona.

$ git checkout -b fix-autoenvSwitched to a new branch ’fix-autoenv’


Pull request

Gdy proponowane zmiany znajda sie juz na forku danego developera,nalezy stworzyc pull request, który nastepnie bedzie oczekiwał naakceptacje.


Pull request


Git







6 Organizacja pracy


Inne mozliwosci

Ignorowanie plikówKonfiguracja

Wiecej o komendach iopcjachDodatkowa dokumentacja


Ignorowanie plików

Plik .gitignore pozwala na ignorowanie niektórych plików i katalogów wprojekcie, np. plików wynikowych kompilacji czy automatycznych kopiizapasowych plików.

Zazwyczaj tworzy sie go w głównym katalogu projektu.

Moze on zawierac konkretne sciezki lub ogólne wzorce nazw plików.

Działa on tylko dla niesledzonych plików – pliki które zostały dodaneprzed jego stworzeniem (lub ich dodanie zostało wymuszone pomimoustawien w .gitignore) w dalszym ciagu beda sledzone.


Ignorowanie plików

1 # Filesystem helper files2 .DS_Store3

4 # Temporary and binary files5 *~6 *.py[cod]7 *.so8 *.cfg9 !setup.cfg

10 *.orig11 *.log

Fragment przykładowego .gitignore


Inne mozliwosci




Konfiguracja

Konfiguracja zachowania gita odbywa sie na trzech poziomach, zktórych kazdy nadpisuje ustawienia poprzedniego:

z systemowy – przechowywany w /etc/gitconfig, definiujezachowanie gita dla wszystkich uzytkowników,

z globalny – zwykle zapisany w $HOME/.gitconfig, definiujezachowanie dla danego uzytkownika,

z lokalny – znajduje sie w pliku .git/config w kazdym repozytorium idefiniuje specyficzne dla niego ustawienia.


Konfiguracja

Pliki konfiguracyjne sa zwyczajnymi plikami tekstowymi, które moznazmieniac w dowolnym edytorze, jednak zwykle wygodniej posłuzyc siepoleceniem git config.

Domyslnie edytuje ono ustawienia na poziomie repozytorium.

By zmienic to zachowanie stosuje sie opcje --system lub --global.


Dane uzytkownika

Jednymi z pierwszych ustawien, które powinny zostac dodane przyrozpoczynaniu pracy z gitem sa dane identyfikujace uzytkownika:

$ git config --global user.name "Maciej Wielgosz"$ git config --global user.email

↪→ [email protected]

Operacje te zazwyczaj wykonuje sie tylko raz w danym systemie.


Inne mozliwosci




Przydatne komendy

Oprócz omówionych, git dostarcza takze wielu innych komend orazopcji. Przykładowe z nich to:

z git blame – pozwala na podejrzenie kto wprowadził jakie zmiany(by miec pewnosc mozna skorzystac z podpisów elektronicznych),

z git stash – pozwala na tymczasowe zapisanie wyników pracy,z git tag – pozwala na stworzenie punktu odpowiadajacego np.

konkretnej wersji oprogramowania,z git revert – pozwala na wygodne i bezpieczne cofanie zmian,

które zostały juz opublikowane.


https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work

http://semver.org/spec/v2.0.0.html

Polecenia szczególnej ostroznosci

Uzywajac niektórych komend i opcji nalezy zachowac szczególnaostroznosc, poniewaz niewłasciwie uzyte moga doprowadzic do utratywyników pracy. Szczególnie warto uwazac przy stosowaniu:

z git reset --hard

z git checkout <filepath>

z git branch -D

z git commit --amend

z git rebase

z git push --force


Polecenia szczególnej ostroznosci

Przed czescia negatywnych skutków pomyłki moze ochronicwczesniejsze stworzenie commita, przed innymi – wykonanie „kopii”brancha. Jednak bład nie zawsze moze dac sie naprawic.

Niektórych z nich (ingerujacych w historie) nie powinno sie nigdyuzywac w odniesieniu do publicznych branchy, czy tez takich, które juzzostały gdzies dołaczone, w czesci badz całosci.


Inne mozliwosci




Dodatkowa dokumentacja i tutoriale

Dodatkowa dokumentacje dotyczaca gita mozna znalezc m.in.:

z https://git-scm.com/book/en/v2

z https://www.atlassian.com/git/tutorials

z https://training.github.com/kit/downloads/github-git-cheat-sheet.pdf

z https://try.github.io

z https://www.codecademy.com/en/courses/learn-git


https://git-scm.com/book/en/v2

https://www.atlassian.com/git/tutorials

https://training.github.com/kit/downloads/github-git-cheat-sheet.pdf

https://training.github.com/kit/downloads/github-git-cheat-sheet.pdf

https://try.github.io

https://www.codecademy.com/en/courses/learn-git

Git







6 Organizacja pracy


Git workflows

Sposób organizacji pracy z gitem w duzym stopniu zalezy odindywidualnych preferencji, potrzeb zespołu czy rozmiaru projektu.

Przed rozpoczeciem pracy warto ustalic nastepujace kwestiedotyczace pracy z VCS (i nie tylko):

z fork vs. branch – Czy współpraca ma byc oparta na forkach czyna branchach? A moze wszyscy beda pracowac na tym samymbranchu? Czy nalezy trzymac sie jakiejs konwencji przynazywaniu branchy?


Git workflows

z rebase vs. merge – W zaleznosci od wybranej formy współpracymozliwe moze byc uzywanie rebase lub merge jakopodstawowego sposobu synchronizowania branchy. Który z nichjest preferowany?

z pull requests – jesli uzywane beda pull requesty – kto jestodpowiedzialny za ich akceptacje? Czy jest to np. jeden członekzespołu czy moze wystarczy, ze zatwierdzi go dowolny innydeveloper? A moze jest to tylko formalnosc i nic nie stoi naprzeszkodzie, by zatwierdzac własne pull requesty?


Git workflows

z architektura – kto decyduje o ogólnej architekturze projektu? Ostrukturze katalogów czy organizacji modułów, uzywanychbibliotekach (zwłaszcza jesli bedzie ona potrzebna w wielumiejscach)? Czy jest konkretna osoba odpowiedzialna zastworzenie ogólnej dokumentacji projektu, zdefiniowanieargumentów linii polecen itp?

z srodowisko – Kto odpowiada za aktualizacje zaleznosci projektu?Za stworzenie instrukcji instalacji?


Przydatne linki

z https://www.atlassian.com/git/tutorials/comparing-workflows

z https://guides.github.com/introduction/flow

z https://www.atlassian.com/git/articles/git-team-workflows-merge-or-rebase

z http://nvie.com/posts/a-successful-git-branching-model


https://www.atlassian.com/git/tutorials/comparing-workflows

https://www.atlassian.com/git/tutorials/comparing-workflows

https://guides.github.com/introduction/flow

https://www.atlassian.com/git/articles/git-team-workflows-merge-or-rebase

https://www.atlassian.com/git/articles/git-team-workflows-merge-or-rebase

http://nvie.com/posts/a-successful-git-branching-model

http://nvie.com/posts/a-successful-git-branching-model

Tips & tricks

Istnieje wiele sposobów na ułatwienie sobie pracy z gitem, np.:

z konfiguracja powłoki, tak, by widoczny był aktywny branch orazjego status (bash, zsh),

z wtyczki badz wbudowane funkcje IDE, pozwalajace zapisywaczmiany czy synchronizowac repo bezposrednio w programie,

z dostosowana do osobistych preferencji konfiguracja gita, np.domyslny edytor czy aliasy komend (za inspiracje moze słuzychttp://documentup.com/skwp/git-workflows-book).


https://github.com/jimeh/git-aware-prompt

https://github.com/robbyrussell/oh-my-zsh

http://documentup.com/skwp/git-workflows-book

Mozliwosci platform

Wiele platform dostarczajacych usługi udostepniania repozytorium gitpozwala na korzystanie z dodatkowych narzedzi optymalizujacychprace zespołowa z VCS. Dostepne moga byc m.in.:

z issues – system do zgłaszania błedów, zapotrzebowania na nowefunkcjonalnosci itp., pozwalajacy na ich komentowanie, czestowyposazony w dodatkowa kategoryzacje czy tagowanie

z wiki – słuzace do tworzenia dodatkowej dokumentacji do projektu,tutoriali, opisu przykładów itp.

z continuous integration & delivery – automatyczne testywykonywane po kazdym pushu, automatyczny deployment naserwer etc.


Programowanie w jezykach skryptowych - Python i Linux...

Documents

Transcript of Programowanie w jezykach skryptowych - Python i Linux...