SVN :: BZR :: GIT

Systemy kontroli wersji

Narzędzia tego typu używane są głównie przez programistów, ale mogą się przydać także np. administratorom do wersjonowania konfiguracji.

SVN

Subversion (czyli svn) jest systemem kontroli wersji z centralnym repozytorium.

# pobranie repozytorium
svn checkout

# aktualizacja
svn update

# dodawanie i usuiwaniw plików
svn add|rm

# wysyłanie zmian a serwer
svn commit

Podstawowymi narzędziami są komendy svn (do zarządzania kopią roboczą) i svnadmin (do zarządzania repozytorium po stronie serwera. Kilka przykładów użycia:

URL może wskazywać dostęp np. w oparciu o ssh - svn+ssh://host/katalog/repo.

BZR

Bazaar (czyli bzr) jest rozproszonym systemem kontroli wersji mogącym jednak funkcjonować jako klasyczny system z centralnym repozytorium.

obsluga branchów

# utworzenie mirrora wskazanego branch'a
bzr branch

# aktualizacja (lub utworzenie) wskazanego mirrora obecnego brancha
bzr push

# zamiana bierzącego brancha w mirror wskazanego brancha (aktualizacja brancha)
bzr pull 

# warto wspomnieć że:
# * podobny efekt jak pull daje merge+commit, przy czym zapewnia ono zachowanie hierarchii w historii zmian
# * branch'e mogą operować na pojedyńczym repozytorium (shared repository) - patrz bzr init_repo

obsluga kopii roboczej

# utworzenie kopii roboczej
bzr checkout
# w ogólności możliwe jest tworzenie kopii z dala od brancha (np. na innej maszynie),
# w przypadku kożystania z checkout'ów działania komend takich jak update, commit
# odnoszą się do macierzystego brancha (działanie bzr przypomina wtedy działanie svn)
# możliwe jest także przełączanie macierzystego brancha dla checkotów (komenda switch)
# a także komitowanie lokalne (opcja --local w commit) lub nawet odłączenie i ponowne
# przyłączenie do brancha (unbind / bind) - w zasaadzie konwersjac checkout/branch

# scalanie zmian z innego brancha / mirrora brancha
bzr merge

# dodawanie usówanie i przenoszenie plików
bzr add|rm|mv

# akceptowanie zmian wprowadzonych kopii roboczej (do związanego z nią brancha)
# bzr commit -m "Opis zmian"

# aktualizacja kopii roboczej
bzr update

# cofanie kopii roboczej do stanu zgodnego z branchem
bzr revert

# warto wspomnieć że (w odróżnieniu od svn):
# * `bzr add *` w katalogu głównym bardzo ładnie dodaje wsystkie nowe obiekty
#    w całym drzwie podkatalogów (działa rekursywnie i po cichu ignoruje
#    obecne już w repo obiekty)
# * `bzr mv` przenosi obiekt w repozytorium a nie usuwa go i tworzy od nowa
#    (istotne przy zmianach nazw/położeń dużych plików)

odzyskiwanie starych wersji

bzr log
bzr -r $REVNUM ls
bzr -r $REVNUM cat

inne

bzr diff
bzr status
bzr info
bzr export DST
bzr init
bzr whoami "Imie Nazwisko <adres@mailowy>"

GIT

Git jest rozproszonym systemem kontroli wersji.

utworzenie pustego repozytorium

mkdir -p NAME && cd NAME && git init

utworzenie kopii repozytorium (bez checkout-u / bez katalogu roboczego)

# metoda wypychająca
#  chyba nie istnieje

# metoda wciągająca
git clone -n ssh://user@host/sciezka/do/repozytorium NEWREPO

aktualizacja kopii repozytorium

# metoda wypychająca
git push ssh://user@host/sciezka/do/repozytorium

# metoda wciągająca
#  -> tworzy katalog roboczy
#  -> w pewnych sytuacjach robi jawnego merge
#  -> automatycznie commituje jeżeli nie ma konfliktów
#  -> pozwala na połączenie dwóch zupełnie niezależnych repozytoriów w jedno
#     (niestety robi to bez wymagania jakiegokolwiek potwierdzenia)
git pull ssh://user@host/sciezka/do/repozytorium master
# mozna to takze zrobic w dwoch krokach jako "fetch" i "merge"

Jeżeli mamy poprawnie zdefiniowane w .git/config wpisy: [remote "origin"] i [branch "master"] (jest tak np. gdy nasze repo powstało poprzez "clone" repo z którego chcemy robić pull) to zamiast powyżej pokazanej pełnego wywołania pull możemy używać krótszej (i bezpieczniejszej - bez ryzyka wciągnięcia innego repozytorium) bezargumentowej postaci: git pull.

Możemy też ustawić automatyczne robienie push po wykonaniu commit poprzez utworzenie stosownego pliku .git/hooks/post-commit (po stronie robiącej push), plik musi mieć atrybut wykonalności. Jeżeli chcemy żeby push działało do repozytorium na którym mamy utworzoną kopie roboczą w .git/config (po stronie przyjmującej push) należy ustawić:

[receive]                                                                                  
	denyCurrentBranch = warn

obsługa katalogu roboczego w oparciu o lokalne repozytorium

# aktualizacja (reset kopi roboczej do stanu repozytorium)
# UWAGA: lokalne zmiany zostana bezpowrotnie utracone
git checkout -f

# dodawanie plikow do poczekalni
git add PLIK

# usuwanie plikow z poczekalni
git reset HEAD PLIK


# usuwanie pliku z repozytorium
git rm PLIK
# zadziala także usunięcie z kopi roboczej i "git add" lub git "commit -a"

# zmiana nazwy pliku (jest to rownowazne z git rm ...; git add ...)
git mv


# podglad zmian kopi roboczej i poczekalni
git status          # aby ignorować jakieś niedodane do repozytorium pliki katalogi należy skorzystać z pliku .gitignore
git diff            # roznica kopi roboczej do poczekalni
git diff --cached   # roznica poczekalni do ostatniej rewizji

# zatwierdzanie zmian z poczekalni (tworzenie rewizji)
# git commit -a [-m "OPIS"]

# poprawianie ostatniej rewizji
git commit --amend
# jezeli zmiany zostaly wypchniete to takze:
git push origin HEAD --force


# przegladanie historii zmian
git log --graph --name-status [PLIK]
git log [-p] [PLIK]

# obejrzenie starej wersji pliku
git revert -n 42200238cbd4c862a0b6ce919e5a4dc2a47cc20b
git ls-tree REV
git cat-file blob file-SHA1
git show rev:path

Gałęzie

# tworzenie nowej gałęzi
git branch nazwa

# utworzenie galezi po stronie zdalnej
git push --set-upstream origin nazwa

# pobranie / aktualizcja informacji (m.in.) o zdalnych galeziach
git fetch

# listowanie galezi
git branch -av

# przelaczanie sie pomiedzy galeziami (zmiany w kopi roboczej inie zostana utracone)
# (w przypadku konfliktu przed przelaczeniem bedzie koniecznosc ich zaakceptowania lub odrzucenia)
git checkout nazwa

# scalanie wskazanej galezi do aktualnej
git merge [zasob_zdalny] nazwa

łączenie dwóch rozforkowanych repozytów

Np. repozytoriów z github celem przygotowania pull request.

# to nie jest skrypt, a to nie są jego argumenty ...
REPO1_URL="adres URL repo podstawowego"
REPO2_URL="adres URL repo wlaczanego"
REPO2_NAME="moj_identyfikator_wlaczanego_repo"
PLIKI_DO_EDYCJI="pliki z konfliktami ktore bedziemy modyfikowac"

#
# POBRANIE OBU REPO
#
git clone $REPO1_URL repo_merge; cd repo_merge
git remote add -t master $REPO2_NAME $REPO2_URL
git remote
git fetch $REPO2_NAME


#
# POŁĄCZENIE OBU REPO JAKO OSOBNYCH BANCH'ÓW
#
git checkout $REPO2_NAME/master
git checkout -b from_$REPO2_NAME
git branch
git push -u origin from_$REPO2_NAME

# alternatywnie (od razu MERGE):
#   git merge $REPO2_NAME/master
# lub:
#   git rebase -i $REPO2_NAME/master; git status; FIX CONFLICTS; git add ...; git rebase --continue

#
# OPCJONALNE MODYFIKACJE DODATKOWEGO REPO UŁATWIAJĄCE MERGE (np. poprawki konca linii)
#
f=SCIEZKA/do/PLIKU/do.POPRAWIENIA && mv $f /tmp/fwsa && tr -d '\r' < /tmp/fwsa > $f
git commit -a -m "fix line endings in modified files"
git push

#
# MERGE
#
git checkout master
git merge from_$REPO2_NAME

#
# USUNIECIE KONFLIKTÓW I COMMIT
#
vi $PLIKI_DO_EDYCJI
git diff from_$REPO2_NAME $PLIKI_DO_EDYCJI
git add $PLIKI_DO_EDYCJI
git commit -a -m "merge linux keyboard changes from $REPO2_NAME"
git push

git branch -d from_$REPO2_NAME


Copyright (c) 1999-2015, Robert Paciorek (http://www.opcode.eu.org/), BSD/MIT-type license


Redystrybucja wersji źródłowych i wynikowych, po lub bez dokonywania modyfikacji JEST DOZWOLONA, pod warunkiem zachowania niniejszej informacji o prawach autorskich. Autor NIE ponosi JAKIEJKOLWIEK odpowiedzialności za skutki użytkowania tego dokumentu/programu oraz za wykorzystanie zawartych tu informacji.

This text/program is free document/software. Redistribution and use in source and binary forms, with or without modification, ARE PERMITTED provided save this copyright notice. This document/program is distributed WITHOUT any warranty, use at YOUR own risk.

Valid XHTML 1.1 Dokument ten (URL: http://www.opcode.eu.org/programing/more/systemy_kontroli_wersji) należy do serwisu OpCode. Autorem tej strony jest Robert Paciorek, wszelkie uwagi proszę kierować na adres e-mail serwisu: webmaster@opcode.eu.org.
Data ostatniej modyfikacji artykulu: '2016-07-25 06:38:14 (UTC)' (data ta może być zafałszowana niemerytorycznymi modyfikacjami artykułu).