Procesory osadzone ETD 7211 W8 – 25.11.2019 Maciej Rudek Programowanie tradcyjne (?) System kontroli wersji (VCS) VCS (ang. version/revision control system) - jest to oprogramowanie, którego głównym celem jest śledzenie zmian w tworzonym oprogramowaniu – kodzie źródłowym. Ponadto, może łączyć, zmiany w plikach, dokonane przez wielu programistów na raz w różnym czasie. VCS można podzielić ze względu na: architekturę oprogramowania, sposób oceny zmian, licencję. Historia systemów VCS 1972 r. – SCCS - System kontroli kodu źródłowego ang. Source Code Control System 1980 r. – RCS - System nadzorowania wydań ang. Revision Control System 2000 r. – CVS - Współbieżny system wersji ang. Concurrent Version System: 2001 r. – SVN system kontroli wersji ang. System Subversion 2005 r. – Git - globalny tropiciel informacji (ang. Global Information Tracker), Mercurial Podział systemów VCS Ze względu na działanie, VCS można podzielić na: • lokalne - zapis danych odbywa się jedynie na lokalnym komputerze • scentralizowane - architektura klient- serwer • rozproszone - architektura osoba do osoby (P2P) RCS (Revision Control System) Lokalny komputer wykorzystywany jest do kontrolowania wersji oprogramowania. • RCS • GNU Source Code Control System CVCS (Centralized Version Control System) - Scentralizowane systemy kontroli wersji – zewnętrzny, centralny serwer, przechowuje wszystkie wersje plików. Zaletą jest zarządzanie uprawnieniami z jednego miejsca, Jednak jest podatny na awarie. • CVS • Subversion - SVN • GNU CSSC • JEDI VCS DVCS (Distributed Version Control System) Rozproszone systemy kontroli wersji – pobierane jest całe repozytoriów a nie tylko zmiany. Każdy klient może pełnić rolę serwera i umożliwia pracę z wieloma różnymi serwerami na raz. System ten odporny jest na awarie. • Bazaar • Codeville • Darcs • Git • GNU Arch • Mercurial • Monotone Funkcje systemów kontroli wersji Funkcje systemu kontroli wersji • przechowywanie i kontrola dostępu do plików projektu, • Zapisywanie zmian w historii, • śledzenie zmian w poszczególnych plikach, • dokumentowanie wprowadzanych zmian w projekcie, • Śledzenie i tworzenia konfiguracji oprogramowania, • Udostępnianie innym użytkownikom kolejnych wersji poszczególnych plików –synchronizacja zmian, • kontrola rozwijania projektu, • usuwanie konfliktów pomiędzy wprowadzonymi zmianami. GIT – głupiec / ladaco… GIT powstał w 7 kwietnia 2005 roku przez Linusa Torvaldsa w celu wspomagania rozwoju jądra Linuxa. Prace nad GIT’em zostały rozpoczęte po zmianie warunków używania systemu BitKeeper. Do celów nowego systemu należały: • Szybkość • Prosta konstrukcja • Silne wsparcie dla nieliniowego rozwoju (tysięcy równoległych gałęzi) • Pełne rozproszenie • Wydajna obsługa dużych projektów – jądro Linuxa GIT - historia • 3 kwietnia 2005 – rozpoczęcie prac nad GIT’em • 6 kwietnia – ogłoszenie projektu • 7 kwietnia – obsługa kontroli wersji własnego projektu • 18 kwietnia – wykonanie łączenia gałęzi • 27 kwietnia – testowanie pod względem prędkości • 16 czerwca 2005 roku - Linux 2.6.12 był hostowany przez Gita. Zalety systemu GIT • ułatwianie prac w środowisku rozproszonym • zdolność do obsługi tysięcy wykonawców • szybkość i skuteczność działania • wymuszanie odpowiedzialności • stałość archiwum • wielotorowość prac rozwojowych • kompletność archiwów Podstawowe cechy: Większość systemów (np. CVS i Subversion) przechowuje informacje o nowej wersji jako różnicową listę zmian dla plików. GIT w lokalnej bazie przechowywane zmiany danych w formie migawki (ang. snapshot). Podstawowe cechy: Większość systemów (np. CVS i Subversion) przechowuje informacje o nowej wersji jako różnicową listę zmian dla plików. GIT w lokalnej bazie przechowywane zmiany danych w formie migawki (ang. snapshot). Podstawowe cechy: Większość operacji wykonywanych jest lokalnie. Co znacznie przyspiesza przeglądanie historii zmian plików i ich edycję. Dopiero na koniec pracy potrzebne jest połączenie z serwerem, w celu wysłania swojej pracy lub aktualizacji projektu z innymi użytkownikami. Przykładowo w Perforce, nie możesz wiele zdziałać bez połączenia z serwerem; w Subversion, albo CVS możesz edytować pliki, ale nie masz możliwości zatwierdzania zmian w repozytorium (ponieważ nie masz do niego dostępu). Podstawowe cechy: Wbudowany mechanizm spójności danych w postaci sumy kontrolnej, co pozwala na odnoszenie się do danego obiektu. Nie można zmienić treści pliku bez reakcji oprogramowania kontroli wersji. Mechanizmem wspomagającym jest zastosowanie sumy kontrolnej SHA-1. Jest to 40 znakowy łańcuch liczb szesnastkowych. Wylicza się go na podstawie treści pliku i struktury katalogów. Jakie są inne sumy kontrolne ? SHA1: 24b9da6552252 987aa493b52f8696cd6d 3b00373 Podstawowe cechy: W GIT plik może znajdować się w jednym z trzech stanów: zatwierdzony, zmodyfikowany i śledzony. • Zatwierdzony - dane zostały bezpiecznie zachowane w lokalnej bazie danych. • Zmodyfikowany - plik został zmieniony, ale zmiany nie zostały wprowadzone do bazy danych. • Śledzony - zmodyfikowany plik został przeznaczony do zatwierdzenia w bieżącej postaci w następnej operacji commit. Podstawowe cechy: Wyróżniamy trzy sekcje projektu: katalog GIT, katalog roboczy i przechowalnia (ang. stage) Git – podstawowe pojecia • repozytorium -‘kontener’ na określony zbiór kodu, najczęściej jeden projekt. Można rozróżnić repozytoria: origin, remote • branch – gałąź, rozwiązanie dla wykonywania oddzielnych zadań na projekcie • HEAD – wskaźnik na lokalną gałąź • working area / working directory / katalog roboczy – miejsce projektu z widocznymi zmianami. • master – zazwyczaj jest to nazwa głównej gałęzi • fork - kopia repozytorium; najczęściej rozwijana niezależnie - popularne w przypadku projektów open- source Czy znacie jakieś forki? https://en.wikipedia.org/wiki/Linux_distribution#/media/File:Linux_Distribution_Timeline.svg Git-Flow Git-Flow jest zbiorem rozszerzeń gita dostarczającym wysokopoziomowe operacje na repozytorium, wspierającym strategię rozgałęziania – autor: Vincent Driessen. Git-Flow https://nvie.com/posts/a-successful-git-branching-model/ Podstawowe pojęcia cz.2 • commit – opis zmian w projekcie • merge – łączenie wielu źródeł • pull/push – pobranie i wysłanie zmian do repozytorium • diff – sprawdzanie dokonanych zmian, Podstawowe polecenia • git init – tworzy nowe repozytorium • git config – globalne ustawienia GIT’a • git clone – pobiera zdalne repozytorium • git fetch – pobiera obiekty z innego repozytorium • git pull – pobiera i integruje zdalne repozytorium • git push – aktualizuje zdalne repozytorium • git status – pokazuje status katalogu roboczego i poczekalni • git add/rm/mv – dodaje/usuwa/przenosi plik • git commit – zapisuje zmiany do repo • git log – wyświetla logi z commit’a Podstawowe polecenia • git branch – wyświetla gałęzie • git checkout – przełączanie się między gałęziami • git merge – łączy ze sobą podane gałęzie • git rebase – przebudowanie gałęzi • git reset – RESET ! • git status – stan plików na gałęzi • git stash – zapisuje/odczytuje zmiany z przestrzeni • git diff – pokazuje dokonane zmiany Hosting Istnieje wiele popularnych serwisów wykorzystujących repozytorium GIT: • GitHub, • GitLab, • Bitbucket, • SourceForge, • Gitorious, • … Github.com https://github.com/ Github.com https://github.com/ Github.com https://github.com/maciej-PWr/myARM Klient GIT https://git-scm.com/downloads Git - konsola Git - konsola https://git-scm.com/book/pl/v2 Podstawowe operacje Integracja katalogi z GIT’em $ git init $ git clone https://github.com/maciej- PWr/myARM.git Podstawowe operacje https://github.com/maciej-PWr/myARM Podstawowe operacje Integracja katalogi z GIT’em https://github.com/maciej-PWr/myARM.git GIT + Linux Podstawowe obsługa Podstawowa obsługa $ git commit *** Please tell me who you are. Run git config --global user.email "[email protected]" git config --global user.name "Your Name" Co się stało Praca na dwóch mazynach $ git push GIT – konflikt wersji GIT – konflikt wersji Dlaczego są różnice? Gdzie są różnice? Liczba pustych linijek … GIT - naprawa GIT - naprawa Dwie nowe spacje Brak spacji w starym pliku […] <<<<<<< HEAD NOWE zmiany ======= Co powinniśmy zrobić? STARY plik >>>>>>> local:NoweRzeczy GIT - naprawa Kolejne kroki: • Zapisujemy zmiany • Wychodzimy z edycji plików • Przechodzimy do konsoli w celu akceptacji zmian GIT - naprawa GIT - naprawa GIT – co się stało GIT - naprawa $ git tig GIT - naprawa $ git tig Git diff $ git diff d49.. 75a.. GIT – pull –r (Win) Git branch Zmiany w plikach README, main README.md main.c Git branch Git branch $ git checkout -b iss53 $ git commit -a -m 'nowa stopka [#53]' $ git branch iss53 $ git checkout iss53 https://git-scm.com/book/pl/v1/Ga%C5%82%C4%99zie-Gita-Podstawy-rozga%C5%82%C4%99ziania-i-scalania Git branch $ git commit -a -m 'nowa stopka [#53]' $ git checkout master $ git checkout -b 'hotfix‚ $ [poprawki] $ git commit -a -m 'poprawiony’ https://git-scm.com/book/pl/v1/Ga%C5%82%C4%99zie-Gita-Podstawy-rozga%C5%82%C4%99ziania-i-scalania Git branch + merge $ git checkout master $ git checkout iss53 $ git merge hotfix $ vim index.html $ git commit -a -m 'skończona' https://git-scm.com/book/pl/v1/Ga%C5%82%C4%99zie-Gita-Podstawy-rozga%C5%82%C4%99ziania-i-scalania Git merge $ git checkout master $ git merge iss53 https://git-scm.com/book/pl/v1/Ga%C5%82%C4%99zie-Gita-Podstawy-rozga%C5%82%C4%99ziania-i-scalania Literatura • Włodzimierz Gajda, Git. Rozproszony system kontroli wersji • RICHARD E. SILVERMAN, GIT. LEKSYKON KIESZONKOWY • Peter Bell, Brent Beer, GitHub. Przyjazny przewodnik • Scott Chacon, Ben Straub, Pro