DW

W tej sekcji znajdziesz informacje na temat tworzenia nowego projektu na Github.

Kluczowe komendy Git, które pozwolą ci na pełne zarządzanie projektem – od jego inicjalizacji, poprzez wprowadzanie zmian, aż po synchronizację z repozytorium na GitHubie.

Aby rozpocząć pracę nad nowym projektem i przygotować go do synchronizacji z GitHubem, wykonaj następujące kroki:

• Utworzenie nowego lokalnego repozytorium:

git init

Ta komenda inicjuje puste repozytorium Git w bieżącym katalogu.

• Dodanie plików do poczekalni (staging area): git add .

Dodaje wszystkie nowe i zmodyfikowane pliki do poczekalni. Możesz również dodać pojedynczy plik, np. git add nazwa_pliku.js

• Zapisanie zmian w historii (commit):

git commit -m "Pierwszy commit: inicjalizacja projektu"

Komenda ta tworzy migawkę projektu w jego bieżącym stanie. Ważne jest, aby komunikat -m był krótki i opisowy.

• Zmiana nazwy domyślnej gałęzi (opcjonalnie, zalecane): git branch -M main

Ustawia domyślną nazwę gałęzi na main zamiast master, co jest obecnie powszechną praktyką.

Po zainicjowaniu lokalnego repozytorium, możesz je połączyć z nowo utworzonym repozytorium na GitHubie.

• Utwórz nowe, puste repozytorium na GitHub.com (nie zaznaczaj opcji dodawania README, .gitignore ani licencji).
• Połącz lokalne repozytorium ze zdalnym (origin):

git remote add origin https://github.com/twoja_nazwa_uzytkownika/nazwa_repozytorium.git

Zastąp twoja_nazwa_uzytkownika i nazwa_repozytorium odpowiednimi danymi.

• Wypchnięcie lokalnych zmian na GitHub: git push -u origin main

Ta komenda wysyła lokalne commity z gałęzi main do zdalnego repozytorium o nazwie origin. Opcja -u (lub –set-upstream) ustawia origin jako domyślne zdalne repozytorium dla bieżącej gałęzi, co pozwoli na używanie krótszych komend w przyszłości (np. git push, git pull).

Kolejność, czyli najpierw inicjalizacja projektu Git w konsoli, a potem tworzenie repozytorium na GitHub i połączenie go z lokalnym projektem, jest zdecydowanie bardziej typowa i zalecana.

Dlaczego ta kolejność jest preferowana?

• Lokalna kontrola wersji od początku: Rozpoczynając od git init w lokalnym katalogu, od razu zaczynasz śledzić zmiany w swoim projekcie. Oznacza to, że możesz tworzyć commity, cofać zmiany i korzystać ze wszystkich zalet Gita, zanim jeszcze pomyślisz o zdalnym repozytorium.

• Mniej konfliktów: Kiedy tworzysz lokalne commity, a dopiero potem łączysz się z pustym repozytorium na GitHubie (lub takim, które zawiera tylko plik README.md stworzony podczas inicjalizacji), rzadziej napotykasz problemy z konfliktami. Twoja lokalna historia jest jedyną historią do połączenia.

• Prostszy proces: Po zainicjowaniu lokalnego repozytorium i dodaniu kilku plików, wystarczy dodać zdalne repozytorium (git remote add origin …) i wypchnąć zmiany (git push -u origin master). To płynny i intuicyjny przepływ pracy.

• Co by się stało, gdyby było odwrotnie? Gdybyś najpierw stworzył repozytorium na GitHubie (szczególnie jeśli zaznaczyłbyś opcję dodania pliku README.md lub .gitignore), a potem próbował połączyć je z już istniejącym lokalnym projektem (który nie jest jeszcze repozytorium Git lub ma swoją własną historię), musiałbyś wykonać dodatkowe kroki:
  • Klonowanie zdalne repozytorium (git clone), a następnie przeniesienie plików do tego sklonowanego katalogu, co jest mniej efektywne.
  • Potencjalne konflikty: Jeśli lokalny projekt miał już jakąś historię Git, a zdalne repozytorium też miało historię (np. z plikiem README.md), mogłyby pojawić się konflikty podczas próby połączenia tych dwóch odrębnych historii.

Gdy już projekt jest zainicjowany i połączony z GitHubem, możesz swobodnie nim zarządzać:

• Sprawdzenie statusu repozytorium: git status

Pokazuje, które pliki zostały zmienione, dodane lub usunięte, a które są gotowe do commita.

• Dodawanie nowych plików lub katalogów:

Po utworzeniu nowych plików lub katalogów, użyj git add aby śledzić je w Gicie:

git add nowy_plik.js
git add nowy_katalog/

• Usuwanie plików:

Aby usunąć plik z projektu i z repozytorium Git: git rm plik_do_usuniecia.txt

Następnie wykonaj commit.

• Zmiana nazwy lub przeniesienie plików/katalogów:

Git posiada specjalną komendę do zmiany nazw i przenoszenia, która automatycznie śledzi zmiany:

git mv stary_plik.txt nowy_plik.txt

• Cofanie zmian (niezatwierdzonych):

Aby cofnąć zmiany w pliku, które nie zostały jeszcze dodane do poczekalni (git add):

git restore nazwa_pliku.js

Aby wycofać zmiany z poczekalni (ale nie z katalogu roboczego):

git restore --staged nazwa_pliku.js

• Zatwierdzanie zmian:

Po każdej grupie logicznie powiązanych zmian, wykonaj git add i git commit:

git add .
git commit -m "Opis zmian: Dodano nową funkcjonalność X i naprawiono błąd Y"

Gałęzie pozwalają na równoległą pracę nad różnymi funkcjami lub poprawkami bez wpływu na główną linię kodu.

• Wyświetlenie wszystkich gałęzi: git branch

Gałąź, na której aktualnie się znajdujesz, będzie oznaczona gwiazdką.

• Tworzenie nowej gałęzi: git branch nowa_funkcja
• Przełączanie się na inną gałąź: git checkout nowa_funkcja

Lub, aby utworzyć nową gałąź i od razu się na nią przełączyć: git checkout -b nowa_funkcja

• Łączenie gałęzi (merge):

Po zakończeniu pracy na gałęzi nowa_funkcja, możesz połączyć jej zmiany z gałęzią main:

git checkout main
git merge nowa_funkcja

Może to spowodować konflikty scalania, które będziesz musiał rozwiązać ręcznie.

• Usuwanie gałęzi (po scaleniu):

git branch -d nowa_funkcja

Użyj -D zamiast -d do wymuszonego usunięcia gałęzi, która nie została jeszcze scalona.

Regularna synchronizacja jest kluczowa dla współpracy i bezpieczeństwa kodu.

• Pobieranie najnowszych zmian ze zdalnego repozytorium: git pull origin main

Ta komenda pobiera zmiany z gałęzi main zdalnego repozytorium origin i automatycznie scala je z bieżącą gałęzią lokalną.

• Wypychanie lokalnych zmian na GitHub: git push

Wysyła wszystkie zatwierdzone zmiany z bieżącej gałęzi do zdalnego repozytorium.

Bezpośrednie zarządzanie repozytoriami Git z Google Cloud Console jest zazwyczaj realizowane poprzez Cloud Source Repositories (które są zintegrowane z Git), a nie bezpośrednie komendy Git działające w konsoli przeglądarkowej.

Jeśli planujesz używać swojego kodu z GitHub do wdrożeń na Google Cloud Platform (np. Cloud Functions, App Engine, Cloud Run), zazwyczaj proces wygląda następująco:

• Kod źródłowy jest zarządzany w repozytorium GitHub.
• Google Cloud Build (usługa CI/CD w GCP) może być skonfigurowany do monitorowania zmian na GitHubie.
• Po wykryciu nowych commitów na GitHubie, Cloud Build może automatycznie:

1. Pobrać kod.
2. Zbudować obraz Docker (dla Cloud Run/App Engine)
3. Wykonać testy.
4. Wdrożyć aplikację na wybranej usłudze GCP.

Przykładowe komendy związane z Google Cloud SDK (gcloud CLI), które możesz wykorzystać do interakcji z GCP po stronie lokalnej, po zarządzaniu kodem na GitHubie:

• Uwierzytelnianie: gcloud auth login
• Ustawienie projektu GCP: gcloud config set project twoj-projekt-gcp
• Wdrażanie funkcji Cloud Functions (zakładając, że jesteś w katalogu z kodem funkcji, który wcześniej zaktualizowałeś za pomocą Git):

gcloud functions deploy nazwa-funkcji --runtime python39 --trigger-http --source .