Git – Tworzenie repozytorium – praktyka

W dzisiejszym artykule będzie samo mięso, kod, praktyka, wybuchy 🙂 Poprzednie wpisy mogły powodować ziewanie, ale teraz skończymy z tym. Stworzymy własne repozytorium, dodamy kilka rewizji, będziemy poruszać się po naszym repozytorium 🙂

Mini ściągawka

• git status – sprawdza stan repozytorium.
• git add nazwaPliku.rozszerzenie – śledzenie stanu pliku o podanej nazwie w projekcie.
• git add -A – śledzenie stanu plików w projekcie. Instrukcja -A oznacza, że będą dodane wszystkie pliki, w których stan został zmieniony.
• git commit -m ” tutaj wpisujesz swój komentarz ” – dodanie rewizji do naszego repozytorium. Instrukcja -m powoduję, że musimy wpisać komentarz przed wrzuceniem plików na repo.
• git log – pokazuje informacje o wszystkich rewizjach w repozytorium.

Tworzymy repozytorium

Utwórzmy folder, w którym będziemy przechowywać nasze repozytorium, w moim przypadku ścieżka do katalogu:

C:\firstRepoTutorial

Przechodzę do tego katalogu i w nim wykonuję komendę za pomocą konsoli ja używam cmder

git init

I to wszystko :), repozytorium utworzone, teraz przejdziemy do dodania rewizji, mówiąc potocznie „komitów”.

Dodanie rewizji

Będąc w naszym katalogu

C:\firstRepoTutorial

Dodajmy plik index.html

  
Pierwsza rewizja.

 

Będąc w naszym folderze wydaj polecenie git status
Git po informuje nas, że w repozytorium są nieśledzone pliki. Są to pliki, które zostały dodane albo została naniesiona w nich zmiana. Aby móc dodać zmiany do repozytorium, należy dodać plik ze zmianą na plik śledzony. Wydaj polecenie

git add index.html

Teraz plik index.html, jest plikiem śledzonym, czyli, Git wie, jaki obecnie pliki ma umieścić w repozytorium. Powyższa komenda mówi: „weź plik index.html i zacznij go śledzić”. Gdy plik jest śledzony, dodajmy go do repozytorium, czyli wykonajmy rewizję albo potocznie mówiąc „komita”

git commit -m "Dodanie pliku index.html do repo. Pierwszy commit" 

Gdy wszystko przebiegło poprawnie zobaczysz informację:
[master (root-commit) b3da9c8] Dodanie pliku index.html do repo. Pierwszy commit
1 file changed, 10 insertions(+)
create mode 100644 index.html
Teraz aby sprawdzić listę wszystkich rewizji w naszym repo wydaj polecenie

git log

Poniżej zobaczysz informacje odnośnie rewizji, kto jest autorem, jaki jest klucz SHA-1, kiedy rewizja została wrzucona do repo, widoczny komentarz rewizji.

commit b3da9c8ace10e851fb2c0f1340515ee224b8ee7f
Author: Przemysław Juśkiewicz 
Date:   Tue Feb 6 18:11:20 2018 +0100

    Dodanie pliku index.html do repo. Pierwszy commit

Teraz wykonamy kilka zmian na pliku index.html i z każdą zmianą będziemy robić „komit” do repo.

Do pliku index.html dodaj liniję

Druga rewizja.

Zapisz plik index.html, wykonaj komendę śledzenia pliku i wrzuć zmiany do repo.

• git add index.html
• git commit -m „Zmiana na pliku index.html. Drugi commit.”

Ponownie dodaj kolejną linię do pliku index.html

Trzecia rewizja.

Zapisz plik index.html, wykonaj komendę śledzenia pliku i wrzuć zmiany do repo.

• git add index.html
• git commit -m „Zmiana na pliku index.html. Trzeci commit.”

Powtórz czynność jeszcze raz, aby uzyskać 4 rewizje w repozytorium

Gdy wykonasz powyższe czynności, wydaj polecenie git log, ujrzysz następujący wynik:

git log
commit 368dcfd15531151a068c353bc7a9768af538b8d1
Author: Przemysław Juśkiewicz 
Date:   Tue Feb 6 18:37:20 2018 +0100

    Zmiana na pliku index.html. Czwarty commit

commit 08d2b7c1832fed27300a938dc6385c351cb42f2c
Author: Przemysław Juśkiewicz 
Date:   Tue Feb 6 18:35:47 2018 +0100

    Zmiana na pliku index.html. Trzeci commit.

commit 9cf36cc841f8ed322070de0bc54647150122aabd
Author: Przemysław Juśkiewicz 
Date:   Tue Feb 6 18:27:12 2018 +0100

    Dodanie pliku index.html do repo. Druga commit

commit b3da9c8ace10e851fb2c0f1340515ee224b8ee7f
Author: Przemysław Juśkiewicz 
Date:   Tue Feb 6 18:11:20 2018 +0100

    Dodanie pliku index.html do repo. Pierwszy commit

Teraz warto zadać sobie pytanie, po co to wszystko, co z tego, że dokładam zmiany do pliku i wrzucam do repo. Chcę wam pokazać jedną z zalet gita, a mianowicie, historia zmian w naszym projekcie. Wiemy, kiedy nastąpiła zmiana, co w tej zmianie nastąpiło. Aby lepiej zobrazować działanie, uruchom w konsoli komendę:

gitk

Pojawi się graficzna wizualizacja naszego repo, gdzie możesz kliknąć każdą rewizję i zobaczysz jakie zmiany w danym komicie zrobiłeś. Co prawda na przestrzeni zmian czterech prostych linijek nie ma tutaj zbyt wiele.

Ale, o co chodzi?

Wyobraź sobie, że Twój projekt składa się z N-krotnej ilości przeróżnych plików gdzie następują zmiany. Od dodania zmiennej aż do zmiany logiki. Zrobiłeś zadanie, zrobiłeś komita, okazuję się, że zadanie zostało, źle wytłumaczone na pewnym etapie, pracę zajęły Ci 4 dni. Jesteś zły i opadają Ci ręce. W takiej sytuacji patrzysz na historię zmian, szukasz rewizji, do której zadanie było wykonane prawidłowo. Zaczynasz pracę od tego momentu, w którym jest jeszcze wszystko ok. Piszesz kolejną brakującą część, ale już z odpowiednią ilością informacji, która pozwoli na wykonanie zadania prawidłowo. Dzięki temu, z 4 dni, możesz odzyskać, powiedzmy 2, a drugie 2 na nowo zakodować. Co prawdą są specjalne „sztuczki” w gicie, gdzie takie zachowanie można rozwiązać na kilka sposobów i będą one na pewno lepsze i bardziej wygodne niż to które przedstawiłem. Na obecnym etapie nie będę wchodzić w bardziej zaawansowane metodyki.

Podsumowanie

Ten wpis ma pokazać Ci podstawy, aby móc zrozumieć wpisy poprzednie. Bez tej wiedzy, następne wpisy będą trudniejsze do zrozumienia. Spokojnie, będę robić wszystko, aby było jak najprościej i jak najczytelniej. Ten wpis przedstawił odrobinkę praktyki i pokazał odrobinkę tego, jak wygląda praca z Git’em od bebchów. Jest to zaledwie ułamek tego, co można robić w systemie Git. Kolejne wpisy będą opowiadać o strukturze gita, dowiesz się, czym jest plik śledzony, i nie śledzony, czym jest gałąź (ang. branch), będziemy poruszać się po gałęziach, pokaże, jak wracać do wybranej rewizji, jak łączyć gałęzie między sobą, te i wiele innych już nie wkrótce w następnych wpisach. Może być sporo suchej teorii z drobnymi przykładami, ale będę co jakiś czas robić podobny temu wpis z praktyką, aby poprzednie wpisy były bardziej klarowne i zrozumiałe.

Jeżeli jest coś nie zrozumiałe, masz pytanie, nie rozumiesz czegoś, albo wstydzisz się napisać komentarz, napisz do mnie bez pośrednio w zakładce kontakt, odpowiem w najbliższej możliwej wolnej chwili 🙂

• Poprzedni – git tworzymy repo
• Następny – obszar roboczy

 

 

Pozdro 🙂