Programowanie. Systemy kotroli wersji. Janusz Szwabiński. Plan wykładu:

Transkrypt

1 Programowanie Systemy kotroli wersji Janusz Szwabiński Plan wykładu: Motywacja Przegląd dostępnych systemów Git Git na Windows Github Subversion Subversion na Windows Dobre praktyki kontroli wersji Materiały do wykładu Dokumentacja gita: ( Essential git, ( A. Bystrek, Git tutorial - jak zacząc z Git, ( Dokumentacja SVN: ( TortoiseSVN: ( Dokumentacja Mercuriala: ( file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 1/39

2 Motywacja Z życia wzięte... Brak kontroli wersji często spotykany w jednoosobowych projektach często generujący całkowitą lub częściową utratę plików (głównie przez nadpisanie) Ręczna kontrola wersji file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 2/39

3 ciągle popularna metoda historia zmian często wpisana do plików źródłowych ręczne kopie zapasowe uciążliwe scalanie zmian pochodzących od różnych programistów file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 3/39

4 słabo skaluje się z liczbą programistów bardzo trudno jest zachować informację o kolejności i autorstwie zmian podatna na błędy, zwłaszcza w "gorących" okresach życia projektu w przypadku problemów wymaga z reguły dużych nakładów czasu i pracy potrzebnych do odtworzenia projektu Systemy kontroli wersji system kontroli wersji (ang. version/revision control system) oprogramowanie przechowujące historię zmian dokonanych w kodzie źródłowym lub innych dokumentach po co?: ułatwienie kontroli nad projektem śledzenie zmian w projekcie przechowywanie różnych wersji projektu ułatwienie współpracy nad projektem szybki powrót do ostatniej działającej wersji w przypadku błędów automatyzacja kopii zapasowych rodzaje: lokalne rozproszone scentralizowane file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 4/39

5 Przegląd dostępnych systemów CVS Subversion Git Microsoft Visual SourceSafe Visual Studio Team System Mercurial Bazaar Darcs SVK file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 5/39

6 Git Krótka historia Git jądro Linuksa jest dużym projektem otwartego oprogramowania w latach zmiany w źródle były przekazywane jako łaty (ang. patches) i zarchiwizowane pliki w 2002 projekt jądra Linuksa zaczął używać systemu DVCS BitKeeper w 2005 cofnięto projektowi pozwolenie na nieodpłatne używanie systemu skłoniło to twórcę Linuksa, Linusa Torvaldsa, i pozostałych programistów do stworzenia własnego systemu cechy tego systemu zdefiniowane zostały na podstawie wiedzy wyniesionej z używania BitKeepera: szybkość prosta konstrukcja silne wsparcie dla nieliniowego rozwoju (tysiące równoległych gałęzi) wydajna obsługa dużych projektów w wyniku tych prac powstał Git obecnie to jeden z najpopularniejszych rozproszonych systemów kontroli wersji Podstawy Git Migawki większość systemów kontroli wersją przechowuje informacje jako listę zmian na plikach: Git traktuje dane jak zestaw migawek (ang. snapshots) małego systemu plików przy każdym wysłaniu zmian albo zapisaniu stanu projektu Git tworzy obraz przedstawiający to jak wyglądają wszystkie pliki w danym momencie i przechowuje referencję do tej migawki w celu uzyskania dobrej wydajności, jeśli dany plik nie został zmieniony, Git nie zapisuje ponownie tego pliku, a tylko referencję do jego poprzedniej, identycznej wersji file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 6/39

7 Operacje o charakterze lokalnym większość operacji w Git do działania wymaga jedynie dostępu do lokalnych plików i zasobów nie są potrzebne żadne dane przechowywane na innym komputerze w sieci kompletna historia projektu znajduje się w całości na dysku lokalnym dzięki temu odnosi się wrażenie, że większość operacji działa niemal natychmiast dzięki temu również można zrobić prawie wszystko będąc poza zasięgiem sieci: jeśli synchronizujemy zmiany z serwerem zdalnym, możemy przesłać cały ich pakiet po odzyskaniu połączenia z siecią Mechanizmy spójności danych dla każdego obiektu Git wyliczana jest suma kontrolna (skrót SHA-1) przed jego zapisem na jej podstawie można odwoływać się do danego obiektu nie ma możliwości zmiany zawartości żadnego pliku, czy katalogu bez reakcji ze strony Git nie ma szansy na utratę informacji, czy uszkodzenie zawartości pliku podczas przesyłania lub pobierania danych, bez możliwości wykrycia takiej sytuacji przez Git Trzy stany git wyróżnia 3 stany plików: zatwierdzony - dane zapisane bezpiecznie w lokalnej bazie danych zmodyfikowany - plik został zmieniony, ale zmiany nie zostały wprowadzone do bazy śledzony - plik został przeznaczony do zatwierdzenia w bieżącej postaci w następnej operacji zatwierdzania zmian (ang. commit) ze stanami związane są 3 główne sekcje projektu Git: katalog Git (repozytorium) - miejsce, w którym Git przechowuje własne metadane oraz obiektową bazę danych projektu. To najważniejsza część Git i to właśnie ten katalog jest kopiowany podczas klonowania repozytorium z innego komputera katalog roboczy - obraz jednej wersji projektu. Zawartość tego katalogu pobierana jest ze skompresowanej bazy danych zawartej w katalogu Git i umieszczana na dysku w miejscu, w którym można ją odczytać lub zmodyfikować przechowalnia (staging area) - prosty plik, zwykle przechowywany w katalogu Git, który zawiera informacje o tym, czego dotyczyć będzie następna operacja zatwierdzania zmian file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 7/39

8 Instalacja Git najlepszą metodą jest instalacja ze źródeł, do pobrania pod adresem ( w ten sposób mamy do dyspozycji najnowszą wersję pakiety binarne pod Linuksem: yum install git-core apt-get install git pakiety binarne dla MacOS: sudo port install git-core +svn +doc +bash_completion +gitweb instalacja w systemie Windows instalator do pobrania pod adresem ( file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 8/39

9 Wstępna konfiguracja git config - narzędzie konfiguracyjne konfigurację wystarczy przeprowadzić raz - będzie obowiązywać również po aktualizacji Gita trzy pliki konfiguracyjne (każdy z nich ma priorytet wyższy od poprzednika): /etc/gitconfig - wartości zmiennych widoczne dla każdego użytkownika w systemie oraz dla każdego z ich repozytoriów. Dodając opcję --system do polecenia git config, odczytane bądź zapisane zostaną zmienne z tej właśnie lokalizacji ~/.gitconfig - lokalizacja specyficzna dla danego użytkownika. Za pomocą opcji -- global można uzyskać dostęp do tych właśnie zmiennych plik konfiguracyjny w katalogu git bieżącego repozytorium (tzn..git/config) zawiera konfigurację charakterystyczną dla tego konkretnego repozytorium Tożsamość użytkownika git config --global user.name "Jan Nowak" git config --global user. jannowak@example.com opcja --global powoduje, że każda operacja będzie od tego momentu korzystała z tych danych jeśli zaistnieje potrzeba zmiany tych informacji dla konkretnego projektu, można skorzystać z git config bez opcji --global Edytor git config --global core.editor nano domyślny edytor tekstowy w przeciwnym razie Git będzie korzystał z vi/vim, które zazwyczaj są zainstalowane w systemie (z rodziny Unix/Linux) Narzędzie obsługi różnic git config --global merge.tool vimdiff używane przy rozstrzyganiu różnic i problemów podczas edycji konfliktów powstałych w czasie operacji łączenia (ang. merge) inne możliwe narzędzia: kdiff3, tkdiff, meld, xxdiff, emerge, gvimdiff, ecmerge oraz opendiff Sprawdzanie ustawień git config --list git config user.name file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 9/39

10 Pierwsze kroki - uzyskiwanie pomocy git help <polecenie> git <polecenie> --help man git-<polecenie> nie wymagają połączenia z Internetem Pierwsze repozytorium Git dwie metody: importowanie istniejącego katalogu lub projektu do Gita sklonowanie istniejącego repozytorium z serwera Inicjalizacja Git w istniejącym katalogu przechodzimy do katalogu projektu (może być pusty) wykonujemy polecenie git init utworzony zostanie podkatalog.git zawierający wszystkie niezbędne pliki - szkielet repozytorium Git jeśli w katalogu znajdowały się jakieś pliki, powinniśmy rozpocząć ich śledzenie i utworzyć początkową wersję projektu poleceniami: git add *.py git add Readme git commit -m 'Initial project version' Klonowanie istniejącego repozytorium poleceniem clone pobierzemy kopię niemalże wszystkich danych posiadanych przez serwer git clone git://github.com/vinta/awesome-python kilka protokołów transmisji: git, http(s), ssh file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 10/39

11 Rejestrowanie zmian w repozytorium za każdym razem, kiedy po naniesieniu zmian projekt osiągnie stan, który powinien być zapamiętany, należy zatwierdzić nowe wersje plików w repozytorium kiedy zmieniamy pliki, Git zapamiętuje je jako zmodyfikowane (różnią się od ostatniej zatwierdzonej zmiany) zmodyfikowane pliki należy umieścić w poczekalni, a następnie zatwierdzić wszystkie oczekujące tam zmiany: Sprawdzanie stanu plików git status #On branch master #Your branch is up-to-date with 'origin/master'. #nothing to commit, working directory clean taki komunikat oznacza, że katalog roboczy nie zawiera śledzonych i zmodyfikowanych plików Git nie widzi również żadnych plików nieśledzonych dodajmy do repozytorium nowy plik README i ponownie sprawdźmy status: vim README git status On branch master Your branch is up-to-date with 'origin/master'. Untracked files: (use "git add <file>..." to include in what will be committed) README nothing added to commit but untracked files present (use "git add" to track) file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 11/39

12 nowy plik README nie jest jeszcze śledzony nieśledzony oznacza, że Git widzi plik, którego nie było w poprzedniej migawce (tzn. zatwierdzonej kopii) Git nie zacznie umieszczać go w przyszłych migawkach, dopóki sami tego nie polecimy Śledzenie nowych plików git add README git status On branch master Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD <file>..." to unstage) nowy plik: README Dodawanie zmodyfikowanych plików do poczekalni vi sort.py git status On branch master Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD <file>..." to unstage) nowy plik: README 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) zmodyfikowany: sort.py plik sort.py został zmieniony, ale modyfikacje nie trafiły jeszcze do poczekalni git add sort.py git status On branch master Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD <file>..." to unstage) nowy plik: README zmodyfikowany: sort.py file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 12/39

13 Podglądanie zmian git diff --cached diff --git a/readme b/readme new file mode index a97f5a --- /dev/null +++ b/readme -0,0 +1 +To jest nowy plik diff --git a/sort.py b/sort.py index d646c3f..25d2c a/sort.py +++ b/sort.py -1,5 +1,5 # coding: utf-8 - +# test """ The approach taken is explained below. I decided to do it simply. Initially I was considering parsing the data into some sort of Zatwierdzanie zmian git commit -m "Zmiany ilustrujące zasady działania Gita" [master 80d29af] Zmiany ilustrujące zasady działania Gita 2 files changed, 2 insertions(+), 1 deletion(-) create mode README Usuwanie plików należy usunąć plik ze zbioru plików śledzonych, a następnie zatwiedzić zmiany polecenie git rm automatycznie usuwa plik z katalogu roboczego zmiana musi zostać zatwierdzona file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 13/39

14 git rm README rm 'README' git status On branch master Your branch is ahead of 'origin/master' by 1 commit. (use "git push" to publish your local commits) Changes to be committed: (use "git reset HEAD <file>..." to unstage) usunięty: README git commit -m "Usunięcie pliku Readme" [master 94ca90a] Usunięcie pliku Readme 1 file changed, 1 deletion(-) delete mode README git status On branch master Your branch is ahead of 'origin/master' by 2 commits. (use "git push" to publish your local commits) nothing to commit, working directory clean file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 14/39

15 Podgląd historii rewizji git log commit 94ca90aaeaa2bc736037ed11accb31f155a60e31 Author: Janusz Szwabiński Date: Mon May 22 14:53: Usunięcie pliku Readme commit 80d29af0c9e167d d912ee388e1f4a81ab Author: Janusz Szwabiński Date: Mon May 22 14:47: Zmiany ilustrujące zasady działania Gita commit efb1cb6181a725548e c2df50bcfc4bed Merge: a25069d Author: Vinta Date: Wed May 3 21:46: Merge pull request #881 from nikos/patch-1 Added awesome pysolr library to Search section. <snip> git log --pretty=oneline 94ca90aaeaa2bc736037ed11accb31f155a60e31 Usunięcie pliku Readme 80d29af0c9e167d d912ee388e1f4a81ab Zmiany ilustrujące zasady działa nia Gita <snip> git log --since=10.minutes commit 94ca90aaeaa2bc736037ed11accb31f155a60e31 Author: Janusz Szwabiński <szwabin@gmail.com> Date: Mon May 22 14:53: Usunięcie pliku Readme file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 15/39

16 Etykietowanie możliwość etykietowania ważnych miejsc w historii projektu większość użytkowników wykorzystuje to do zaznaczania ważnych wersji kodu (np. wersja 1.0) Tworzenie etykiet git tag -a v0.1 -m 'Moja wersja 0.1' Wyświetlanie etykiet git tag v0.1 git show v0.1 tag v0.1 Tagger: Janusz Szwabiński <szwabin@gmail.com> Date: Tue May 23 09:12: Moja wersja 0.1 commit 400d0d3b875976b75242b93e94753ed3926e9f9f Author: szwabin <szwabin@gmail.com> Date: Mon May 22 15:28: Initial commit diff --git a/readme.md b/readme.md new file mode index e2a /dev/null ,0 +# pytrek +A StarTrek inspired shooter file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 16/39

17 Gałęzie gałąź w Gicie to przesuwalny wskaźnik na jakąś migawkę projektu domyślna nazwa gałęzi to master tworząc nową gałąź, dodajemy wskaźnik, który potem będziemy mogli przesuwać początkowo jednak nowa gałąź wskazuje na ten sam zestaw zmian, co master git branch testing Git utrzymuje specjalny wskaźnik HEAD, który zawiera informację o aktualnej gałęzi dodanie nowej gałęzi nie powoduje automatycznego przełączenia do niej file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 17/39

18 polecenie git checkout służy do przełączania się między gałęziami git checkout testing zmiany dodawane są tylko do aktualnej gałęzi vim test.rb git commit -a -m 'zmiana' file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 18/39

19 powrót do gałęzi master cofnie nas do stanu projektu sprzed ostatniej zmiany git checkout master kolejne zmiany doprowadzą do rozgałęzienia historii projektu vim test.rb git commit -a -m 'inna zmiana' file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 19/39

20 gałęzie w Gicie są chętnie używane, ponieważ są tanie w tworzeniu i usuwaniu (inaczej niż w większości systemów kontroli wersji) file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 20/39

21 Podstawy rozgałęziania i scalania - przykład Scenariusz pracujemy nad stroną internetową tworzymy gałąź dla wersji z nową funkcją, którą akurat implementujemy dalsze prace odbywają się w nowej gałęzi otrzymujemy telefon od szefa/klienta, że inny problem jest obecnie priorytetowy i potrzeba błyskawicznej poprawki wracamy do gałęzi produkcyjnej tworzymy nową gałąź, by dodać tam poprawkę po przetestowaniu scalamy gałąź z poprawką i "wypychamy" zmiany na serwer produkcyjny wracamy do gałęzi z nową funkcją i kontunuujemy implementacje Przebieg pracy z Gitem załóżmy, że pracujemy już z projektem i mamy zatwierdzonych kilka zmian w systemie śledzenia zgłoszeń pojawił się bardzo ważny problem nr 53, którym chcemy się zająć w pierwszej kolejności tworzymy nową gałąź, jednocześnie się na nią przełączając git checkout -b iss53 Switched to a new branch "iss53" pracujemy nad stroną w nowej gałęzi i zatwierdzamy kolejne zmiany - aktualna gałąź przesuwa się do przodu vim index.html git commit -a -m 'nowa stopka [#53]' file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 21/39

22 po otrzymaniu wiadomości o błędzie do natychmiastowej poprawki wracamy do gałęzi produkcyjnej git checkout master Switched to branch "master" w tym momencie projekt jest dokładnie w takim samym stanie, jak przed przejściem do gałęzi iss53 tworzymy kolejną gałąź, w ramach której poprawimy błąd git checkout -b 'hotfix' Switched to a new branch "hotfix" vim index.html git commit -a -m 'poprawiony adres ' [hotfix]: created 3a0874c: "poprawiony adres " 1 files changed, 0 insertions(+), 1 deletions(-) po przetestowaniu okazuje się, że błąd został usunięty, dlatego możemy scalić gałąź błędu z gałęzią master git checkout master git merge hotfix Updating f42c576..3a0874c Fast forward README 1-1 files changed, 0 insertions(+), 1 deletions(-) file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 22/39

23 ponieważ gałąź master była bezpośrednim rodzicem aktualnego zestawu zmian, Git przesuwa jej wskaźnik do przodu usuwamy gałąź hotfix, bo nie jest już potrzebna git branch -d hotfix Deleted branch hotfix (3a0874c) możemy teraz wrócić do przerwanej wcześniej pracy nad nową funkcją git checkout iss53 Switched to branch "iss53" vim index.html git commit -a -m 'skończona nowa stopka [#53]' [iss53]: created ad82d7a: "skończona nowa stopka [#53]" 1 files changed, 1 insertions(+), 0 deletions(-) po zakończeniu pracy możemy scalić tę gałąź z gałęzią master git checkout master git merge iss53 file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 23/39

24 Merge made by recursive. README files changed, 1 insertions(+), 0 deletions(-) w tym wypadku jest to tzw. scalenie trójstronne (ang. three-way merge), ponieważ historia rozwoju została rozszczepiona na wcześniejszym etapie - Git używa dwóch migawek wskazywanych przez końcówki gałęzi i ich wspólnego przodka (najlepszy przodek wybierany jest automatycznie) w wyniku scalenia Git tworzy w tym przypadku nową migawkę pracę kończymy usuwając gałąź iss53 git branch -d iss53 file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 24/39

25 Konflikty scalania czasami zdarza się, że ten sam plik został w różnych gałęziach różnie zmodyfikowany taka sytuacja to konflikt - Git nie rozwiąże jej samodzielnie jeśli np. poprawka problemu #53 z powyższego przykładu zmieniła tę samą część pliku, co zmiana w gałęzi hotfix, podczas scalania pojawi się komunikat o konflikcie git merge iss53 Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result. zmiana scalająca nie została zatwierdzona w każdej chwili możemy podglądnąć pliki, które nie zostały scalone git status index.html: needs merge 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) unmerged: index.html niescalony plik zawiera mniej więcej coś takiego <<<<<<< HEAD:index.html <div id="footer">contact : .support@github.com</div> ======= <div id="footer"> please contact us at support@github.com </div> >>>>>>> iss53:index.html konflikt możemy usunąć ręcznie, edytując odpowiednie pliki i zatwierdzając ich zmiany lub korzystając z odpowiedniego narzędzia file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 25/39

26 git mergetool merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff Merging the files: index.html Normal merge conflict for 'index.html': {local}: modified {remote}: modified Hit return to start merge resolution tool (opendiff): po usunięciu konfliktu zatwierdzamy zmiany przy pomocy git commit file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 26/39

27 Git na Windows Wstępna konfiguracja Git poszukuje pliku.gitconfig w katalogu %HOME% (C:\Documents and Settings\%USERNAME% w większości przypadków). Git sprawdza również istnienie pliku /etc/gitconfig, ale w tym wypadku katalog ten jest katalogiem względnym do katalogu instalacji MSysGit Konsola Gita po zainstalowaniu msysgit klikamy w menedżerze plików na ikonę katalogu projektu prawym przyciskiem myszki i wybieramy z menu kontekstowego polecenie Git Bash w powłoce Gita możemy wykonać wszystkie polecenia wspomniane wcześniej Git GUI file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 27/39

28 SourceTree ( ( SmartGit ( ( TortoiseGit ( ( file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 28/39

29 Github serwis internetowy przeznaczony głównie dla programistów wykorzystuje Git darmowy hosting programów open source płatne prywatne repozytoria działa od mln aktywnych repozytoriów w 2016 Tworzenie nowego projektu file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 29/39

30 Klonowanie projektu file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 30/39

31 git clone git://github.com/szwabin/pytrek Cloning into 'pytrek'... remote: Counting objects: 3, done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 Receiving objects: 100% (3/3), done. Checking connectivity... done. cd pytrek/ ls README.md Zdalne wprowadzanie zmian file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 31/39

32 vi README.md git commit -a -m 'Name added' [master 5ae42c5] Name added 1 file changed, 2 insertions(+) git push warning: push.default is unset; its implicit value has changed in Git 2.0 from 'matching' to 'simple'. To squelch this message and maintain the traditional behavior, use: git config --global push.default matching To squelch this message and adopt the new behavior now, use: git config --global push.default simple When push.default is set to 'matching', git will push local branches to the remote branches that already exist with the same name. Since Git 2.0, Git defaults to the more conservative 'simple' behavior, which only pushes the current branch to the corresponding remote branch that 'git pull' uses to update the current branch. See 'git help config' and search for 'push.default' for further informati on. (the 'simple' mode was introduced in Git Use the similar mode 'current' instead of 'simple' if you sometimes use older versions of Git) Username for ' szwabin Password for ' Counting objects: 3, done. Delta compression using up to 8 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 310 bytes 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) To 400d0d3..5ae42c5 master -> master file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 32/39

33 file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 33/39

34 Subversion (SVN) Instalacja wymaga zainstalowania klienta (jeśli chcemy pracować z istniejącymi zdalnymi repozytoriami) i serwera (jeśli chcemy sami tworzyć i oferować repozytoria) Podstawowe polecenia Tworzenie kopii roboczej svn checkout URL PATH URL to adres repozytorium PATH to miejsce w lokalnym drzewie katalogów, do którego wstawiona zostanie kopia Zapisywanie zmian w repozytorium svn commit -m "log messages" Przeglądanie zawartości repozytorium svn list Dodawanie pliku do repozytorium file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 34/39

35 svn add file_name svn commit -m "Adding new file" file_name Usuwanie pliku z repozytorium svn delete file_name svn commit -m "Removing file" file_name Różnice między plikami svn diff file_name Przykład: svn diff thegeekstuff Index: thegeekstuff =================================================================== --- thegeekstuff (revision 815) +++ thegeekstuff (working -1 -testing +tester Status kopii roboczej svn status PATH Wyświetlanie logów svn log PATH Zmiana nazw plików lub katalogów svn move src dest svn commit -m "Renaming src to dest" dest Aktualizacja kopii roboczej svn update PATH Tworzenie gałęzi file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 35/39

36 Tworzenie gałęzi svn copy \ \ -m "Creating a private branch of /calc/trunk." svn checkout Scalanie gałęzi najpierw scalamy zmiany w repozytorium z naszą gałęzią svn merge ^/calc/trunk svn commit -m "Final merge of trunk changes to my-calc-branch." aktualizujemy całość svn update a następnie scalamy naszą gałąź z resztą svn merge --reintegrate ^/calc/branches/my-calc-branch svn commit -m "Merge my-calc-branch back into trunk!" file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 36/39

37 Subversion na Windows Serwer ( - VisualSVNServer ( ( - darmowy w wersji standardowej Klient TortoiseSVN ( ( - integruje się z powłoką Windowsa (czyli m.in. Windows Explorerem) VisualSVN ( ( file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 37/39

38 Dobre praktyki zarządzania wersjami zatwierdzaj razem tylko powiązane zmiany zatwierdzaj zmiany często (małe zmiany łatwiej zrozumieć) nie zatwierdzaj zmian, jeśli nie są dokończone przetestuj, zanim zatwierdzisz pisz wyczerpujące podsumowania zatwierdzanych zmian file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 38/39

39 file:///home/szwabin/dropbox/zajecia/programowanie/lectures/10_cvs.html 39/39