I. Tworzenie repozytorium wewnętrznego na Twoim kompie
Najpierw krótki schemat:
Za chwile zrozumiesz 😉
- Tworzymy na pulpicie folder o nazwie hmm… niech to będzie /gitTest/
- cd nazwaFolderu - przechodzisz do folderu nazwaFolderu (np. cd gitTest)
- cd .. - wychodzisz tego z folderu
- ls - pokazuje Ci pliki w folderze, w którym się znajdujesz
- ls -la - wyświetla również ukryte pliki w tym folderze
- mkdir nazwaFolderu - tworzy folder
- cat nazwaPliku - pokazuje zawartość pliku (np. tekst w pliku README.txt)
Klikamy folder prawym przyciskiem myszy i wypieramy Git Bush Here
W tym momencie otwiera się konsola Git Bash. Aktualnie znajdujemy się w folderze /gitTest/. Pierwsza rzecz to konfiguracja, w której wykorzystamy nasze dane logowania z Githuba. Użyjemy zatem komendy git config:
W konsoli możemy również wykorzystywać wiele komend linuxowych, takich jak np:
- Następnie używamy komendy git init, dzięki której inicjalizujemy (tworzymy) nasze lokalne repozytorium w folderze /gitTest/
git init
- Aby sprawdzić, czy na pewno się nam to udało, użyjemy komendy ls -la. Dzięki temu możemy zobaczyć, czy w naszym folderze znajduje się ukryty plik .git, który świadczy o tym, że repo zostało utworzone
- Możemy w tym momencie użyć komendy git status, aby sprawdzić status (stan) naszego repozytorium. Tak komenda umożliwia wyświetlenie stanu naszej pracy, np. czy dokonaliśmy jakichś zmian w danych oraz o tym, czy zmiany te są zatwierdzone. W naszym przypadku uzyskaliśmy informację o braku zatwierdzonych zmian w repo (czyli o braku tzw. commitów). Commity służą nam do zatwierdzania i opisywania zmian dokonanych w trakcie pracy nad kodem.
- Teraz możemy stworzyć jakiś plik, w którym będziemy mogli np. umieszczać nasz kod. Ten sam plik chcemy umieścić w naszym repozytorium, aby np. w późniejszym etapie wprowadzać różne zmiany w danych. Plik tworzymy poprzez poprzez komendę touch nazwaPliku, np:
Jak widzisz powyżej, po wpisaniu komendy git status, Szanowna Konsola wyświetli na czerwono informację o tym, że mamy nieśledzony plikTekstowy.txt (untracked file). Co to oznacza? A no to, że wcześniej tylko utworzyliśmy nowy plikTekstowy.txt, ale bez poinformowania o tym Gita. W dużym sktócie, Git jeszcze “nie śledzi” tego pliku. Czerwone info untracked file sugeruje nam, abyśmy użyli komendy git add, aby dodać info (poinformować Gita) o wprowadzonych zmianach. Komenda git add pozwala przenieść plik z Working Area do Staging area i przygotować go do wysłania np. na zewnętrzne repozytorium na GitHubie:
Jeśli teraz użyjesz komendy git status, nagle w konsoli pojawi się informacja w żółtym kolorze, że plik jest już śledzony przez Gita. Możemy ruszać dalej!
- Teraz mój ulubiony moment, czyli zatwierdzanie naszych zmian. I tutaj dumnie wjeżdża komenda git commit -m “Informacja o zmianie danych” (-m oznacza massage) Ten etap jest niezwykle istotny, ponieważ oprócz zatwierdzenia naszych aktualizacji, opisujemy to co właśnie zmieniliśmy. Opis jest szczególnie ważny dla dokładnej historii i dokumentacji naszej pracy:
Po zatwierdzeniu wyświetli się informacja o wykonanym commicie. Gdy następnie wypiszesz komendę git status, nagle okaże się, że nie masz nic do commitowania i wszystko jest “cacy” 😇
W tym momencie masz już utworzone repozytorium lokalne, w którym znajduje się zacomittowany i przygotowany do wysyłki na zewnątrz (np. na GitHuba) plikTekstowy.txt . Well done!
💥 Czy teraz rozumiesz już schemat z początku strony?
- Working area (pkt.1 - pkt.5)
Wszystkie operacje, które wykonujemy aż do momentu wykorzystania komendy git add
- Staging area (pkt.5 - pkt6)
Obszar, w którym znajdą się pliki po zastosowaniu komendy git add, ale przed zatwierdzeniem zmian, czyli użyciem komendy git commit
- Repozytorium (pkt. 7)
Docelowe miejsce, w którym znajdują się zacomittowane pliki (w tym przypadku nasze lokalne repozytorium na kompie) Ok, Lecimy dalej!
II. Wprowadzanie zmian w dodanym pliku
Ok, a co w przypadku jeśli będziemy chcieli z poziomu pulpitu wprowadzić zmiany w naszym pliku .txt? Przykładowo w plikTekstowy.txt o umieścimy treść “To jest pierwszy tekst w tym pliku”.
Co teraz? Teraz wypada te zmiany jakoś zatwierdzić, ponieważ mimo, że umieściliśmy w pliku nasz nowy tekst, to po wpisaniu w naszej konsoli komendę cat plikTekstowy.txt (pokazuje zawartość pliku), nie wyświetli się nic nowego.
- Poprzez edytor tekstu uzupłeniamy plikTekstow.txt o treść “To jest pierwszy tekst w tym pliku”
- Po zastosowaniu git status zobaczymy na czerwono informacje o untrucked file. Co zatem robimy? A no to samo co wcześniej w pkt. 5, czyli stosujemy komendę git add aby dodać plik do śledzenia, a następnie git commit, by zatwierdzić i opisać zmiany jako "Zmiana nr 2" i przygotować zmiany do wypchania na repo zawnętrzne (np. na Githuba)
Po wpisaniu ponownie git status, możemy odetchnać z ulgą, gdyż Git poinformuje nas, że nie mamy już nic do zacommitowania = wszystkie zmiany są zatwierdzone💪
💥 Mam dla Ciebie jeszcze 2 fajne i przydatne tricki, a mianowicie komendy:
- git add *.txt
Możesz ją zastosować, jeśli chcesz dodać do truckowania/śledzenia więcej niż 1 plik tekstowy. Ta komenda dodaje do śledzenia wszystkie pliki .txt, które znajdują się w danym folderze
- git commit -am
W dużym skrócie, jest to połączenie komend git add oraz git commit -m, które oznacza nic więcej jak “add massage” (-am). W praktyce przyśpieszy to cały proces, bo jednocześnie dodajemy plik do Gita i z automatu go commitujemy. Może to wygladać np. tak:
git commit -am "Twój komentarz do zmiany"
III. Push do repozytorium zewnętrznego
No i nastała długo wyczekiwana chwila. Zbieramy do kupy wszystko co do tej pory zrobilismy i….
… wbijamy na Githuba! 🥳
Jak tego dokonać? Jedziemy po kolei:
- Tworzymy nowe repozytorium na GitHubie. Ustawiamy:
- Nazwę repozytorium (u mnie “gitTest”)
- Dostępność repozytorium (public/private)
- ewentualnie jakiś opis (u mnie “To jest pierwszy test Gita”)
- jest tutaj opcja dodania do naszego repozytirium pliku README (teraz tego nie rób, zajmiemy się tym w Instrukcja nr 2 (zewnętrzne repo)
- Po zatwierdzeniu naszym oczom ujawi się kilka opcji do wyboru. To co nasz interesuje to adres naszego repozytorium, zaznaczony poniżej strzałką. Kopiujemy adres.
- W konsoli Basha przy pomocy komendy git remote add origin łączymy się z naszym zdalnym repozytorium. Wykorzystujemy do tego skopiowany adres naszego repozytorium zewnętrznego, które znajduje się na GitHubie:
Origin to skrót od adresu Twojego repozytorium na Githbie, zaś master to nazwa naszego głównego brancha
- Nie pozostało nic innego, jak tylko wypchnięcie danych na naszego Githuba przy użyciu komendy git push origin master
Posiadamy na razie tylko jeden główny branch (master) i chcemy, aby właśnie tam zostały wypchnięte nasze dane
W tym momencie Git poprosi Cię o podanie nazwy użytkownika oraz hasła do Twojego GitHuba. Ja wykonałem autoryzacje do GitHuba poprzez klucz publiczny, więc omija mnie ten krok i autoryzacja następuje automatycznie. Polecam ten sposób, ponieważ nie będziesz zmuszony za każdym razem podawać danych logowania. Po zatwierdzeniu danych użytkowanika nasz plik zostanie umieszczony na zewnętrzym repo.
- Po zatwierdzeniu enterem, zmiany z naszego lokalnego repozytorium powinny pojawić się na zewnętrzym repo na Gitubie. Aby sprawdzić historię wszystkich swoich commitów zastosowaliśmy w konsoli komendę git log.
- Na naszym repozytrium zdalnym pojawiły się nowe dane:
- Zmiana nr 1 - utworzenie nowego pliku plikTekstowy.txt
- Zmiana nr 2 - nowa treść “To jest pierwszy tekst w tym pliku” w plikTekstowy.txt
💥Może zauważyłeś, że cały czas jesteśmy w branchu master (główny branch). Na potrzeby łatwego przedstawienia tematu wszystkie zmiany wprowadzaliśmy do tej pory właśnie na branchu master.
Podczas bardziej zaawansowanej pracy z kodem korzysta się z innego rozwiązania. Na stronie głównej znajdziesz Instrukcja nr 3 (nowe branche) , w której wyjaśnię Ci o co dokładnie chodzi.
Podsumowanie
I. Tworzenie repozytorium wewnętrznego na Twoim kompie
Krok po kroku:
- Tworzymy folder np. /gitTest/ na kompie
- Konfiguracja gita (git config)
- Ustawiamy nasze lokalne repo w tym folderze; pojawia się tam plik .git (init)
- Tworzymy plik w katalogu (np. plikTekstowy.txt)
- Przekazujemy plik do śledzenia przez Gita, bo plik jest na razie “untracked” (git add)
- Zatwierdzamy nasze zmiany (git commit -m)
- ewentualnie pkt 5 oraz pkt 6 można wykonać łącznie (git commit -am)
- Plik jest już w naszym wewnętrzym repo
II. Wprowadzanie zmian w dodanym pliku
Krok po kroku:
- Z poziomu edytora tekstu edytujemy plik w naszym repo lokalnym (np plik .txt)
- Przekazujemy zmiany do śledzenia przez Gita, bo plik jest na razie “untracked” (git add)
- Zatwierdzamy i komentujemy nasze zmiany poprzez (git commit -m)
- ewentualnie pkt 5 oraz pkt 6 można wykonać łącznie (git commit -am)
- Edytowany plik jest już w naszym wewnętrzym repo
III. Push do repozytorium zewnętrznego
Krok po kroku:
- Tworzymy nowe repozytorium na GitHubie
- Kopiujemy link i łaczymy się z naszym GitHubem (git remote add origin)
- Wypychamy nasze dane na repozytorim zewnętrze (git push origin master)
- Plik jest już w naszym zewnętrzym repo
- Możemy sprawdzić historię commitów w konsoli (git log)
Śledź mnie na LinkedIn:
Newsletter
Popełnianie błędów jest rzeczą naturalną zanim perfekcyjnie opanujemy nowy materiał. Jeśli wyłapałeś jakieś nieprawidłowości w moim tekście, proszę daj mi znać mailowo. Jeśli masz jakieś sugestie lub pytania, proszę napisz do mnie wiadomość: kuba@javampokaze.pl
Made with Bullet