Instrukcja nr 2 (zewnętrzne repo)
2️⃣

Instrukcja nr 2 (zewnętrzne repo)

W
1️⃣
Instrukcja nr 1 (wewnętrzne repo) wytłumaczyłem Ci jak możesz stworzyć swoje wewnętrzne (lokalne) repozytorium na swoim kompie. Dodatkowo pokazałem jak wypchnąć dane na zewnątrz, czyli jak przesłać je na GitHuba.
W tym momencie wykonamy kilka podobnych operacji, ale od drugiej strony, a mianowicie zaczniemy od GitHuba.

I. Tworzenie repozytorium zewnętrznego na Githubie

  1. Pierwszym krokiem jaki możemy tutaj wykonać będzie utworzenie na naszym kompie folderu, np. /gitTest2/ (to tutaj będziemy chcieli przesłać dane z Twojego zewnętrznego repo)
  1. Następnie Wbijamy na GitHuba i tworzymy nowe zewnętrzne repozytorium. Ustawiamy:
      • Nazwę repozytorium
      • Dostępność repozytorium (public/private)
      • ewentualnie jakiś opis (u mnie “To jest drugi test Gita”)
      • do naszego repo dodajmy sobie też dla przykładu plik README na którym będziemy wykonywać odpowiednie modyfikację, aby przedstawić sens całej tej zabawy z Gitem
      notion image
      Zwróć uwagę, że plik README będzie posiadał rozszerzenie .md. Pliki z rozszerzeniem .txt oraz .md służą do przechowywania informacji tekstowych, ale różnią się sposobem formatowania i mogą mieć różne zastosowanie. Teraz nie jest to dla nas istotne.

II. Pobranie danych z Githuba do repozytorium wewnętrzego

  1. Kolejnym krokiem będzie pobranie danych z naszego repo zewnętrzego na Twój komuter. Aby to wykonać musimy najpierw otworzyć naszą konsolę Bashową (klikamy nasz nowy folder prawym przyciskiem myszy i wybieramy Git Bash Here).
  1. Wracamy na Githuba. Aby pobrać dane na nasz komputer musimy zastosować proces klonowania. Jest na to kilka metod, ale my wykorzystamy klonowanie poprzez certyfikat HTTSP. Kopiujemy zatem link do naszego repo. Wracamy do konsoli Bash.
notion image
 
  1. Klonowanie w Git możliwe jest dzięki komendzie git clone “adres repozytorium”.
git clone https://github.com/jakubXXX/gitTest2.git
  1. Po zatwierdzeniu Git prawdopodobnie poprosi Cię o podanie nazwy użytkownika oraz hasła go Twojego Githuba. Ja ustawiłem sobie automatyczną autoryzacje, więc omija mnie ten krok.
  1. Po wpisaniu Twoich danych logowania, wszystkie dane z repozytorium zewnętrzego (w naszym przypadkuplik Readme.md zostaną skopiowane na Twój komputer (do folderu /testGita2/). Dla potwierdzenia możesz spojrzeć do swojego katalogu na pulpicie lub zastosować komendy ls oraz cd w konsoli
notion image

III. Wprowadzenie zmian w danych

Po pobraniu danych na nasze repozytorium wewnętrzne możemy wprowadzać w nich różnego rodzaju zmiany. Jeśli potrzebujemy np. zamieścić dodatkową treść w pobranym pliku README.md, możemy to zrobić bezpośredio poprzez edytor tekstu, a następnie dodać zmiany do Gita (git add) i zatwierdzić (git commit). Zakutalizowane dane będę wtedy przygotowane, aby umieścić je na naszym zewnętrznym repozytorium (wykonać push). Opis jak to wykonać znajduje się tutaj:
1️⃣
Instrukcja nr 1 (wewnętrzne repo) w pkt. II. Wprowadzanie zmian w dodanym pliku.

IV. Pull zaktualizowanych plików na Twój komuter

Oprócz edycji danych bezpośrednio w pliku (lub poprzez konsolę) mamy również możliwość zrobienia tego z poziomu GitHuba. Aby to wykonać, musimy przejść przez kilka kroków:
  1. Wskakujemy na naszego GithHuba i otwieramy edytor danych
  1. Następnie edytujemy plik README.md, np. umieszczając opis np. “Komentarz do wykonania pull” (tutaj gdzie biała strzałka na poniższym screenie)
  1. Zatwierdamy, klikacjąc opcję Commit changes (po prawej stronie screena) opisując dodatkowo zmianę, np. “Commit githubowy”. Zauważyłeś jakieś podobieństwo? To bardzo podobne do komendy git commit -m z konsoli Basha
notion image
  1. My ustawiamy te zmiany na branchu master (czy też main), ponieważ nie tworzyliśmy do tej pory żadnego innego brancha. Jednak dobra praktyka programowania wskazuje na to, aby wszystkie dodatkowe zmiany wykonywać i zapisywać nie na branchu głównym, ale na dodatkowo utworzonych branchach. Dopiero, gdy przetestujemy nasze nowe zmiany i będziemy pewni że wszystko działa jak należy, to wtedy łączymy nowy branch z branchem głównym master/main.
      2. Więcej info o tworzeniu nowych branchy znajdziesz tutaj:
      3️⃣
      Instrukcja nr 3 (nowe branche)
  1. Po zatwiedzeniu zmian na naszym repo zewnętrzym mamy już aktualną wersję danych:
notion image
  1. Ostatnim etapem jest zaciągnięcie tych zaktualizowanych danych na Twój komputer, czyli repo wewnętrzne (ponieważ zmiany w pliku zostały wykonane jedynie na Githubie). Korzystamy tutaj z komendy git pull
notion image
  1. Aby upewnić się, że nasze aktualne dane zostały pobrane na komuter, zastosujmy komendę cat README.md., aby wyświetlić zawartość tego pliku. Widzimy, że zostały pobrane dane z najnowszego commita githubowego: “Komentarz do wykonania pull”
  1. Gotowe! Pobrałeś dane z GitHuba do siebie na kompa.

Ad.I. Tworzenie plików w repozytorium lokalnym z poziomu konsoli

We wcześniejszym przykładzie, w pkt. I rozpoczęliśmy pracę od utworzenia repozytorium na Githubie. Jak pamiętasz, na etapie tworzenia nowego projektu na GitHubie dodaliśmy sobie do repozytorium plik README.md
Teraz wykonamy inny wariant z pkt. I. Powtórzymy sobie ten sam proces, jednak nie dodamy teraz pliku README i spróbujemy pokazać jak tworzyć i dodawać takie pliki do repozytorium , z poziomu konsoli. Vamos!
  1. Najpierw tworzymy repo zewnętrzne na GitHubie.
      2. WAŻNE: Nie zaznaczamy opcji “Add a REAMDE file”, ponieważ chcemy taki plik utworzyć i dodać do repo z poziomu konsoli
notion image
  1. Na ekranie pojawi się teraz kilka opcji do wyboru:
a) adres naszego repozytorium na Githubie
b) stworzenie nowego repozytorium (z poziomu konsoli)
c) wypchanie istniejącego już repo zewnętrz (z poziomu konsoli)
To samo robliśmy w
1️⃣
Instrukcja nr 1 (wewnętrzne repo) w pkt. III (push danych)
d) importowanie kodu (tutaj nie będę się wymądrzał, bo na ten temat jeszcze nic nie wiem 😄)
notion image
W tym momencie interesuje nas jedynie punkt c), poniważ chcemy stworzyć nowe repozytorium wewnętrzne oraz plik tekstowy .md, a następnie wypchnąć go do naszego repo zewnętrzego (push).
 
  1. Tworzymy zatem folder /Test/ na pulpicie i uruchamiamy konsolę Basha prawym przyciskiem myszy.
      2. Jeśli nie pamiętasz jak to zrobić, patrz
      1️⃣
      Instrukcja nr 1 (wewnętrzne repo)       pkt. 1.
  1. Po otwarciu konsoli musimy wykonać konfigurację Gita przy użyciu dobrze nam znanych komend config. Podajemy tutaj swoje dane logowania do Githuba i lecimy dalej.
  1. Teraz chcemy utworzyć plik tekstowy o nazwie javamPokaze.md oraz umieścić w nim krótki opis. Wykorzystamy do tego komendy touch (tworzenie pliku) oraz echo (opis)
touch javamPokaze.md && echo "# javamPokaze jest super" > javamPokaze.md
  1. Inicjalizujemy repozytorium w folderze /Test/ przy pomocy komendy git init
  1. Następnie dodajemy plik do Staging Area używając komendy git add javamPokaze. W tym momencie Git pokazuje nam komunikat o błędzie:
warning: in the working copy of 'javamPokaze.md', LF will be replaced by CRLF the next time Git touches it
Problem wynika z różnicy w rozszerzeniach plików używanych w Git (LF) i domyślnych dla systemu Windows (CRLF). (więcej info na ten temat: https://linuxhint.com/fix-lf-will-replaced-by-crlf-warning-in-gif/). Można to łatwo rozwiązać używająć komendy git config
git config --global core.autocrlf true
  1. Ponownie próbujemy dodać dane do Staging Area (git add javamPokaze.md), a następnie commitujemy zmiany (git commit -m “Pierwszy commit w javamPokaze”).
  1. Obeszliśmy problem, więc pozostaje nam jedynie wypchnięcie naszych danych do zewnętrznego repo (push), aby na naszym Githubie pojawiły się dane z zapisanymi zmianami

Podsumowanie

I. Tworzenie repozytorium zewnętrznego na Githubie:

💡
Krok po kroku:
  1. Tworzymy jakiś folder na kompie
  1. Następnie tworzymy repo na Githubie:
    1. nazwa repo
    2. dostęp (public/private)
    3. opis repo
    4. plik README.md

II. Pobranie danych z Githuba do repozytorium wewnętrzego:

💡
Krok po kroku:
  1. Wchodzimy ma GitHuba
  1. Kopijemy adres naszego repo
  1. Klonujemy nasze repo poprzez certyfikat HTTSP (git clone)
  1. Autoryzacja (podajemy dane logowania do naszego Githuba)
  1. Dane są już w naszym wewnętrzym repo (w folderze na naszym kompie)

III. Wprowadzenie zmian w danych:

💡
Krok po kroku:
  1. Z poziomu edytora tekstu wprowadzamy zmiany w pliku, który pobraliśmy do naszego repo lokalnego (np plik REAMDE)
  1. Przekazujemy zmiany do śledzenia przez Gita, bo plik jest na razie “untracked” (git add)
  1. Zatwierdzamy i komentujemy nasze zmiany poprzez (git commit -m)
      • ewentualnie pkt 5 oraz pkt 6 można wykonać łącznie (git commit -am)
  1. Edytowany plik jest już gotowy do wypchnięcia do naszego zewnętrznego repo (push)

IV. Pull zaktualizowanych plików na Twój komuter:

💡
Krok po kroku:
  1. Otwieramy nasze repo na Githubie, a następnie edytor danych pliku
  1. Edytujemy interesujący nas plik (np.README.md)
  1. Zatwierdzamy zmiany komendą commit, opisując naszą aktualizację danych
  1. Pobieramy aktualne dane na swoje repo wewnętrzne (git pull)

Ad. I. Tworzenie plików w repozytorium lokalnym z poziomu konsoli

💡
Krok po kroku:
  1. Tworzymy jakiś folder na kompie
  1. Następnie tworzymy repo na Githubie (ale bez tworzenia pliku README):
    1. nazwa repo
    2. dostęp (public/private)
    3. opis repo
    4. bez zaznaczania opcji z plikiem README.md
  1. Postępujemy zgodnie z instrukcją sugerowaną przez GitHuba w opcji:
      2. “…or create a new repository on the command line”, czyli:
      • otwieramy konsolę Basha na utworzonym folderze
      • konfigurujemy Gita podając dane logowania
      • tworzymy plik (touch); możemy w nim również umieścić jakiś tekst (echo)
      • inicjalizujemy repozytorium w naszym nowym folderze (git init)
      • dodajemy plik do Staging Area (git add) i commitujemy (git commit -m)
        • jeśli pojawi się błąd LF will be replaced by CRLF to konfigutujemy ustawienia (git config --global core.autocrlf true)
      • łączymy się z naszym Githubem (git remote add origin “link”)
      • wypychamy nasze dane do repozytorim zewnętrzego (git push origin master)
 

Ś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