Podstawy Gita i wprowadzania zmian

Wstęp

Git to program napisany przez twórcę Linuxa, Linusa Torvaldsa. Wszystkie repozytoria na Githubie, to repozytoria Gita, wiele funkcji Githuba to jedynie ładna oprawa graficzna dla komend do programu Git. Ale nawet jeżeli wprowadzasz małe zmiany, to warto znać pare rzeczy na temat Gita.

Absolutne podstawy Gita

Git działa głównie na podstawie branchów i commitów.

• repo - repozytorium, to w naszym przypadku poprostu codebase naszego serwera https://github.com/aq33/tgstation
• branch - to "gałąź" repozytorium, czyli jedna z jego wersji, zazwyczaj główną wersją jest branch o nazwie "master", u nas serwer jest automatycznie aktualizowany do mastera co jakiś czas, główni koderzy często będą pracowali na jakimś osobnym branchu gdy dodają nowy feature do gry
• commit - to jedna "zmiana" na danym branchu, całe repozytorium można w każdej chwili przedstawić jako długi ciąg commitów, dzięki temu systemowi, jeżeli coś pójdzie nie tak, np jakiś commit wprowadza buga, można go łatwo cofnąć

Rzeczy specyficzne dla Githuba

• fork - to wasza własna kopia repozytorium, na niej możecie robić własne commity, branche,
• pull request (PR) - to główny sposób dodawania nowych mechanik, itd. do codebase, PR to prośba o złączenie zmian z jednego brancha do drugiego, - branche źródłowe mogą być lokalne lub z forków, a branch docelowy to zazwyczaj master (a więc nasz serwer), zanim wasz PR zostanie zmerge'owany (zaakceptowany), musi przejśc testy sprawdzające czy nie zepsuliście gdzieś kodu, a potem zukonake musi go zatwierdzić

Ok, to jak zacząć cokolwiek robić?

1. tworzycie swój fork klikając guzik w górnym-prawym rogu
2. na swoim forku robicie zmiany, np. tłumaczenia i commitujecie je (nie twórzcie branchów, chyba że macie zamiar zrobić wiele PR), ten krok możecie wykonać nawet w samym githubie, ma on wbudowany edytor tekstu, jedynie upewnijcie się że robicie to na swoim forku, i wykonujecie commity do mastera
3. na naszym repo robicie nowy PR, monitorujecie, czekacie na odpowiedź, ewentualnie coś poprawiacie na swoim forku, to automatycznie zaktualizuje PR

Więcej niż podstawy Gita

• clone - "klonowanie" repo, to poprostu pobranie repozytorium na swój komputer
• remote - zdalne repozytorium, gdy klonujecie nasze repo lub swój fork, to ma on automatycznie ustawiony remote "origin" wskazujący na źródło z Githuba, remote może nawet wskazywać na zupełnie inne repozytoria, np przy portowaniu zmian, można dodać tgstation jako osobny remote
• merge - nanosi zmiany z jednego brancha do drugiego, tego używa pull request, w większości przypadków merge przebiega bez problemów, ale czasem jeden plik został zmieniony przez oba branche, wtedy w konfliktującym pliku pokazane są obie wersje, należy go zedytować i wybrać jedną z wersji, lub w jakiś sposób je połączyć
• fetch - zaktualizowanie remote, czyli pobranie nowych commitów które ktoś mógł nanieść z Githuba, to aktualizuje samo remote, ale nie lokalną wersję, patrz: pull
• push - zmerge'owanie lokalnego brancha do brancha na remote, nie powiedzie się jeżeli "zalegacie" w jakichś commitach
• pull - pobranie zdalnych commitów na lokalny klon, w praktyce to jest to samo co fetch, a potem merge z remote do lokalnej
• tracking branch - branch lokalny który połączony jest z jakimś remote branchem, np domyślnie po sklonowaniu, wasz master będzie trackował origin/master (branch "master" na remote "origin")

Bardzo często sam Github nie starczy, wtedy można pobrać Github Desktop lub Git Bash. Github Desktop to ładna oprawa graficzna do Gita, zintegrowana też z Githubem. Git Bash to terminal z Linuxowymi komendami, przydatny do jeszcze bardziej zaawansowanej pracy z repo. Aby z tych programów wykonać PR, wystarczy że sklonujecie swój fork (w jednym z tych dwóch programów), naniesiecie jakiekolwiek zmiany w plikach, zcommitujecie je, i zpushujecie do remote.

W Github Desktop jest to dosyć proste, więc nie będę tego tłumaczył. W Git Bashu trzeba do wszystkiego używać komendy git, jest ona bardzo rozbudowana i pozwala na o wiele więcej operacji.