System kontroli wersji Git

System kontroli wersji Git dr inż. Sebastian Ernst Katedra Informatyki Stosowanej W prezentacji wykorzystano ilustracje z: Scott Chancon, Pro Git, http://git-scm.com/book

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

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

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.

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

Przechowywanie danych Tradycyjny system kontroli wersji: Git:

Oznaczenia wersji 2e1a59f9e062019e83faa36b2d314c67d1d68510 3f6a956591ef80979c957d7fc5a5155505a40c9b aea3b733b81d1099945c198e48bbd3506f1ec95d 2945d9df1c50153cdbb3bebcdc7c191b73d4a9be d016e55316c0724cd339ec25596f2b6d305c0608

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.

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

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

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

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

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

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.

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

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

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

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

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.

Scalanie: fast-forward

Scalenie: recursive merge

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.

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

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

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

Systemy zarządzania repozytoriami Git w KIS RedMine: https://prj.kis.agh.edu.pl 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: https://gitlab.kis.agh.edu.pl logowanie przy użyciu lokalnych danych uwierzytelniających maszyna za firewallem AGH przeznaczenie przede wszystkim do projektów studenckich, prac dyplomowych