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:

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

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

Dodanie rewizji

Będąc w naszym katalogu

Dodajmy plik index.html

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


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”

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

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.

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ę

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

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:

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ę:

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 🙂

 

 

Pozdro 🙂
 

 

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*