18 09 10 Użycie systemu kontroli wersji Git z Wordpresem

Jak zawsze dodany przez : Sylwek, komentarze: ( 0 )

Dziś będzie kilka słów na temat kontorli wersji projektu tworzonego na Wordpresie. Witryny budowane z pomocą tego systemu zarządzania treścią, z punktu widzenia kontroli wersji, nie różnią się znacznie od innych projektów programistycznych. Do kontroli kodu projektu w tym przypadku zostanie wykorzystany system Git.

Ten wpis zakłada podstawową znajomość interfejsu linii poleceń dystrybucji Linuxa. Niektóre komendy użyte we wpiesie są specyficzne dla Debiana i Ubuntu.

Co to jest Git ?

Git jest jednym z nowszych systemów kontroli wersji. Autorem projektu jest Linus Torvalds. Tak, ten sam, który odpowiada za powstanie jądra Linux. System opublikowano na licencji GPLv2 co oznacza, że każdy może z niego swobodnie korzystać. Git w większości przypadków jest ogólnie dostępny w repozytoriach distro opartych na jądrze Linuxa.

Instalacja Gita

Aby sprawdzić czy Git jest zainstalowany w systemie, w konsoli należy wpisać komendę:

which git

Jeżli ścieżka do pliku wykonywalnego git w katalogu /usr/bin/ nie istnieje, wówczas konieczna jest instalacja oprogramowania z repozytorium.

Aby zainstalować Git z repozytorium Ubuntu należy wpisać :

sudo aptitude install git-core

To tyle w kwestii instalacji Gita.

Praca z Gitem

Mając zainstalowany system kontroli wersji, można zająć się samym projektem witryny.

Załóżmy, że projekt nosi nazwę example.local, a świeża instalacja Wordpresa znajduje się w katalogu:

/home/twoja_nazwa_użytkownika/www/example.local/public_html/

i katalog ten jest dostępny dla lokalnego serwera.

Aby utworzyć nowe repozytorium Gita dla projektu należy przjść do katalogu /home/twoja_nazwa_użytkownika/www/example.local/

i wpisać następujące komendy w linii poleceń:

git init
git add .
git commit -a

Pierwsza z komend inicjalizuje nowe repozytorium, druga dodaje wszystki pliki w drzewie pod katalogiem z repozytorium do indexu, trzecia powoduje zapisanie zmian w repozytorium. Podczas zapisu otworzy się domyślny edytor tekstu, co daje możliwość zapisania własnej notatki na temat zmian w projekcie. Ponieważ zmian jeszcze nie ma. Wpisujemy cokolwiek lub "pierwszy zapis". Po zamknięciu edytora nastąpi zapisanie zmian w repozytorium.

Repozytorium Gita rezyduje w projekcie, czyli w katalogu /home/twoja_nazwa_użytkownika/www/example.local/.git. gdzie znajdują się wszystkie pliki.

Mając na koncie pierwszy zapis w repozytorium czas zająć się projektem strony. Zanim jednak zaczniemy coś zmieniać w plikach, dobrze jest utworzyć nową gałąź, na której będzie można eksperymentować z kodem.

Domyślnie Git posiada jedną gałąć ( master ), dla której zapisywane są wszystkie zmiany. Ponieważ nie chcemy modyfikować jedynej wersji oprogramowania jaką aktualnie mamy, tworzymy kolejną gałąź, która będzie nosić nazwę experimental. Utworzenie nowej gałęzi w Git wygląda jak następuje:

git branch experimental

Aby zobaczyć wszystkie dostępne komendy należy wpisać:

git branch

Gałęzie zostaną wyświetlone jedna pod drugą. Ta, na której aktualnie pracujemy, będzie oznaczona gwizadką. Póki co jesteśmy na master, aby przejść na experimental wpisujemy w konsoli:

git checkout experimental

W tym momecie, niezależnie na której gałęzi jesteśmy, mamy dwie identyczne drzewa z plikami projektu. Możemy wreszcie bezpiecznie zacząć coś zmieniać w samym projekcie.

Po zmianach wykonanych w plikach lub dodaniu nowych należy uaktualnić repozytorium. Zanim jednak to, załóżmy, że chcemy podejrzeć status drzewa plików i katalogów na którym pracujemy. Możemy tego dokonać z pomocą komendy:

git status

Git wyświetli w konsoli wszystkie pliki, które zmieniły swoją zawartość i te, które nie są aktualnie śledzone. Pliki, które nie są śledzone należy dodać przed dokonanie wpisu do repozytorium.

git add --all
git commit -a

Podobnie jak przy poprzednim zapisie, otworzy nam się okno domyślnego edytora tekstu, gdzie możemy dodać opis zmian w projekcie według własnego uznania. Zamykamy edytor i voila. Zmiany zostały zapisane. W tym momencie obie gałęzie, tj. master i experimental różnią się od siebie. Ta pierwsza odnosi się do wersji projektu przed przejściem na gałąź experimental. Gałąź experimental natomiast zawiera aktualną wersję projektu. Oznacza to, że gdy wrócimy do gałęzi master, kodu, który zapisaliśmy w plikach podczas pracy na experimental nie będzie. Załóżmy jednak, że nie powracamy jeszcze do gałęzi master ale kontynuujemy rozwijanie projektu na experimental.

Za każdym razem gdy dokonujemy większych zmian w plikach lub katalogach, wykonujemy zapis do repozytorium metodą jak powyżej.

Aby sprawdzić co się zmieniło w strukturze projektu od ostatniego zapisu należy wpisać komendę:

git whatchanged

Komenda powyżej wyświetla historię zapisów do repozytorium wraz z różnicami jakie wprowadza każdy z nich.

Jeżeli chcemy zobaczyć dodatkowe szczegóły zmian ( włącznie z tymi odnoszącymi się do zawartości plikaów), wpisujemy:

  git whatchanged -p

Jeżeli chcemy zobaczyć zmiany, jakie dokonały się podczas pięciu ostatnie zapisów do repozytorium, wpisujemy:

  git whatchanged -n5

Jeżeli chcemy zobaczyć zmiany jakie zaszły między ostatnim zapisem do teraz, wpisujemy:

git diff

Załóżmy, że po kliku dniach pracy dochodzimy do wniosku, że mamy wersję 0.1 projektu.
To jest właściwy czas na to aby wrócić do gałęzi master.

git checkout master

Upss … cofneliśmy się w czasie, wszystkie zmiany w projekcie znikły. Aby je odzyskać należy połączyć gałąź master z experimental.

git merge experimental

W tym momencie oba drzewa katalogów projektu znów powinny byc identyczne.
Nie pozostaje nic innego jak dodać taga obwieszczającego, że oto osiągneliśmy wersję 0.1 naszego projektu.

git tag 0.1 -a

Po wpisaiu powyższej komendy, kolejny raz otworzy nam się edytor tekstu gdzie będziemy mogli podsumować osiągnięcia i zmiany w wersji 0.1.

Po zapisaniu zmian pozostaje utworzyć gdzieś na dysku katalog na wszystkie wersje projektu, skopiować katalog public_html/ projektu i wrzucić bazę danych wordpresa do pliku (zakładam, że baza danych ma nazwę example_local) .

cd ~
mkdir versions
mkdir versions/example.local
mkdir versions/example.local/0.1

cd versions/example.local/0.1/

rsync -a /home/twoja_nazwa_użytkownika/www/example.local/public_html ./

mysqldump example_loca > exaple.local.sql

Załóżmy, że teraz chcemy zacząć pracę nad wersją 0.2. Zanim jednak dotkniemy jakiegokolwiek pliku w projekcie należy przypomnieć sobie, na której gałęzi jesteśmy:

git branch

W odróżnieniu od experimental, gałąź master nie służ do zmian i eksperymentów z kodem. Prechodzimy więc na naszą eksperymentalną gałąź i na niej kontynuujemy prace w sposób jak robiliśmy to poprzednio zapisując zmiany w repozytorium od czasu do czasu.

W przypadku gdy niechcący zapiszemy zmiany w gałęzi master, istnieje możliwość cofnięcia się do poprzedniego zapisu repozytorium z pomocą komendy reset.

git reset --hard 0.1

Odradzam robienie zmian w plikach na kilku gałęziach jednocześnie. Jak łatwo sobie wyobrazić, próba połączenia ich z master będzie prowadzić do błędów. Po skończeniu pewnej części pracy, zapisaniu zmian i połączeiu gałęzi, na której normalnie pracujemy z master, można ją usunąć.

Gałąź experimental można skasować za pomocą komendy:

git branch -d experimental

Gdzie szukać pomocy

Komendy Gita można zobaczyć wpisując w konsoli

git help

Opisy poszczególnych komend można obejrzeć wpisując

git help komenda

lub

man git-komenda

Więcej o systemie kontroli wersji Git można poczytać pod tym adresem. Lektura zdecydowanie obowiązkowa.

Powyższy wpis, choć dość długi, nawet w minimalnym stopniu nie wyczerpuje tematu. Git jest rozbudowanym i elastycznym systemem, który znalazł swoje zastosowanie w takich projektach jak Ruby on Rails, Clojure, GIMP, Linux, Fedora, Digg czy GNOME. Osobiście używam go do niemal wszystkiego w skład czego wchodzi więcej niż kilka plików.

Kategorie: wordpress
Tagi: git