System kontroli wersji Git

(1)

System kontroli wersji Git

Maciej Wielgosz

Wydział Informatyki, Elektroniki i Telekomunikacji

2019, semestr zimowy

M. Wielgosz (AGH - IET) Git 2019 1 / 137

(2)

1 Systemy kontroli wersji

2 Systemy scentralizowane a rozproszone

3 Git jako system lokalny Inicjalizacja

Stany plików Zapis stanu Historia

Praca z branchami

4 Git jako system rozproszony

Zdalne repozytorium

Podstawowa synchronizacja Model pracy oparty o wiele repozytoriów

5 Inne mo˙zliwo´sci Ignorowanie plików Konfiguracja

Wi ˛ecej o komendach i opcjach

Dodatkowa dokumentacja

6 Organizacja pracy

(3)

VCS

System kontroli wersji (ang. Version Control System)

Program słu˙z ˛acy do ´sledzenia zmian w kodzie/dokumencie ´zródłowym oraz ułatwiaj ˛acy ł ˛aczenie modyfikacji pochodz ˛acych z wielu ´zródeł.

Obecnie VCS stały si ˛e standardem przy pracy nad ró˙znego typu projektami informatycznymi, ale za VCS mo˙zna uzna´c tak˙ze np.

´sledzenie zmian w systemach typu Wiki czy pakietach biurowych.

(4)

Dlaczego warto u˙zywa´c VCS?

Do najwa˙zniejszych zalet VCS mo˙zna zaliczy´c:

z proste przegl ˛adanie i przywracanie poprzednich wersji plików, z łatwo´s´c synchronizacji ´zródeł pomi ˛edzy ró˙znymi maszynami i

członkami zespołu,

z mo˙zliwo´s´c rozwijania projektu w wielu kierunkach jednocze´snie (np. naprawianie bł ˛edów z ostatniej wersji przy równoczesnej pracy nad now ˛a funkcjonalno´sci ˛a),

z opcje integracji z automatycznymi narz ˛edziami do np. testowania czy deploymentu.

(5)

Popularne systemy

W chwili obecnej najcz ˛e´sciej mo˙zna spotka´c si ˛e z nast ˛epuj ˛acymi systemami:

z Apache Subversion (SVN) – stworzony w roku 2000 jako (w wi ˛ekszo´sci kompatybilny) nast ˛epca Concurrent Version System (CVS),

z Mercurial (Hg) – pojawił si ˛e w roku 2005; jego zamierzonym pierwotnym zastosowaniem była praca nad rozwojem j ˛adra Linuksa, 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.

(6)

Praca z branchami

Zdalne repozytorium

6 Organizacja pracy

(7)

Systemy lokalne

z Proste bazy danych, która przechowuj ˛a wszystkie zmiany w plikach jako kolejne wersje,

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

z systemy te działaj ˛a na zasadzie przechowywania ró˙znic pomi ˛edzy plikami tzw. patchy,

z mo˙zna odtworzy´c jak plik wygl ˛adał w dowolnym momencie czasu poprzez zsumowanie wszystkich patchy.

(8)

Systemy scentralizowane

z Systemy scentralizowane powstały z potrzeby współdzielenia kodu pomi ˛edzy ró˙znymi developerami i maszynami,

z oparte s ˛a na idei głównego serwera przechowuj ˛acego cał ˛a histori ˛e i dowolnej ilo´sci klientów, którzy kopiuj ˛a z centralnego serwera pliki,

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

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

(9)

Zalety i wady systemów scentralizowanych

Zalety (w stosunku do systemów lokalnych):

z ka˙zdy do pewnego stopnia orientuje si ˛e, co robi ˛a inni członkowie zespołu,

z szczegółowa kontrola uprawnie ´n u˙zytkowników,

z łatwiejsze zarz ˛adzanie (łatwiej zarz ˛adza´c jednym repozytorium ni˙z wieloma lokalnymi).

(10)

Zalety i wady systemów scentralizowanych

Wady:

z niedost ˛epno´s´c centralnego repozytorium powoduje parali˙z pracy całego zespołu, ze wzgl ˛edu na brak komunikacji z baz ˛a danych, z awaria centralnego serwera powoduje utrat ˛e całej historii pracy

(chyba ˙ze były tworzone kopie zapasowe).

(11)

Systemy rozproszone

Zasada działania

Systemy rozproszone przechowuj ˛a lokalnie cał ˛a histori ˛e zmian, co pozwala u˙zytkownikowi na prac ˛e niezale˙znie od dost ˛epno´sci innych w ˛ezłów.

(12)

Zalety systemów rozproszonych

Zalety:

z ka˙zda kopia repozytorium słu˙zy jednocze´snie jako kompletne repozytorium,

z istnieje mo˙zliwo´s´c u˙zywania kilku zdalnych („centralnych”) serwerów,

z taka architektura umo˙zliwia stosowanie wielu modeli organizacji pracy,

z obecnie najpopularniejszym przykładem systemu rozproszonego jest git.

(13)

Podsumowanie

Systemy scentralizowane s ˛a tworzone z zało˙zeniem, ˙ze istnieje jedno wła´sciwe (absolutne) ´zródło.

Systemy rozproszone:

z zostały stworzone z zało˙zeniem, ˙ze ka˙zde repozytorium jest tak samo dobre jak inne,

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

indywidualnie i nie jest kontrolowana przez oprogramowanie.

(14)

Praca z branchami

Zdalne repozytorium

6 Organizacja pracy

(15)

Git jako system lokalny

Główn ˛a zalet ˛a systemów rozproszonych jest ich autonomiczno´s´c:

z aby z nich korzysta´c, nie jest potrzebny ˙zaden serwer,

z w podstawowej wersji wszystko mo˙ze odbywa´c si ˛e tak, jak przy stosowaniu najprostszego lokalnego systemu.

(16)

Git CLI

Programgitdziała na zasadzie komend (podprogramów), z których niemal ka˙zda ma odr ˛ebny zestaw argumentów.

List ˛e wspólnych opcji oraz najcz ˛e´sciej u˙zywanych komend mo˙zna zobaczy´c wpisuj ˛ac:

$ git --help

Szczegółowe opcje poszczególnych komend mo˙zna zobaczy´c u˙zywaj ˛ac:

$ git <command> --help

(17)

Git jako system lokalny

Inicjalizacja Stany plików

Zapis stanu Historia

Praca z branchami

(18)

Nowe repozytorium

Zało˙zenie nowego, lokalnego repozytorium w wybranym katalogu (mog ˛a wcze´sniej istnie´c w nim jakie´s pliki; w przykładach u˙zywany b ˛edzie katalog acai):

$ cd acai

$ git init

Initialized empty Git repository in ,→ /[...]/acai/.git/

(19)

Dodanie istniej ˛ acych plików

Stworzone w ten sposób repozytorium nie ´sledzi jeszcze ˙zadnych zmian w plikach. Aby rozpocz ˛a´c kontrolowanie wersji dla ju˙z

istniej ˛acych w katalogu plików nale˙zy wyda´c dwa polecenia. Pierwsze z nich to:

$ git add .

Powoduje ono dodanie do kontroli wersji wszystkich plików z bie˙z ˛acego (.) katalogu. Co dokładnie zostało dodane mo˙zna sprawdzi´c wydaj ˛ac poleceniegit status.

(20)

Dodanie istniej ˛ acych plików

$ git status On branch master Initial commit

Changes to be committed:

(use "git rm --cached <file>..." to unstage)

new file: .gitignore new file: LICENSE.txt new file: README.md ...

(21)

Pierwszy commit

Druga komenda instruuje gita, aby „zapami ˛etał ten punkt w historii”. W wersji podstawowej wygl ˛ada ono tak:

$ git commit

Po wykonaniu polecenia otwierany jest domy´slnie skonfigurowany edytor tekstowy w którym nale˙zy poda´c opis wła´snie tworzonego

„punktu”.

Standardowo opis tenmusi zosta´c dodany – w przeciwnym razie tworzenie punktu zostanie anulowane.

(22)

Pierwszy commit

Cz ˛esto opis (wiadomo´s´c, ang. message) podaje si ˛e bezpo´srednio z linii polece ´n:

$ git commit -m "Project skeleton"

[master (root-commit) 6048090] Project skeleton 19 files changed, 718 insertions(+)

create mode 100644 .gitignore create mode 100644 LICENSE.txt create mode 100644 README.md ...

(23)

Pełna inicjalizacja

Podsumowuj ˛ac, rozpocz ˛ecie lokalnej pracy z gitem najcz ˛e´sciej przebiega nast ˛epuj ˛aco:

$ cd <project_dir>

$ git init ...

$ git add .

$ git commit -m "Initial commit"

...

(24)

Git jako system lokalny

Praca z branchami

(25)

Mo˙zliwe stany plików

Pliki w gicie mog ˛a znajdowa´c si ˛e w jednym z 2 stanów:

z nie´sledzone (ang. untracked ) – pliki, których stanu git nie przechowuje

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

Aby plik był ´sledzony, nale˙zy go doda´c do gita, np. u˙zywaj ˛ac polecenia git add.

Usuni ˛ecie pliku z listy ´sledzonych (i z dysku!) po stworzeniu commita odbywa si ˛e za pomoc ˛agit rm.

(26)

Sledzenie zmian ´

Sledzone pliki mog ˛´ a by´c:

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

z zmodyfikowane (ang. modified ) – takie, w których s ˛a wprowadzone jakie´s zmiany

(27)

Sledzenie zmian ´

Ka˙zdy zmodyfikowany plik zawiera jedn ˛a lub wi ˛ecej zmian. Warto pami ˛eta´c, ˙ze git ma mo˙zliwo´s´c zapisu stanu ka˙zdej zmiany z osobna.

Ka˙zda zmiana mo˙ze by´c zatwierdzona (w nomenklaturze gita staged ) lub nie. Zwykle jednak nie rozpatruje si ˛e ka˙zdej zmiany pojedynczo, tylko zatwierdza wszystkie w danym pliku.

To, na jakim etapie „cyklu ˙zycia” jest dana zmiana mo˙zna podejrze´c u˙zywaj ˛ac komendygit status.

(28)

Status pliku

$ git status On branch master

Changes 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.txt modified: README.md

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

(29)

Zatwierdzenie zmian

Zatwierdzenie (wszystkich) zmian w danych plikach odbywa si ˛e przy u˙zyciu poleceniagit add:

$ git add LICENSE.txt README.md

Changes to be committed:

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

modified: LICENSE.txt modified: README.md

(30)

Zatwierdzenie zmian

Do zatwierdzenie wszystkich zmian we wszystkich zmodyfikowanych plikach, a tak˙ze dodania do kontroli wersji nowych (i usuni ˛ecia z niej ju˙z nieistniej ˛acych), przydatna jest opcja-A:

$ git add -A

Oznacza ona w skrócie „zatwierd´z wszystko”.

(31)

Wycofanie zmian

Je´sli która´s z zatwierdzonych zmian jednak nie powinna zostać zapisana, mo˙zna u˙zyćgit reset, aby j ˛a wycofać:

$ git reset README.md

Unstaged changes after reset:

M README.md

Polecenie to (w tej formie) nie powoduje ˙zadnych zmian w pliku – informuje tylko gita, ˙ze dana zmiana (zmiany) maj ˛a jeszcze nie by´c zapisywane.

(32)

Podejrzenie zmian

Do podgl ˛adania, co zostało zmienione od ostatniego zapisu stanu (ogólnie lub w danym pliku) słu˙zy poleceniegit diff:

$ git diff README.md

Otworzy ono edytor, w którym zaznaczone b ˛ed ˛a miejsca wyst ˛apienia zmian.

W najprostszym przypadku lista ró˙znic b ˛edzie miała posta´c pliku tekstowego, zawieraj ˛acego informacje o tym, które linie i w jakich plikach zostały zmienione.

(33)

git diff

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

2 index e69de29..1edb8e1 100644

3 --- a/README.md

4 +++ b/README.md

5 @@ -0,0 +1,3 @@

6 +ACAI - ACcelerated AI

7 +

8 +Suite of Artificial Intelligence algorithms ,→ implemented with future hardware

,→ acceleration (via OpenCL) in mind.

git diff README.md

(34)

Podwójny status pliku

Czasami mo˙ze zdarzy´c si ˛e, ˙ze plik znajduje si ˛e zarówno na li´scie zmian zatwierdzonych do zapisu (staged ), jak i na li´scie zmian jeszcze nie zatwierdzonych (unstaged ).

Wynika to ze wspomnianego wcze´sniej ´sledzenia pojedynczych zmian – je´sli zatwierdzony był cały plik, to tak naprawd ˛e zatwierdzone były wszystkie zmiany znajduj ˛ace si ˛e w nim w danym momencie.

Je´sli uległ on dalszej modyfikacji (nawet nadpisuj ˛acej zatwierdzone zmiany), to nowe modyfikacje równie˙z trzeba zatwierdzi´c, by mogły by´c zapisane.

(35)

Git jako system lokalny

Praca z branchami

(36)

Komenda commit

Zatwierdzone zmiany zapami ˛etuje si ˛e u˙zywaj ˛ac polecenia

git commit. Tworzy ono opisany punkt na osi czasu, do którego mo˙zna powraca´c.

Ka˙zdy commit identyfikowany jest przez unikalny hash, automatycznie generowany na podstawie danych takich jak bie˙z ˛acy czas, autor commita czy wprowadzony opis.

Hash ten pozwala stwierdzi´c, czy dwa commity posiadaj ˛ace ten sam opis faktycznie s ˛a takie same.

Wiele polece ´n gita przyjmuje hash jako jeden ze swoich argumentów.

Cały identyfikator jest jednak kłopotliwy w u˙zyciu (SHA1 generuje ci ˛agi o długo´sci 40 znaków), wi ˛ec cz ˛esto stosuje si ˛e tylko 7 pierwszych jego znaków.

(37)

Always commit, you must

Stworzony commit zabezpiecza przed utrat ˛a wyników pracy.

Cz ˛esto okazuje si ˛e, ˙ze poprzednie rozwi ˛azanie było tym wła´sciwym...

Je˙zeli zapisany został tylko stan po wszystkich poprawkach, nie ma jak podejrzeć i/lub wykorzystać w tym celu pierwotnego rozwi ˛azania – trzeba napisać je od nowa.

(38)

Always commit, you must

Je˙zeli natomiast stan był zapisywany po ka˙zdym etapie pracy, to z łatwo´sci ˛a mo˙zna przywróci´c plik do poprzedniego stanu – czy to w celu zast ˛apienia obecnej wersji, czy tylko „podejrzenia” i ekstrakcji potrzebnych fragmentów.

Miedzy innymi z tego powodu warto jest wyrobi´c sobie nawyk

tworzenia cz ˛estych i dobrze opisanych commitów. Przyda si ˛e to tak˙ze w pó´zniejszej, zespołowej pracy z gitem – a czasami mo˙ze okaza´c si ˛e jedyn ˛a desk ˛a ratunku w przypadku wyst ˛apienia jakich´s problemów.

(39)

Podstawowe u˙zycie

$ git commit

Uruchomienie powy˙zszej komendy otworzy domy´slny edytor (vim), w którym nale˙zy wprowadzi´c opis. Standardowo plik ten zawiera komentarz, dostarczaj ˛acy dodatkowych informacji o tworzonym wła´snie commicie.

(40)

Podstawowe u˙zycie

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 master

5 # Changes to be committed:

6 # modified: LICENSE.txt

7 #

8 # Changes not staged for commit:

9 # modified: README.md

10 #

Domy´slna zawarto´s´c pliku z opisem

(41)

Podstawowe u˙zycie

Domy´slnie, je´sli nie wpiszemy tre´sci opisu, commit zostanie anulowany:

Aborting commit due to empty commit message.

(42)

Opis z linii polece ´n

Cz ˛esto u˙zywa si ˛e parametru-m, aby wprowadzi´c opis bezpo´srednio z linii polece ´n:

$ git commit -m "Change license to MIT"

[master 3278ed2] Change license to MIT

1 file changed, 21 insertions(+), 1 deletion(-) rewrite LICENSE.txt (100%)

(43)

Zatwierdzenie wszystkich zmian przy zapisie

Aby nie dodawa´c r ˛ecznie zmian w ka˙zdym ´sledzonym ju˙z pliku, mo˙zna u˙zy´c opcji-a:

$ git commit -a -m "Add basic repo description"

[master fc13f88] Add basic repo description 1 file changed, 3 insertions(+)

Opcja ta dotyczy tylkoju˙z ´sledzonych plików. Je˙zeli w repo zostały stworzone nowe, nale˙zy doda´c je „normalnie”, u˙zywaj ˛ac np.

git add -A.

(44)

Edycja commita

Zdarza si ˛e, ˙ze przy tworzeniu commita nast ˛apiła pomyłka, np.

literówka w opisie czy pomini ˛ety plik. Z pomoc ˛a przychodzi wtedy opcja--amend, pozwalaj ˛aca na łatw ˛a edycj ˛e ostatniego commita:

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

[master bb3823f] Add basic project description Date: Wed Oct 14 13:45:38 2015 +0200

1 file changed, 3 insertions(+)

(45)

Edycja commita

To, co tak naprawd ˛e git robi, to usuwa ostatni commit i w jego miejsce tworzy nowy, zawieraj ˛acy wszystkie zmiany z tego usuni ˛etego oraz nowo zatwierdzone. Mo˙zna to zaobserwowa´c porównuj ˛ac ich identyfikatory.

W wyniku edycji powstaje nowy commit. Nie ma to wielkiego znaczenia w przypadku lokalnego u˙zycia gita, jest jednak wa˙zne przy bardziej zaawansowanych zastosowaniach.

(46)

Git jako system lokalny

Praca z branchami

(47)

Ostatni commit

Opis i zmiany zapisane w ostatnim commicie mo˙zna zobaczy´c

korzystaj ˛ac z poleceniagit show. Analogicznie jakgit diffotworzy ono edytor z plikiem zawieraj ˛acym list ˛e zmian i dodatkowo

informacjami o commicie:

1 commit bb3823f63f1254108238951a60b319fcc3a1b1a7

2 Author: Maciej Wielgosz <wielgosz@agh.edu.pl>

3 Date: Wed Oct 14 13:45:38 2015 +0200

4

5 Add basic project description

6

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

(48)

Ostatni commit

8 index e69de29..8dd37ac 100644

9 --- a/README.md

10 +++ b/README.md

11 @@ -0,0 +1,3 @@

12 +ACAI - ACcellerated AI

13 +

14 +Suite of Artificial Intelligence algorithms ,→ implemented with future hardware

,→ acceleration (via OpenCL) in mind.

git show

(49)

Przegl ˛ ad historii

Skrócon ˛a histori ˛e commitów mo˙zna przegl ˛ada´c przy u˙zyciu polecenia git log. B ˛edzie ona otworzona w domy´slnym edytorze.

1 commit bb3823f63f1254108238951a60b319fcc3a1b1a7

3 Date: Wed Oct 14 13:45:38 2015 +0200

4

5 Add basic project description

6

7 commit 3278ed255627fa64ede6ab587e0d2c8c2711d203

9 Date: Wed Oct 14 13:23:57 2015 +0200

10

11 Change license to MIT

(50)

Przegl ˛ ad historii

13 commit 6048090a0ce0997025957d5fd88224d9582aaa0a

15 Date: Mon Oct 12 22:28:43 2015 +0200

16

17 Project skeleton

git log

Pełn ˛a informacj ˛e o zmianach mo˙zna wy´swietli´c podaj ˛ac argument w postaci hasha do poleceniagit show, np. git show 3278ed2.

(51)

Historyczne wersje pliku

Aby zobaczyć, jak wygl ˛adał dany plik w konkretnym punkcie historii lub przywrócić go do tego stanu, mo˙zna u˙zyć komendygit checkout podaj ˛ac hash interesuj ˛acego commita i ´scie˙zk˛e do pliku.

$ git checkout 6048090 LICENSE.txt

Przywrócenie go do bie˙z ˛acej wersji (z najnowszego commita) odbywa si ˛e analogicznie (HEADodpowiada ostatniemu commitowi):

$ git checkout HEAD LICENSE.txt

(52)

Historyczne wersje pliku

Dost ˛epne s ˛a równie˙z pewne skróty, np.

$ git checkout HEAD~2 LICENSE.txt

cofa plik LICENSE.txt o 2 wersje.

Nale˙zy zauwa˙zyć, ˙ze wynikiem poleceniagit checkoutnie jest tylko podgl ˛ad – dokonywane s ˛a faktyczne zmiany w pliku, które w razie potrzeby mo˙zna zatwierdzić i zapisać.

(53)

Podgl ˛ ad historycznej wersji pliku

Je˙zeli po˙z ˛adany jest tylko podgl ˛ad, bez wprowadzania zmian do pliku, mo˙zna skorzysta´c z wariantu poleceniagit show:

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

Jako separatora pomi ˛edzy identyfikatorem wersji, a ´scie˙zk ˛a do pliku u˙zywa si ˛e:(bez spacji!).

(54)

Znacz ˛ ace opisy

Dobre opisy commitów znacz ˛aco ułatwiaj ˛a prace z histori ˛a zmian.

Mog ˛a pomóc znacznie zaw ˛ezi´c przeszukiwany przedział czasu w przypadku np. pojawienia si ˛e nowych bł ˛edów czy ułatwi´c znalezienie konkretnej wersji pliku.

Czytelne opisy s ˛a istotne zwłaszcza w przypadku pracy w grupie oraz korzystania z narz ˛edzi automatycznie generuj ˛acych list ˛e zmian (changelog) w projekcie.

(55)

Git jako system lokalny

Inicjalizacja Stany plików Zapis stanu Historia

Praca z branchami

Tworzenie Ł ˛aczenie Konflikty Usuwanie Rebase

(56)

Branch

Odgał ˛ezienie projektu, zwykle wydzielone w celu realizacji konkretnej funkcjonalno´sci.

Wszystkie repozytoria git maj ˛a domy´slny, główny branch o nazwie

’master’. Zwykle stanowi on baz ˛e, na podstawie której tworzy si ˛e inne branche.

(57)

Istniej ˛ ace branche

Sprawdzenie, jakie branche istniej ˛a w projekcie odbywa si ˛e za pomoc ˛a poleceniagit branch.

$ git branch

* master

W momencie stworzenia nowego repozytorium branch ’master’ nie jest widoczny na li´scie branchy – pojawia si ˛e on tam dopiero po pierwszym commicie.

Aktywny branch (czyli ten, do którego „przynale˙z ˛a” wersje plików znajduj ˛ace si ˛e obecnie na dysku) oznaczony jest_*. W danej chwili aktywny mo˙ze by´c tylko jeden branch.

(58)

Tworzenie

Jednym ze sposobów stworzenia nowego brancha jest:

git branch <branch_name>

Polecenie to tworzy nowy branch, ale go nie aktywuje. Aby zacz ˛a´c prac ˛e nale˙zy si ˛e na niego przeł ˛aczy´c:

git checkout <branch_name>

Jest to standardowy sposób przeł ˛aczania si ˛e mi ˛edzy branchami.

(59)

Tworzenie

Wygodniejszym sposobem jest stworzenie nowego brancha równocze´snie z jego aktywacj ˛a, przy u˙zyciu opcji-b:

$ git checkout -b documentation

Switched to a new branch ’documentation’

Nowo stworzony branch domy´slnie pocz ˛atkowo znajduje si ˛e w tym samym punkcie, co obecnie aktywny. Mo˙zna tak˙ze poda´c, który branch ma stanowi´c „baz ˛e” nowo tworzonego:

$ git checkout -b docs master Switched to a new branch ’docs’

(60)

Merge

Po zako ńczeniu pracy nad dan ˛a funkcjonalno´sci ˛a i jej przetestowaniu przychodzi czas na wł ˛aczenie jej do głównego brancha. Jednym ze sposobów, by to zrobić, jest u˙zycie poleceniagit merge. Aby poł ˛aczyć branche za jego pomoc ˛a, nale˙zy najpierw przeł ˛aczyć si ˛e na docelowy branch (zwykle ’master’).

$ git checkout master

Switched to branch ’master’

$ git merge docs

Updating 0903642..48e8690 Fast-forward

README.md | 5 +++++

1 file changed, 5 insertions(+)

(61)

Merge

master

merge 'docs' docs

docs

documentation

(62)

Konflikty

Nie zawsze merge przebiega bez problemów. Je´sli dany plik został zmieniony zarówno w branchu, który chcemy doł ˛aczy´c, jak i w branchu docelowym, mog ˛a pojawi´c si ˛e konflikty, z którymi git nie poradzi sobie automatycznie.

$ git checkout documentation

Switched to branch ’documentation’

$ git merge docs

Auto-merging README.md

CONFLICT (content): Merge conflict in README.md Automatic merge failed; fix conflicts and then

,→ commit the result.

(63)

Konflikty

W takim wypadku dost ˛epne s ˛a dwie opcje post ˛epowania:

1 anulowanie operacji:

$ git merge --abort

2 manualne rozwi ˛azanie konfliktów i stworzenie commita ł ˛acz ˛acego konfliktowe zmiany w po˙z ˛adany sposób. Wykorzystywane w tym celu s ˛a poleceniagit addigit commit.

(64)

Rozwi ˛ azywanie konfliktów

Git dodaje do pliku charakterystyczne znaczniki w miejscach, w których nast ˛apił konflikt:

1 ACAI - ACcellerated AI

2 ======================

3

4 <<<<<<< HEAD

5 Lorem ipsum dolor sit amet, consectetur [...]

6 =======

7 Suite of Artificial Intelligence algorithms [...]

12 >>>>>>> docs

Plik README.md z konfliktami

(65)

Rozwi ˛ azywanie konfliktów

Przy wyst ˛apieniu konfliktu jako pierwsze wy´swietlane s ˛a zmiany, które były zapisane na aktywnym branchu. Nast ˛epnie (po=======)

wy´swietlane s ˛a zmiany, które pochodz ˛a z doł ˛aczanego brancha.

Rozwi ˛azywanie konfliktów polega na wyszukania wszystkich wyst ˛apie ´n takich alternatyw i zast ˛apieniu ich (ł ˛acznie z markerami ograniczaj ˛acymi) po˙z ˛adan ˛a zawarto´sci ˛a.

(66)

Rozwi ˛ azywanie konfliktów

1 ACAI - ACcellerated AI

2 ======================

3

4 Suite of Artificial Intelligence algorithms [...]

5

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

7

8 ## Idea

9

10 [...]

README.md z rozwi ˛azanymi konfliktami

(67)

Rozwi ˛ azywanie konfliktów

Rozwi ˛azanie konfliktu oznaczamy u˙zywaj ˛acgit add.

$ git add README.md

Je´sli wszystkie konflikty zostały rozwi ˛azane, to mo˙zna zako ´nczy´c merge:

$ git commit

[documentation 33693fc] Merge branch ’docs’ into ,→ documentation

(68)

Rozwi ˛ azywanie konfliktów

master

merge 'docs' into 'documentation'

docs

documentation master

docs

documentation

merge commi

t

(69)

Usuwanie

Je´sli chcemy usun ˛a´c jaki´s branch, nie mo˙ze on by´c aktywny.

Aby usun ˛a´c branch, który został doł ˛aczony do bie˙z ˛acego („bezpieczne usuni ˛ecie”), u˙zywa si ˛e opcji-d:

$ git branch -d docs

Deleted branch docs (was 48e8690).

(70)

Usuwanie

Aby usun ˛a´c branch, który ju˙z nie jest potrzebny, a nie jest doł ˛aczony do bie˙z ˛acego (np. w mi ˛edzyczasie powstała zupełnie inna koncepcja rozwi ˛azania danego problemu), nale˙zy skorzysta´c z opcji-D(-d zwróci bł ˛ad):

$ git branch -d documentation

error: The branch ’documentation’ is not fully ,→ merged.

If you are sure you want to delete it, run ’git ,→ branch -D documentation’.

$ git branch -D documentation

Deleted branch documentation (was 33693fc).

(71)

Rebase

Alternatywnym podej´sciem do scalania zmian jest stosowanie komendygit rebase.

Jej działanie polega na edycji kolejno´sci commitów (a co za tym idzie, na edycji zawarto´sci samych commitów) tak, by commity z brancha podlegaj ˛acego operacji rebase wydawały si ˛e stworzone

chronologicznie po wszystkich commitach brancha bazowego.

Pozwala to na pó´zniejsze bezkonfliktowe zastosowanie polecenia git merge.

(72)

Rebase

Załó˙zmy, ˙ze przed merge brancha ’docs’ został na bazie brancha

’master’ stworzony branch ’setup’. Porównanie historii commitów w branchach ’master’ i ’setup’ pozwala stwierdzi´c, ˙ze ró˙zni ˛a si ˛e one jednym commitem.

$ git checkout setup

Switched to branch ’setup’

$ git log

(73)

Rebase

1 commit 8e4bd6bf762a577795c42a33fb5ca27f9d2d43d7

3 Date: Wed Oct 14 22:28:05 2015 +0200

4

5 Correctly configure console entry point

6

7 commit 0903642a4b1118f7a75e10dad7f8271d2d28e4ed

9 [...]

git log dla brancha ’setup’

(74)

Rebase

1 commit 48e8690b2f7019dfc811bcc6f88e6d197198f796

3 Date: Wed Oct 14 19:42:20 2015 +0200

4

5 Added some formatting & idea description

6

9 [...]

git log dla brancha ’master’

(75)

Rebase

Chcieliby´smy, by docelowa kolejno´s´c commitów w branchu master zawierała najpierw commit48e8690, a nast ˛epnie8e4bd6b– bez

˙zadnych dodatkowych commitów wynikaj ˛acych z merge (tzw. merge fast-forward).

(76)

Rebase

master master

setup

desired state

(77)

Rebase

Oznacza to, ˙ze przed wł ˛aczeniem brancha ’setup’ do ’master’ musimy zawrze´c wszystkie commity z ’master’ (b ˛ed ˛acego baz ˛a) w ’setup’.

Innymi słowy: ustali´c now ˛a baz ˛e dla ’setup’ (branch ’setup’ musi by´c aktywny):

$ git rebase master

First, rewinding head to replay your work on top ,→ of it...

Applying: Correctly configure console entry point

(78)

Rebase

master master

setup

setup rebase 'setup' to 'master'

(79)

Rebase

Po rebase historia brancha ’setup’ wygl ˛ada nast ˛epuj ˛aco:

1 commit 3fe7e9e09628669e39f17c8cef6e4031326b4223

3 Date: Wed Oct 14 22:28:05 2015 +0200

4

5 Correctly configure console entry point

6

7 commit 48e8690b2f7019dfc811bcc6f88e6d197198f796

(80)

Rebase

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

10

11 Added some formatting & idea description

12

15 [...]

git log dla brancha ’setup’ po rebase

Warto zwróci´c uwag ˛e na identyfikatory commitów – nawet w

przypadku braku konfliktów (które rozwi ˛azuje si ˛e analogicznie jak przy u˙zyciu merge) git tak naprawd ˛ezast ˛epuje wszystkie unikatowe commity stworzone w branchu podlegaj ˛acemu rebase nowymi.

(81)

Rebase

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

$ git merge setup

Updating 48e8690..3fe7e9e Fast-forward

acai/main.py | 2 +-

setup.cfg | 11 ++++---

2 files changed, 5 insertions(+), 8 deletions(-)

(82)

U˙zywanie rebase

Zalety:

z bardziej przejrzysta historia (unika si ˛e potencjalnie sporej ilo´sci

„merge commitów”),

z poniewa˙z rebase de facto tworzy nowe commity, mo˙ze on zosta´c wykorzystany do uporz ˛adkowania historii brancha podlegaj ˛acego tej operacji (np. edycja starych opisów, ł ˛aczenie i rozdzielanie commitów). Aby skorzysta´c z tej mo˙zliwo´sci u˙zywa si ˛e trybu interaktywnego (git rebase -i <base_branch>).

(83)

U˙zywanie rebase

Wady i niebezpiecze ´nstwa:

z w przeciwie ´nstwie do merge, rebase jest potencjalnie

destrukcyjn ˛a operacj ˛a. Oznacza to, ˙ze w razie pomyłki mo˙zna zaprzepa´sci´c wyniki pracy,

z nigdy nie powinno si ˛e u˙zywa´c rebase na tzw. publicznych branchach – czyli takich, których w jakim´s celu u˙zywa te˙z kto´s inny (albo na podstawie którego powstały inne branche). Z punktu widzenia gita commity przepisane po rebase i oryginalne commity to dwie zupełnie ró˙zne rzeczy (nawet je´sli prowadz ˛a do tego samego rezultatu). W efekcie próba poł ˛aczenia oryginalnych i

„nowych” zmian wygeneruje ogromn ˛a ilo´s´c konfliktów.

(84)

U˙zywanie rebase

Przydatne uwagi:

z nigdy nie powinno si ˛e przeprowadza´c operacji rebase na branchu

’master’,

z przed nieudanym rebase mo˙zna si ˛e w pewnym stopniu zabezpieczy´c, tworz ˛ac tymczasowy branch:

$ git checkout feature-branch

$ git checkout -b temporary-branch

$ git rebase -i master

$ git merge temporary-branch

(85)

Praca z branchami

Zdalne repozytorium

6 Organizacja pracy

(86)

Git jako system rozproszony

Zdalne repozytorium

Podstawowa synchronizacja

Model pracy oparty o wiele repozytoriów

(87)

Zdalne repozytorium

W wi ˛ekszo´sci zastosowa ´n jedno z repozytoriów dost ˛epne dla całego zespołu słu˙zy jako repozytorium centralne, analogicznie jak w systemach scentralizowanych.

Repozytorium takie zwykle tworzone jest zanim zacznie si ˛e jakakolwiek praca na kodem lub tu˙z po stworzeniu minimalnego szkieletu projektu. Pozwala to na zminimalizowanie pó´zniejszego konfigurowania lokalnych kopii.

(88)

Remote

Repozytorium, najcz ˛e´sciej zdalne, które jest powi ˛azane z dan ˛a instancj ˛a repo (nie musi by´c to repozytorium centralne, mo˙ze to by´c np. kopia na maszynie innego developera).

Przyj ˛eło si ˛e, ˙ze domy´slny remote dla danego repozytorium nosi nazw ˛e

’origin’.

(89)

Ustawienie remote w istniej ˛ acym repo

Aby doda´c remote do istniej ˛acego repo (przykładowo, gdy cała praca odbywała si ˛e lokalnie, a teraz została podj ˛eta decyzja o upublicznieniu wyników) nale˙zy posłu˙zy´c si ˛e wariantem komendygit remote:

$ git remote add origin

,→ git@bitbucket.org:maciekwielgosz/acai.git

Aby zobaczy´c dost ˛epne remote’y wraz z ich URLami, mo˙zna u˙zy´c:

$ git remote -v

origin git@bitbucket.org:maciekwielgosz/acai.git ,→ (fetch)

origin git@bitbucket.org:maciekwielgosz/acai.git ,→ (push)

(90)

Ustawienie remote w istniej ˛ acym repo

Samo dodanie remote jednak nie wystarczy. Dla wygody u˙zytkowania powinno si ˛e tak˙ze ustawi´c dodany wła´snie remote jako domy´slny przy

˙z ˛adaniu synchronizacji pomi ˛edzy repozytoriami (tzw. upstream). W przeciwnym razie b ˛edzie trzeba go podawa´c przy ka˙zdym tego typu

˙z ˛adaniu.

Dalsze post ˛epowanie zale˙zy od tego, czy zdalne repozytorium (’origin’) zawiera ju˙z jakie´s dane, czy te˙z jest puste.

(91)

Puste zdalne repozytorium

Je´sli u˙zyte ma być puste repozytorium, to pierwsz ˛a czynno´sci ˛a po dodaniu remote do istniej ˛acego projektu powinno być powielenie istniej ˛acej lokalnej struktury w zdalnym repozytorium. Równocze´snie w trakcie tej operacji mo˙zna ustawić nowy remote jako domy´slny do synchronizacji dla istniej ˛acych branchy (opcja-ulub

--set-upstream).

(92)

Puste zdalne repozytorium

Wysłanie (push) na remote ’origin’ wszystkich (--all) istniej ˛acych lokalnie branchy:

$ git push -u origin --all Counting 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 git@bitbucket.org:maciekwielgosz/acai.git

* [new branch] master -> master

Branch master set up to track remote branch ,→ master from origin.

(93)

Zdalne repozytorium z zawarto´sci ˛ a

Je´sli w zdalnym repozytorium ju˙z istnieje branch, który ma by´c ustawiony jako domy´slny przy synchronizacji, mo˙zna zastosowa´c to samo polecenie (wysłanie lokalnych zmian z równoczesnym

zapami ˛etaniem remote):

$ git push -u origin master

(94)

Zdalne repozytorium z zawarto´sci ˛ a

Alternatyw ˛a jest skorzystanie z wariantu poleceniagit branch(nie dokonuje ono równocze´snie synchronizacji):

$ git branch -u origin/master

Warto zwróci´c uwag ˛e na ró˙znic ˛e w składni powy˙zszych polece ´n.

git branchprzyjmuje jako argument tylko nazw ˛e brancha (origin/mastertraktowane jest jako cało´s´c). Pozwala ono na

ustawienie jako upstream zdalnego brancha o nazwie innej ni˙z lokalna, podczas gdy przy u˙zyciupushnazwy musz ˛a si ˛e zgadza´c.

(95)

Klonowanie

Je˙zeli chcemy dopiero zacz ˛a´c prac ˛e z repo, które ju˙z gdzie´s zdalnie istnieje, najprostszym sposobem jest u˙zyciegit clone.

Pobierze ono automatycznie wszystkie istniej ˛ace branche, pozwalaj ˛ac na natychmiastowe rozpocz ˛ecie pracy (b ˛ed ˛a one domy´slnie

skonfigurowane, by pobiera´c i wysyła´c zmiany na ’origin’, czyli repo, z którego sklonowano instancj ˛e).

(96)

Klonowanie

$ git clone

,→ git@bitbucket.org: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 nazw ˛e lokalnego katalogu na acai-clone.

(97)

Git jako system rozproszony

Zdalne repozytorium

(98)

Wysyłanie zmian

Zmiany wysyłane s ˛a do zdalnego repo przy u˙zyciu znanego ju˙z git push.

To, jakie branche git b ˛edzie próbował wysła´c na serwer zale˙zy od konfiguracji. Od wersji 2.0 git domy´slnym zachowaniem (przy braku innych parametrów) jest wysyłanie zmian tylko z aktywnego brancha.

Branch ten musi mie´c ustawiony upstream i t ˛a sam ˛a nazw ˛e lokalnie, jak i w zdalnym repo.

Wcze´sniejsze wersje wysyłały zmiany do wszystkich branchy, których nazwy lokalne pokrywały si ˛e ze zdalnymi. Mogło prowadzi´c to do opublikowania niechcianych zmian, wi ˛ec zachowanie to zostało zmienione.

(99)

Wysyłanie zmian

$ cd ~/acai

Your 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-patch

commit 3c7730e1860259cd79daf925a568e36c8fca06c8 Author: Maciej Wielgosz <wielgosz@agh.edu.pl>

Date: Thu Oct 15 20:13:30 2015 +0200 Add acai ASCII art

(100)

Wysyłanie zmian

$ git push

Counting 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 git@bitbucket.org:maciekwielgosz/acai.git 3fe7e9e..3c7730e master -> master

(101)

Pobieranie zmian

Zmiany ze zdalnego repozytorium pobiera si ˛e poleceniemgit fetch. Aby jednak zostały one zaaplikowane (faktycznie wprowadzone w plikach), nale˙zy nast ˛epnie u˙zy´cgit merge.

$ cd ~/acai-clone

$ git fetch

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

(102)

Pobieranie zmian

$ git merge

Updating 3fe7e9e..3c7730e Fast-forward

acai/acai.txt | 31

,→ +++++++++++++++++++++++++++++++

acai/main.py | 13 ++++++++---

2 files changed, 39 insertions(+), 5 deletions(-) create mode 100644 acai/acai.txt

(103)

Pobieranie zmian

Cz ˛e´sciej u˙zywany jestgit pull, b ˛ed ˛acy ich poł ˛aczeniem:

$ git pull

3c7730e..6c207ea master -> origin/master Updating 3c7730e..6c207ea

Fast-forward .env | 1 +

1 file changed, 1 insertion(+) create mode 100644 .env

(104)

Mo˙zliwo´sci fetch/pull

z fetch pobiera zmiany dla wszystkich branchy istniej ˛acych na domy´slnym remote,

z domy´slny remote dla polecenia fetch mo˙ze ró˙zni´c si ˛e od domy´slnego remote’a dla polecenia push,

z pull mo˙ze zostać tak skonfigurowany, by opierać swoje działanie na rebase zamiast na merge. Nale˙zy wtedy wzi ˛ać pod uwag ˛e te same punkty, które dotycz ˛a rebase.

(105)

Git jako system rozproszony

Zdalne repozytorium

(106)

Fork

Kopia repozytorium, zwykle stworzona w tym samym serwisie co repozytorium „centralne”. Mo˙ze posłu˙zy´c do rozwijania odr ˛ebnej wersji projektu, jako sposób kontroli uprawnie ´n u˙zytkowników czy te˙z

dodatkowy poziom zabezpieczenia głównego repozytorium przed bł ˛edami.

(107)

Kontrola dost ˛epu

Cz ˛esto, zwłaszcza w wi ˛ekszych projektach, ka˙zdy z pracuj ˛acych developerów ma uprawnienia do pobrania zmian z głównego

repozytorium (read access), ale tylko cz ˛e´s´c z nich mo˙ze bezpo´srednio dokonywa´c w nim zmian (write access).

Ka˙zdy z członków zespołu pracuje na swoim forku (jest to jego ’origin’), co jaki´s czas synchronizuj ˛ac go z głównym repozytorium (remote ten przyj ˛eto nazywać ’upstream’). Gdy zako ńczy implementować dan ˛a funkcjonalno´sć, stworzone przez niego zmiany s ˛a zatwierdzane i wł ˛aczane do głównego repozytorium przez kogo´s posiadaj ˛acego odpowiednie uprawnienia.

(108)

Pull request

Proces zgłaszania, akceptowania (b ˛ad´z odrzucania) i wł ˛aczania zmian do głównego repozytorium zazwyczaj odbywa si ˛e przy pomocy tzw.

pull requestów.

Pull requesty pozwalaj ˛a na łatwe przegl ˛adanie zmian, ich

komentowanie, automatyczne testy kodu czy te˙z prost ˛a synchronizacj ˛e z główn ˛a wersj ˛a kodu.

W mo˙zliwo´s´c łatwego tworzenia forków i pull requestów wyposa˙zona jest obecnie wi ˛ekszo´s´c serwisów udost ˛epniaj ˛acych usług ˛e

przechowywania repozytoriów.

(109)

Tworzenie forka

(110)

Tworzenie forka

(111)

Praca z forkiem

$ git clone git@bitbucket.org:yuijim/acai.git ,→ acai-fork

Cloning into ’acai-fork’...

[...]

$ cd acai-fork

$ git remote add upstream

,→ git@bitbucket.org:maciekwielgosz/acai.git

$ git remote origin

upstream

$ git branch

* master

(112)

Praca z forkiem

W czasie pracy z forkiem zwykle nie robi si ˛e zmian bezpo´srednio na branchu ’master’. Ma on słu˙zy´c jako branch referencyjny, który mo˙zna łatwo synchronizowa´c z głównym repozytorium (’upstream’) przed rozpocz ˛eciem kodowania.

$ git pull upstream master

* branch master -> FETCH_HEAD

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

(113)

Praca z forkiem

Wszystkie zmiany wprowadzane s ˛a na dedykowanych branchach. W ten sposób mo˙zna pracowa´c nad kilkoma

poprawkami/funkcjonalno´sciami jednocze´snie, zawsze maj ˛ac jako baz ˛e aktualn ˛a wersj ˛e kodu z głównego repozytorium. Dzi ˛eki takiemu post ˛epowaniu nie ma problemów, je´sli np. cz ˛e´s´c zmian zostanie zaakceptowana, a cz ˛e´s´c odrzucona.

$ git checkout -b fix-autoenv

Switched to a new branch ’fix-autoenv’

(114)

Pull request

Gdy proponowane zmiany znajd ˛a si ˛e ju˙z na forku danego developera, nale˙zy stworzy´c pull request, który nast ˛epnie b ˛edzie oczekiwał na akceptacj ˛e.

(115)

Pull request

(116)