Download - Programowanie - prac.im.pwr.wroc.plprac.im.pwr.wroc.pl/~szwabin/assets/prog/lec/10.pdf · Systemy kontroli wersji system kontroli wersji (ang. version/revision control system ) –

9.06.2017 10_cvs

file:///home/szwabin/Dropbox/Zajecia/Programowanie/Lectures/10_cvs.html 1/39

Programowanie

Systemy kotroli wersji

Janusz Szwabiński

Plan wykładu:

MotywacjaPrzegląd dostępnych systemówGitGit na WindowsGithubSubversionSubversion na WindowsDobre praktyki kontroli wersji

Materiały do wykładu

Dokumentacja gita: https://git-scm.com/doc (https://git-scm.com/doc)Essential git, https://nhs.io/git/ (https://nhs.io/git/)A. Bystrek, Git tutorial - jak zacząc z Git, http://poznajprogramowanie.pl/git-tutorial-jak-zaczac-z-git/(http://poznajprogramowanie.pl/git-tutorial-jak-zaczac-z-git/)Dokumentacja SVN: https://subversion.apache.org/docs/ (https://subversion.apache.org/docs/)TortoiseSVN: https://tortoisesvn.net/support.html (https://tortoisesvn.net/support.html)Dokumentacja Mercuriala: https://www.mercurial-scm.org/guide (https://www.mercurial-scm.org/guide)

https://git-scm.com/doc

https://nhs.io/git/

http://poznajprogramowanie.pl/git-tutorial-jak-zaczac-z-git/

https://subversion.apache.org/docs/

https://tortoisesvn.net/support.html

https://www.mercurial-scm.org/guide

9.06.2017 10_cvs


Motywacja

Z życia wzięte...

Brak kontroli wersji

często spotykany w jednoosobowych projektachczęsto generujący całkowitą lub częściową utratę plików (głównie przez nadpisanie)

Ręczna kontrola wersji

9.06.2017 10_cvs


ciągle popularna metodahistoria zmian często wpisana do plików źródłowychręczne kopie zapasoweuciążliwe scalanie zmian pochodzących od różnych programistów

9.06.2017 10_cvs


słabo skaluje się z liczbą programistówbardzo trudno jest zachować informację o kolejności i autorstwie zmianpodatna na błędy, zwłaszcza w "gorących" okresach życia projektuw przypadku problemów wymaga z reguły dużych nakładów czasu i pracy potrzebnych doodtworzenia projektu

Systemy kontroli wersji

system kontroli wersji (ang. version/revision control system) – oprogramowanie przechowującehistorię zmian dokonanych w kodzie źródłowym lub innych dokumentachpo co?:

ułatwienie kontroli nad projektemśledzenie zmian w projekcieprzechowywanie różnych wersji projektuułatwienie współpracy nad projektemszybki powrót do ostatniej działającej wersji w przypadku błędówautomatyzacja kopii zapasowych

rodzaje:lokalnerozproszonescentralizowane

9.06.2017 10_cvs


Przegląd dostępnych systemówCVSSubversionGitMicrosoft Visual SourceSafeVisual Studio Team SystemMercurialBazaarDarcsSVK

9.06.2017 10_cvs


Git

Krótka historia Git

jądro Linuksa jest dużym projektem otwartego oprogramowaniaw latach 1991-2002 zmiany w źródle były przekazywane jako łaty (ang. patches) i zarchiwizowaneplikiw 2002 projekt jądra Linuksa zaczął używać systemu DVCS BitKeeperw 2005 cofnięto projektowi pozwolenie na nieodpłatne używanie systemuskłoniło to twórcę Linuksa, Linusa Torvaldsa, i pozostałych programistów do stworzenia własnegosystemucechy tego systemu zdefiniowane zostały na podstawie wiedzy wyniesionej z używania BitKeepera:

szybkośćprosta konstrukcjasilne wsparcie dla nieliniowego rozwoju (tysiące równoległych gałęzi)wydajna obsługa dużych projektów

w wyniku tych prac powstał Gitobecnie 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ówprzy każdym wysłaniu zmian albo zapisaniu stanu projektu Git tworzy obrazprzedstawiający to jak wyglądają wszystkie pliki w danym momencie i przechowujereferencję do tej migawkiw celu uzyskania dobrej wydajności, jeśli dany plik nie został zmieniony, Git nie zapisujeponownie tego pliku, a tylko referencję do jego poprzedniej, identycznej wersji

9.06.2017 10_cvs


Operacje o charakterze lokalnym

większość operacji w Git do działania wymaga jedynie dostępu do lokalnych plików i zasobównie są potrzebne żadne dane przechowywane na innym komputerze w siecikompletna historia projektu znajduje się w całości na dysku lokalnymdzięki temu odnosi się wrażenie, że większość operacji działa niemal natychmiastdzię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 poodzyskaniu połączenia z siecią

Mechanizmy spójności danych

dla każdego obiektu Git wyliczana jest suma kontrolna (skrót SHA-1) przed jego zapisemna jej podstawie można odwoływać się do danego obiektunie ma możliwości zmiany zawartości żadnego pliku, czy katalogu bez reakcji ze strony Gitnie ma szansy na utratę informacji, czy uszkodzenie zawartości pliku podczas przesyłania lubpobierania 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 danychzmodyfikowany - plik został zmieniony, ale zmiany nie zostały wprowadzone do bazyśledzony - plik został przeznaczony do zatwierdzenia w bieżącej postaci w następnejoperacji 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 orazobiektową bazę danych projektu. To najważniejsza część Git i to właśnie ten katalog jestkopiowany podczas klonowania repozytorium z innego komputerakatalog roboczy - obraz jednej wersji projektu. Zawartość tego katalogu pobierana jest zeskompresowanej 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óryzawiera informacje o tym, czego dotyczyć będzie następna operacja zatwierdzania zmian

9.06.2017 10_cvs


Instalacja Git

najlepszą metodą jest instalacja ze źródeł, do pobrania pod adresem http://git-scm.com/download(http://git-scm.com/download)

w ten sposób mamy do dyspozycji najnowszą wersjępakiety binarne pod Linuksem: yum install git-core apt-get install gitpakiety binarne dla MacOS: sudo port install git-core +svn +doc +bash_completion +gitwebinstalacja w systemie Windows

instalator do pobrania pod adresem http://msysgit.github.com/ (http://msysgit.github.com/)

http://git-scm.com/download

http://msysgit.github.com/

9.06.2017 10_cvs


Wstępna konfiguracja

git config - narzędzie konfiguracyjnekonfigurację wystarczy przeprowadzić raz - będzie obowiązywać również po aktualizacji Gitatrzy pliki konfiguracyjne (każdy z nich ma priorytet wyższy od poprzednika):

/etc/gitconfig - wartości zmiennych widoczne dla każdego użytkownika w systemieoraz 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 zmiennychplik konfiguracyjny w katalogu git bieżącego repozytorium (tzn. .git/config) zawierakonfigurację charakterystyczną dla tego konkretnego repozytorium

Tożsamość użytkownika

git config --global user.name "Jan Nowak" git config --global user.email [email protected]

opcja --global powoduje, że każda operacja będzie od tego momentu korzystała z tych danychjeś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 tekstowyw przeciwnym razie Git będzie korzystał z vi/vim, które zazwyczaj są zainstalowane w systemie (zrodziny 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 czasieoperacji łą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

9.06.2017 10_cvs


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 Gitasklonowanie istniejącego repozytorium z serwera

Inicjalizacja Git w istniejącym katalogu

przechodzimy do katalogu projektu (może być pusty)wykonujemy polecenie

git initutworzony zostanie podkatalog .git zawierający wszystkie niezbędne pliki - szkielet repozytoriumGitjeś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

9.06.2017 10_cvs


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 repozytoriumkiedy zmieniamy pliki, Git zapamiętuje je jako zmodyfikowane (różnią się od ostatniej zatwierdzonejzmiany)zmodyfikowane pliki należy umieścić w poczekalni, a następnie zatwierdzić wszystkie oczekującetam 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ówGit nie widzi również żadnych plików nieśledzonychdodajmy 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)

9.06.2017 10_cvs


nowy plik README nie jest jeszcze śledzonynieśledzony oznacza, że Git widzi plik, którego nie było w poprzedniej migawce (tzn. zatwierdzonejkopii)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

9.06.2017 10_cvs


Podglądanie zmian

git diff --cached diff --git a/README b/README new file mode 100644 index 0000000..7a97f5a --- /dev/null +++ b/README @@ -0,0 +1 @@ +To jest nowy plik diff --git a/sort.py b/sort.py index d646c3f..25d2c08 100644 --- 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 100644 README

Usuwanie plików

należy usunąć plik ze zbioru plików śledzonych, a następnie zatwiedzić zmianypolecenie git rm

automatycznie usuwa plik z katalogu roboczegozmiana musi zostać zatwierdzona

9.06.2017 10_cvs


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 100644 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

9.06.2017 10_cvs


Podgląd historii rewizji

git log commit 94ca90aaeaa2bc736037ed11accb31f155a60e31 Author: Janusz Szwabiński <[email protected]> Date: Mon May 22 14:53:27 2017 +0200 Usunięcie pliku Readme commit 80d29af0c9e167d6590743d912ee388e1f4a81ab Author: Janusz Szwabiński <[email protected]> Date: Mon May 22 14:47:36 2017 +0200 Zmiany ilustrujące zasady działania Gita commit efb1cb6181a725548e74726681c2df50bcfc4bed Merge: 9973479 a25069d Author: Vinta <[email protected]> Date: Wed May 3 21:46:07 2017 +0800 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 80d29af0c9e167d6590743d912ee388e1f4a81ab Zmiany ilustrujące zasady działania Gita <snip>

git log --since=10.minutes commit 94ca90aaeaa2bc736037ed11accb31f155a60e31 Author: Janusz Szwabiński <[email protected]> Date: Mon May 22 14:53:27 2017 +0200 Usunięcie pliku Readme

9.06.2017 10_cvs


Etykietowanie

możliwość etykietowania ważnych miejsc w historii projektuwię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 <[email protected]> Date: Tue May 23 09:12:37 2017 +0200 Moja wersja 0.1 commit 400d0d3b875976b75242b93e94753ed3926e9f9f Author: szwabin <[email protected]> Date: Mon May 22 15:28:23 2017 +0200 Initial commit diff --git a/README.md b/README.md new file mode 100644 index 0000000..e2a8374 --- /dev/null +++ b/README.md @@ -0,0 +1,2 @@ +# pytrek +A StarTrek inspired shooter

9.06.2017 10_cvs


Gałęzie

gałąź w Gicie to przesuwalny wskaźnik na jakąś migawkę projektudomyś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łęzidodanie nowej gałęzi nie powoduje automatycznego przełączenia do niej

9.06.2017 10_cvs


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'

9.06.2017 10_cvs


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'

9.06.2017 10_cvs


gałęzie w Gicie są chętnie używane, ponieważ są tanie w tworzeniu i usuwaniu (inaczej niż wwiększości systemów kontroli wersji)

9.06.2017 10_cvs


Podstawy rozgałęziania i scalania - przykład

Scenariusz

pracujemy nad stroną internetowątworzymy gałąź dla wersji z nową funkcją, którą akurat implementujemydalsze prace odbywają się w nowej gałęziotrzymujemy telefon od szefa/klienta, że inny problem jest obecnie priorytetowy i potrzebabłyskawicznej poprawki

wracamy do gałęzi produkcyjnejtworzymy nową gałąź, by dodać tam poprawkępo przetestowaniu scalamy gałąź z poprawką i "wypychamy" zmiany na serwerprodukcyjnywracamy 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ąć wpierwszej kolejnościtworzymy 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]'

9.06.2017 10_cvs


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 iss53tworzymy 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 e-mail' [hotfix]: created 3a0874c: "poprawiony adres e-mail" 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(-)

9.06.2017 10_cvs


ponieważ gałąź master była bezpośrednim rodzicem aktualnego zestawu zmian, Git przesuwa jejwskaź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

9.06.2017 10_cvs


Merge made by recursive. README | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) w tym wypadku jest to tzw. scalenie trójstronne (ang. three-way merge), ponieważ historia rozwojuzostała rozszczepiona na wcześniejszym etapie - Git używa dwóch migawek wskazywanych przezkoń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

9.06.2017 10_cvs


Konflikty scalania

czasami zdarza się, że ten sam plik został w różnych gałęziach różnie zmodyfikowanytaka sytuacja to konflikt - Git nie rozwiąże jej samodzielniejeśli np. poprawka problemu #53 z powyższego przykładu zmieniła tę samą część pliku, co zmianaw 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 zatwierdzonaw 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 : [email protected]</div> ======= <div id="footer"> please contact us at [email protected] </div> >>>>>>> iss53:index.html

konflikt możemy usunąć ręcznie, edytując odpowiednie pliki i zatwierdzając ich zmiany lubkorzystając z odpowiedniego narzędzia

9.06.2017 10_cvs


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

9.06.2017 10_cvs


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 jestkatalogiem względnym do katalogu instalacji MSysGit

Konsola Gita

po zainstalowaniu msysGit klikamy w menedżerze plików na ikonę katalogu projektu prawymprzyciskiem myszki i wybieramy z menu kontekstowego polecenie Git Bash

w powłoce Gita możemy wykonać wszystkie polecenia wspomniane wcześniej

Git GUI

9.06.2017 10_cvs


SourceTree (https://www.sourcetreeapp.com/ (https://www.sourcetreeapp.com/))SmartGit (http://www.syntevo.com/smartgit/ (http://www.syntevo.com/smartgit/))TortoiseGit (https://tortoisegit.org/ (https://tortoisegit.org/))

https://www.sourcetreeapp.com/

http://www.syntevo.com/smartgit/

https://tortoisegit.org/

9.06.2017 10_cvs


Githubserwis internetowy przeznaczony głównie dla programistówwykorzystuje Gitdarmowy hosting programów open sourcepłatne prywatne repozytoriadziała od 200820 mln aktywnych repozytoriów w 2016

Tworzenie nowego projektu

9.06.2017 10_cvs


Klonowanie projektu

9.06.2017 10_cvs


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

9.06.2017 10_cvs


vi README.md git commit -a -m 'Name added' [master 5ae42c5] Name added 1 file changed, 2 insertions(+) git push https://github.com/szwabin/pytrek.git 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 information. (the 'simple' mode was introduced in Git 1.7.11. Use the similar mode 'current' instead of 'simple' if you sometimes use older versions of Git) Username for 'https://github.com': szwabin Password for 'https://[email protected]': 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 https://github.com/szwabin/pytrek.git 400d0d3..5ae42c5 master -> master

9.06.2017 10_cvs


9.06.2017 10_cvs


Subversion (SVN)

Instalacja

wymaga zainstalowania klienta (jeśli chcemy pracować z istniejącymi zdalnymi repozytoriami) iserwera (jeśli chcemy sami tworzyć i oferować repozytoria)

Podstawowe polecenia

Tworzenie kopii roboczej

svn checkout URL PATH

URL to adres repozytoriumPATH 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

9.06.2017 10_cvs


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 copy) @@ -1 +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

9.06.2017 10_cvs


Tworzenie gałęzi

svn copy http://svn.example.com/repos/calc/trunk \ http://svn.example.com/repos/calc/branches/my-calc-branch \ -m "Creating a private branch of /calc/trunk."

svn checkout http://svn.example.com/repos/calc/branches/my-calc-branch

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!"

9.06.2017 10_cvs


Subversion na Windows

Serwer

https://sourceforge.net/projects/win32svn/ (https://sourceforge.net/projects/win32svn/) -VisualSVNServer (https://www.visualsvn.com/ (https://www.visualsvn.com/)) - darmowy w wersjistandardowej

Klient

TortoiseSVN (https://tortoisesvn.net/ (https://tortoisesvn.net/)) - integruje się z powłoką Windowsa(czyli m.in. Windows Explorerem)

VisualSVN (https://www.visualsvn.com/ (https://www.visualsvn.com/))

https://sourceforge.net/projects/win32svn/

https://www.visualsvn.com/

https://tortoisesvn.net/

https://www.visualsvn.com/

9.06.2017 10_cvs


Dobre praktyki zarządzania wersjamizatwierdzaj razem tylko powiązane zmianyzatwierdzaj zmiany często (małe zmiany łatwiej zrozumieć)nie zatwierdzaj zmian, jeśli nie są dokończoneprzetestuj, zanim zatwierdziszpisz wyczerpujące podsumowania zatwierdzanych zmian

9.06.2017 10_cvs
