Git. Rozproszony system kontroli wersji. Opis poleceń i konfiguracji na Windows.

[b]Instalacja na Windows[/b] Git w wersji portable na Windows można pobrać stąd: PortableGit-1.7.4-preview20110204.7z http://code.google.com/p/msysgit/downloads/list Zawartość paczki wrzucamy do stworzonego przez nas katalogu: C:PortableGit Teraz należy dodać do zmiennych środowiskowych (a dokładnie do zmiennej PATH) ścieżkę C:PortableGit Robimy to klikając PPM->Komputer->Właściwości->Zaawansowane ustawienia systemu->(zakładka Zaawansowane) i wybieramy button Zmienne środowiskowe -> Wybieramy PATH i edytuj -> W polu wartość zmiennej na końcu dopisujemy średnik ; oraz ścieżkę C:PortableGit Zatwierdzamy zmiany. Teraz aby sprawdzić czy Git działa wchodzimy do Uruchom -> cmd -> wpisujemy w oknie konsoli git –version [code=bash]C:UsersArtur>git –version git version 1.

Kup dostęp do treści Dodaj artykuł aby odblokować treść

[b]Instalacja na Windows[/b] Git w wersji portable na Windows można pobrać stąd: PortableGit-1.7.4-preview20110204.7z http://code.google.com/p/msysgit/downloads/list

Zawartość paczki wrzucamy do stworzonego przez nas katalogu: C:PortableGit Teraz należy dodać do zmiennych środowiskowych (a dokładnie do zmiennej PATH) ścieżkę C:PortableGit Robimy to klikając PPM->Komputer->Właściwości->Zaawansowane ustawienia systemu->(zakładka Zaawansowane) i wybieramy button Zmienne środowiskowe -> Wybieramy PATH i edytuj -> W polu wartość zmiennej na końcu dopisujemy średnik ; oraz ścieżkę C:PortableGit Zatwierdzamy zmiany.

Teraz aby sprawdzić czy Git działa wchodzimy do Uruchom -> cmd -> wpisujemy w oknie konsoli git –version [code=bash]C:UsersArtur>git –version git version 1.7.4.msysgit.0[/code]

Ściągawka (english), może się przydać (kilka prostych poleceń): http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html

[b]Opis podstawowych poleceń[/b] // ustawiamy informacje o uzytkowniku [i]git config –global user.name “Artur” git config –global user.email you@yourdomain.example.com[/i]

[i]git init[/i] // tworzy repozytorium w katalogu w ktorym sie znajdujemy

[i]git add .[/i] // dodaje wszystkie pliki w katalogu do repozytorium

[i]git commit -a -m “Pierwszy commit”[/i] // wykonujemy zapis aktualnej wersji projektu

[i]git branch[/i] // wyswietla wszystkie gałęzie rozwojowe (gałąź na której pracujemy jest oznaczona * i zielonym kolorem)

[i]git branch menu1[/i] // tworzy gałąź rozwojową o nazwie menu1 na podstawie danych z gałęzi na której aktualnie pracujemy

[i]git checkout menu1[/i] // przełączamy się na gałąź menu1

[i]git checkout -b menu2[/i] // tworzy gałąź menu2 jeśli nie istnieje, a następnie na nią zostajemy przełączeni

[i]gitk[/i] // wyświetla graficzną prezentacje drzewa gałęzi od korzenia do gałęzi na której pracujemy (odgałęzienia nie są wyświetlane)

[i]gitk –all[/i] // wyświetla graficzną prezentacje drzewa WSZYSTKICH gałęzi

[i]git status[/i] //pokaze pliki ktore sie zmienily, ktore nie dodalismy jeszcze do repozytorium

[i]git log[/i] // pokaze ostatnio wykonane commity z gałęzi na której aktualnie pracujemy

[i]git log -p[/i] // pokaze co zmienilo sie w plikach, mozna zamiast tego uzywac gitk

// Łączenie gałęzi. Gałąź na której pracujemy łączymy z gałęzią experimental. // Wynik łączenia zachowywany jest na gałęzi na której aktualnie pracowaliśmy [i]git merge experimental[/i] // po łączeniu należy wykonać commit // jeśli wystąpi konflikt należy ręcznie edytować plik z konfliktem. W tym pliku git wstawi specjalne oznaczenia ««<HEAD // w miejsca gdzie występują konflikty. Nalezy te miejsca edytować samodzielnie i usąc komentarze git’a // gdy naprawimy konflikt mozemy wykonac commit

// wyświetla różnice w plikach jakie zrobilismy od ostatniego commita. UWAGA! Tutaj nie są porownywane dwa ostatnie commity // tylko zmiany jakie wprowadzilismy teraz w plikach w stosunku do ostatniego commita. // (git diff will show you any changes that you’ve made but not yet added to the index.) [i]git diff[/i]

// exportowanie danej gałęzi. newbranch to gałąź którą eksportujemy do paczki [i]git archive newbranch –format zip –output paczka.zip[/i]

// Cofanie się do danego commita // Poleceniem gitk lub git log sprawdzamy liste comittow i kopiujemy SH1 ID danego commita. // Poniższe polecenie cofa do wybranego commita [i]git reset –hard 88e432f3b60b96c1e8c3646e784048586a59597e[/i]

// różne polecenia dodawania plikow do repozytorium [i]git add -A[/i] // stages All [i]git add .[/i] // stages new and modified, without deleted [i]git add -u[/i] // stages modified and updated, without new

// Ignorowane pliki/typy plików należy podać w: [i].git/info/exclude[/i]

// Usuwanie plików z repozytorium w sposób rekursywny. Plik kasowany jest rowniez z katalogu projektu [i]git rm *.txt -r[/i]

[b]Przydatne polecenia:[/b] // Pokazuje w których plikach nastapiły zmiany między dwoma wybranymi commitami: [i]git diff commit commit –name-only[/i] // w miejsce commit wstawiamy jego hash SHA np. [i]git diff f98a94fa686034bbcd5b4cb483476e56ffe891e0 1a25f69e146206ada82a9afbc6d0728c140f5787 –name-only[/i]

// wyświetla zmiany między ostatnimi dwoma commitami [i]git diff HEAD^ HEAD[/i] // opcja –name-only pokazuje tylko nazwy plików [i]git diff HEAD^ HEAD –name-only[/i]

// tworzy archiwum files.zip zawierające pliki, które zmienił się w ostatnich dwóch commitach. [i]git archive -o files.zip HEAD $(git diff HEAD^ HEAD –name-only)[/i]

// w tym wypadku pominięte zostaną pliki, które zostały usunięte co pozwoli poprawnie zbudować archiwum. // więcej info: http://www.kernel.org/pub/software/scm/git/docs/git-diff.html [i]git archive -o files.zip HEAD $(git diff HEAD^ HEAD –name-only –diff-filter=“A|C|M|R|T|U|X|B”)[/i]

// tworzy archiwum files.zip zawierające pliki, które zmienił się między dwoma commitami o zadanych hashach. // w miejsce commit1/2 podajemy jego hash SHA1 // commit1 to nowszy commit, a commit2 to starszy. // paczka będzie zawierać pliki, które zostały zmodyfikowane/stworzone od czasu commit2 do commit1 [i]git archive -o files.zip HEAD $(git diff commit1 commit2 –name-only)[/i]

// Pamiętać, że zanim robimy commit to trzeba dodać nowe pliki do repo. [i]git add -A[/i]

[b]# Scenariusz pracy. Podstawowe instrukcje do GIT.[/b]

Przypadek A

Jeśli zmienimy coś w projekcie i/lub dodamy nowe pliki do niego. Wpisujemy: $ git status Pokaże nam pliki na czerwono oraz te które są nowo dodane i nie są jeszcze śledzone przez system kontroli wersji GIT.

Aby te pliki były śledzone należy wpisać: $ git add -A (Wskazówka: Git nie śledzi pustych katalogów. Aby śledzić pusty katalog należy stworzyć w nim pusty plik o nazwie .gitignore)

Ponownie wpisujemy polecenie: $ git status Teraz widzimy, że wszystkie pliki są na zielono. Możemy zatem wykonać commit (commit czyli zapis stanu projektu w danym czasie, taki snapshot).

Aby wykonać commit wpisujemy: git commit -m "Opis commita np. dodałem nowe obrazki i zmieniłem wygląd strony logowania."

Teraz możemy wpisać: gitk Otworzy nam się okno w którym widzimy listę wszystkich commitów jakie zostały dokonane w repozytorium. Po zaznaczeniu danego commita widzimy jakie pliki zostały zmienione od poprzedniego commita. Widać również, które linie kodu zostały dodane/usunięte z danego pliku. Zamykamy okno.

Przypadek B.1

Chcemy wysłać zmiany z naszego lokalnego repo do repo na serwerze bitbucket. Wpisujemy polecenie: $ git push -u origin master oznacza to, że wysyłamy zawartość gałęzi master z naszego lokalnego repozytorium do origin, gdzie origin to alias dla adresu repozytorium znajdującego się na bitbucket. Zostaniemy poproszeni o podanie hasła do naszego klucza prywatnego rsa aby móc poprawnie zweryfikować, że uprawniony użytkownik wysyła zmiany do repozytorium na bitbucket.

Przypadek B.2

Co jeżeli ktoś zmienił coś w projekcie w głównym repozytorium na bitbucket? Wtedy nie możemy wykonac poprzedniego polecenia git push ponieważ otrzymamy ostrzeżenie. W takim wypadku musimy najpierw pobrać zmiany z repo na bitbucket i połączyć kod z naszym lokalnym kodem. Wpisujemy polecenie: $ git pull origin master Polecenie oznacza pobierz zmiany z origin (czyli z bitbucket) i połącz te zmiany z moim kodem znajdującym się w mojej lokalnej gałęzi master. Jeśli przebiegnie wszystko pomyślnie to w naszym lokalnym repo będziemy mieć połączony kod. Jeśli będą jakieś konflikty między plikami to git nam zasygnalizuje w których plikach wykrył konflikt. Należy wtedy te pliki poprawić (znajdą się w nich dodane przez GIT specjalne komentarze oznaczające gdzie są konflikty). Usuwamy komentarze o błędach z plików i poprawiamy kod na taki jak uważamy. Teraz możemy zapisać zmiany: $ git commit -m "Połączyłem kod z origin z moim master. Usunąłem konflikty plików." I dopiero teraz możemy wysłać zmiany na główne repo bitbucket. $ git push -u origin master

Przypadek C

Uczymy się pracować na gałęziach. Aby zobaczyć jakie mamy gałęzie w repo lokalnym wpisujemy polecenie: $ git branch Nazwa gałęzi na której się znajdujemy będzie miała *gwiazdkę przed nazwą. Wskazówka: Oprócz tego nazwa gałęzi na której się znajdujemy jest wyświetlana przed znakiem zachęty zaraz po adresie katalogu w którym jesteśmy.

Aby stworzyć nową gałąź wpisujemy: $ git branch test Gdzie test to nazwa naszej gałęzi. Gałąź test będzie zawierać dokładnie takie same pliki jak w gałęzi master w chwili gdy wpialiśmy polecenie git branch test.

Przełączamy się na gałąź test wpisując: $ git checkout test Teraz edytując pliki naszego projektu dodajemy jakieś nowe funkcje do niego. Po czym wykonujemy commit aby zapisać zmiany w gałęzi test.

Teraz najciekawsze gdy już skończymy prace nad nowymi funkcjami na gałęzi test i chcemy aby te funkcje zostały wdrożone w głównym projekcie, w takim wypadku musimy połączyć naszą gałąź test z główną gałęzią master. W tym celu musimy się upewnić że zapisaliśmy wszystkie zmiany w gałęzi test. Wpisujemy $ git status Jeśli nie ma żadnych plików które oczekują na commit to możemy przejść dalej. Natomiast jeśli wyświetlają się na czerwono jakieś pliki, które jeszcze nie zapisaliśmy commitem to musimy zrobić commit.

Łączymy gałąź test z master. W tym celu musimy przejść na gałąź master: $ git checkout master A następnie wykonać połączenie kodu z test z kodem w master. W efekcie master będzie zawierać wszystkie zmiany dodane w test. $ git merge test Efekt polecenie to połączenie test z master. (WAŻNE: Gałąź test jest łączona z gałęzią na której się aktualnie znajdujemy. Uprzednio przeszliśmy na gałąź master wykonują $ git checkout master)