Git

Zeszłotygodniowy artykuł miał wprowadzić wszystkich niezaznajomionych z tematem kontroli wersji do świata, który z niej korzysta. Post omawiał ryzyko jakie płynie z niekorzystania z niej oraz podstawowe koncepty wykorzystywane przez Git, SVN i im podobne. Dzisiejszy wpis jest kontynuacją poprzedniego, a omówię w nim bardziej techniczną stronę korzystania z kontroli wersji.

Narzędzia

Niezależnie jaki system kontroli wersji wybierzesz, będziesz potrzebował narzędzi do korzystania z niego. Poniżej przedstawiam Ci niezbędne minimum, które pozwoli Ci używać kontroli wersji. Przypominam, że tak jak w całej serii, tak i tutaj skupiam się na systemie Git.

  • Oprogramowanie systemu kontroli wersji – żeby korzystać z Gita, musisz go zainstalować! Pobierzesz go stąd. Da Ci to możliwość do wykonywania komend w wierszu poleceń (cmd) w przypadku Windowsa oraz jego odpowiednikach na Linuxie i iOS. Jeżeli planujesz używać Gita w konsoli, pozostałe narzędzia nie powinny Cię interesować.
  • Graficzna obsługa kontroli wersji – dla wszystkich, którzy nie przepadają za wpisywaniem komend w konsoli istnieje wiele rozwiązań oferujących GUI dla kontroli wersji. Z tych dedykowanych dla Gita, miałem okazję korzystać z dwóch: Sourcetree, rozwijane przez firmę Atlassian oraz Git Kraken od Axosoft. Trudno opiniować, który z nich jest lepszy, bo różnią się nieznacznie pod względem funkcjonalności. Oba opakowują w końcu ten sam system w graficzny odpowiednik. Wybór zależy więc raczej od indywidualnych preferencji. Obiektywnie patrząc można jednak stwierdzić, że Git Kraken cechuje większa płynność działania. Najlepszą radą jednak będzie przetestowanie obu i wybranie tego, który uznasz za lepszy. A może znasz inny, który deklasuje pozostałe? Napisz o nim w komentarzu 🙂
  • Program do rozwiązywania konfliktów – zdarza się, że proces ten bywa dość skomplikowany i wymaga dodatkowego narzędzia. Pozwala ono na przejrzenie kodu i zdecydowanie o tym, jak rozwiązać problem. W sieci znajdziesz wiele rozwiązań. Np.: Git Kraken posiada swoje, całkiem niezłe narzędzie służące do tego celu. Możesz także wybrać aplikacje dedykowane do tego np.: KDiff3. Wybór tutaj również zależy od Twojego gustu- potestuj i wybierz coś dla siebie.

Zastosowanie w praktyce

Mając te trzy narzędzia jesteś w stanie wykorzystać potencjał kontroli wersji. Możesz teraz zacząć używać go w projekcie… No właśnie, ale jak to zrobić? Rozpisałem się na temat teorii, a wiedzy praktycznej z tego żadnej. Spokojnie, właśnie przyszedł czas na to. Oprócz aplikacji, które wymieniłem wyżej, potrzebujesz jeszcze serwera, przechowującego Twój kod. Głównym i najpopularniejszym narzędziem do tych celów jest GitHub. Ja natomiast korzystam głównie z jego alternatywy – Bitbucketa. Robię tak z tego względu, że już w darmowej wersji oferuje on możliwość tworzenia prywatnych repozytoriów. Na nim właśnie oprę swój przykład.

Zadania do wykonania po stronie serwera

Zaczniemy właśnie od stworzenia repozytorium na serwerze. Zakładam, że konto masz już utworzone. Kliknij na ikonę plusa po lewej stronie, a z otwartego menu wybierz opcję Repository. Ukaże się przed Tobą taki widok:

Tworzenie repozytorium

W tym miejscu możesz wybrać:

– nazwę

– zdecydować o prywatności/publiczności repozytorium

– wybrać rodzaj systemu kontroli wersji (Git/Mercurial)

Po zatwierdzeniu zobaczysz ekran główny swojego repo:

Tworzenie repozytorium

A teraz Git Kraken

Najważniejszy dla Ciebie jest tutaj adres URL. Będzie Ci on potrzebny podczas klonowania repozytorium do lokalnej kopii, co jest kolejnym elementem na liście rzeczy do zrobienia. Do tego celu będziemy używać Git Krakena, który pobierzesz tutaj. Gdy go już zainstalujesz, założysz konto i zapoznasz się z całością, rozpocznij klonowanie repozytorium. Możesz to zrobić wybierając ikonę folderu:

Klonowanie repozytorium

Lub wciskając Ctrl+N albo z menu Plik wybrać opcję Clone. Twoim oczom ukaże się takie okienko:

Klonowanie repozytorium

Musisz podać tutaj dwie informacje:

– URL do repozytorium na serwerze

– lokalizacja na dysku, gdzie będzie stworzone Twoje lokalne repozytorium

Zatwierdź przyciskiem Clone the repo! Program poprosi Cię dodatkowo o hasło dostępu do Bitbucketa (jeśli Twoje repozytorium jest prywatne) i sklonuje repozytorium. Jako, że zostało ono dopiero stworzone na serwerze i nie ma tam żadnych commitów, Git Kraken zasugeruje stworzenie pierwszego. Po zatwierdzeniu zobaczysz ekran główny programu:

Klonowanie repozytorium

Gdzie jest mój commit?

Znajdujemy się na branchu master, który posiada jednego commita o treści „Initial commit”. Sprawdźmy teraz, co dzieje się na serwerze. Otwórz stronę Bitbucketa i przejdź do sekcji Commits w Twoim repozytorium. Ku Twojemu zdziwieniu nic tam nie ma! A przecież pierwszy commit już zrobiony! Tak, zgadza się, ale istnieje on tylko lokalnie, aby zsynchronizować go z chmurą musisz wcisnąć przycisk Push.

push

Kolejny komunikat dotyczy nazwy brancha na originie, który będzie śledził lokalnego mastera- proponuję zostawić domyślne ustawienia. Zatwierdź przyciskiem Submit.

push

Sprawdź teraz, commit powinien być już na serwerze.

branche w repozytorium
branche w repozytorium
stanPoPushu - bitbucket - branche
stanPoPushu – Bitbucket – branche
stanPoPushu - bitbucket - commity
stanPoPushu – Bitbucket – commity

Okej! Pierwsze koty za płoty, ale we wcześniejszym artykule pisałem, że master jest do trzymania tylko gotowego kodu. Dlatego trzeba stworzyć kolejny branch- develop. Możesz to zrobić na wiele sposobów, np. używając konsoli, Git Krakena, itp. W przykładzie skorzystam jednak z Bitbucketa, on też pozwala na wykonanie takiej czynności. Na stronie swojego repo przejdź do sekcji Branches i wybierz przycisk Create branch w prawym, górnym rogu ekranu. Pojawi się nowe okno:

tworzenie brancha

Wpisz w nim nazwę brancha i wybierz ten, z którego ma pobrać dane. Git Kraken powinien szybko „zauważyć”, że stworzono branch na serwerze, spójrz na sekcję Remote.

tworzenie brancha

Co udało się zrobić?

Nie masz go jeszcze w lokalnej wersji. Musisz zrobić tzw. checkout – podwójnie klikając na developa. Popatrzmy przy okazji na folder naszego repozytorium. Jak się domyślasz nie ma tam za wiele – plik readme i folder z konfiguracją Gita. Wróćmy jednak do konkretów. Zrobiliśmy już całkiem sporo, wypada jeszcze pokazać jak dodać ciekawszego commita. Potrzebujemy plików, ale najpierw podsumujmy co udało się osiągnąć:

– stworzyłeś repo na serwerze

– sklonowałeś je na dysk

– wykonałeś pierwszy commit na lokalnym masterze

– kolejny był pierwszy push na serwer

– stworzyłeś developa z mastera na serwerze

– zrobiłeś checkout tworząc jego lokalną wersję, śledzącą zmiany na serwerze.

Ostatnie zadanie

Teraz, aby mieć pliki stworzymy projekt w repo. Otwórz Visual Studio i stwórz nowy projekt. Jako miejsce wybierz lokalne repozytorium.

nowy orojekt w repozytorium

Git Kraken wykryje nowe pliki, widzisz to w prawej sekcji zatytułowanej Unstaged files:

commitowanie

Wybierz przycisk Stage all files, lub zaznacz te, które chcesz dodać do kontroli wersji. W polu Commit Message wpisz opis zmian i zatwierdź je przyciskiem Commit changes to files.

commitowanie

Uwaga! Zmian nadal nie ma na serwerze, a jedynie w lokalnej wersji. Przypominam w wciśnięciu Push 🙂 Teraz wszystko jest zsynchronizowane. Zobaczysz to w drzewie commitów:

commitowanie

Gotowe.

I to by było na tyle w dwuczęściowej serii z podstaw kontroli wersji i Gita. Miej jednak na uwadze, że to wiedza dobra, żeby zacząć. Systemy kontroli wersji, to coś o wiele bardziej złożonego, co zdecydowanie warto poznać. Zachęcam Cię do samodzielnych eksploracji, te artykuły miały na celu pomóc Ci zacząć. Mam nadzieję, że okazały się przydatne. Napisz w komentarzu, czy wszystko było jasne i czy nie miałeś problemów z wdrożeniem tego w życie. Tradycyjnie dodam, że jeśli uważasz artykuł za wartościowy, to podaj go dalej 🙂 Pomożesz innym i mnie. Z góry dziękuję 🙂

Please follow and like us:

Dodaj komentarz

This site uses Akismet to reduce spam. Learn how your comment data is processed.