System kontroli wersji Git

Transkrypt

1 System kontroli wersji Git dr inż. Sebastian Ernst Katedra Informatyki Stosowanej W prezentacji wykorzystano ilustracje z: Scott Chancon, Pro Git,

2 Systemy kontroli wersji Rejestracja historii zmian. Zatwierdzanie nowych wersji. Zarządzanie rozgałęzieniami. Rozwiązywanie konfliktów.

3 Tryby działania Lokalna kontrola wersji (np. rcs). Scentralizowana kontrola wersji (np. CVS, Subversion). Rozproszona kontrola wersji (np. git, Mercurial).

4 Tryby działania Lokalna kontrola wersji (np. rcs). Scentralizowana kontrola wersji (np. CVS, Subversion). Rozproszona kontrola wersji (np. git, Mercurial).

5 Tryby działania Lokalna kontrola wersji (np. rcs). Scentralizowana kontrola wersji (np. CVS, Subversion). Rozproszona kontrola wersji (np. git, Mercurial).

6 Rozproszona kontrola wersji Każdy węzeł posiada całe repozytorium (z całą historią). Kontrola dostępu tylko na poziomie całego repozytorium. Istotny dobór odpowiedniej granulacji repozytoriów.

7 Struktura repozytorium git Typowe repozytorium składa się z: kopii roboczej (pliki i foldery), ukrytego katalogu.git zawierającego właściwe repozytorium (kolejne wersje, gałęzie). Utworzenie repozytorium zakotwiczonego w danym katalogu: git init

8 Przechowywanie danych Tradycyjny system kontroli wersji: Git:

9 Oznaczenia wersji 2e1a59f9e062019e83faa36b2d314c67d1d f6a956591ef80979c957d7fc5a a40c9b aea3b733b81d c198e48bbd3506f1ec95d 2945d9df1c50153cdbb3bebcdc7c191b73d4a9be d016e55316c0724cd339ec25596f2b6d305c0608

10 Operacje lokalne Checkout pobranie określonej wersji (lub gałęzi) z repozytorium. Stage umieszczenie pliku/ plików w przechowalni (ang. staging area). Commit zatwierdzenie zawartości przechowalni jako nowej wersji.

11 Pierwsze repozytorium Inicjalizacja nowego repozytorium w bieżącym katalogu: $ git init Dodanie kilku plików: $ git add *.c $ git add README Zatwierdzenie wersji: $ git commit -m pierwsza wersja

12 Cykl życia plików Możliwe wartości: untracked pliki w obszarze kopii roboczej, ale nie śledzone przez git, unmodified nie zmienione względem poprzedniej wersji, modified pliki zmienione, ale nie umieszczone w przechowalni do zatwierdzenia, staged przeznaczone do zatwierdzenia. Sprawdzanie stanu: $ git status

13 Wyświetlanie różnic i historii Różnice w zmienionych plikach: $ git diff Różnice w plikach w poczekalni: $ git diff --staged Wyświetlanie historii: $ git log

14 Zatwierdzanie zmian Zatwierdzenie zmian we wszystkich plikach w poczekalni: $ git commit -m opis Zatwierdzenie zmian we wszystkich zmodyfikowanych plikach: $ git commit -a -m opis

15 Cofanie zmian Modyfikacja ostatniej zatwierdzonej wersji: $ git commit -m 'initial commit' $ git add forgotten_file $ git commit --amend Usuwanie pliku z przechowalni: $ git reset HEAD benchmarks.rb Przywracanie ostatnio zatwierdzonej wersji pliku: $ git checkout -- benchmarks.rb

16 Gałęzie (branches) Każda zatwierdzona wersja zawiera m.in. wskaźnik do wersji, na której jest oparta. Gałąź to po prostu wskaźnik ja jedną z zatwierdzonych wersji. Każde repozytorium posiada domyślnie jedną gałąź o nazwie master.

17 Tworzenie gałęzi Nową gałąź (np. o nazwie testing) utworzyć można przy pomocy polecenia: $ git branch testing

18 Przełączanie gałęzi Utworzona gałąź nie staje się automatycznie gałęzią aktualną pozostaje nią gałąź master. Aktualną gałąź określa wskaźnik HEAD.

19 Przełączanie gałęzi Aby przełączyć aktualną gałąź: $ git checkout testing

20 Rozłączenie historii Jeżeli w każdej gałęzi dokonamy niezależnych zmian, historia repozytorium ulega rozłączeniu:

21 Scalanie gałęzi (merging) Operacja scalania polega na scaleniu wersji, na którą wskazuje określona gałąź z wersją, na którą wskazuje ta aktualnie wybrana: $ git merge nazwa_galezi Najczęściej kończy się w jeden z trzech sposobów: 1. Przesunięcie wskaźnika (fast-forward). 2. Automatyczne scalenie (recursive merge). 3. Wygenerowanie konfliktu.

22 Scalanie: fast-forward

23 Scalenie: recursive merge

24 Scalanie: konflikty Miejsca w plikach, których nie udało się scalić automatycznie, oznaczane są znacznikami zawierającymi obie konfliktujące wersje. Użytkownik musi wyczyścić pliki i ponownie wykonać operację commit.

25 Praca rozproszona Każda maszyna może komunikować się z dowolną liczbą innych maszyn (ang. remotes) posiadających to samo repozytorium. Typowym scenariuszem jest praca w topologii gwiazdy, a jedyny remote nosi wtedy nazwę origin. x

26 Sposoby połączenia z serwerem Protokół Git HTTP(S) SSH

27 Wymiana danych z serwerem Utworzenie lokalnego repozytorium na podstawie repozytorium z serwera: $ git clone <adres URL> Wysłanie swoich zmian (commitów) na serwer: $ git push origin master Pobranie nowych commitów z serwera jako osobną gałąź (rzadko stosowane): $ git fetch Pobranie nowych commitów z serwera i wykonanie scalenia (pull = fetch + merge): $ git pull

28 Systemy zarządzania repozytoriami Git w KIS RedMine: logowanie przy użyciu danych z Poczty AGH lub lokalnych nieograniczony dostęp spoza AGH i sieci AGH przeznaczenie przede wszystkim do projektów badawczych GitLab: logowanie przy użyciu lokalnych danych uwierzytelniających maszyna za firewallem AGH przeznaczenie przede wszystkim do projektów studenckich, prac dyplomowych