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ąć

Git operuje na podstawie commitów, wszelkie zmiany jakie będziecie robić, powinny być zapisane jako jeden, lub więcej commitów.

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. pushujecie wasze lokalne commity do waszego forka na githubie
4. na naszym repo robicie nowy PR, monitorujecie, czekacie na odpowiedź, ewentualnie coś poprawiacie na swoim forku, to automatycznie zaktualizuje PR

Bardzo często sam Github nie starczy (np. przy edycji sprite'ów), 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 nawet opcja żeby odrazu stworzyć PR.

Gdy zmieniacie pliki w repozytorium Github Desktop oraz Git Bash automatycznie wykryją że nastąpiły zmiany, wtedy wasze pliki są "unstaged", jeżeli chcecie zrobić commita z tymi zmianami, musicie je zestage'ować, wtedy będą one "staged", teraz gdy zrobicie commita, to wasze staged zmiany zostaną zapisane i włączone do nowego commita.

W Git Bashu trzeba do wszystkiego używać komendy git, jest ona bardzo rozbudowana i pozwala na o wiele więcej operacji.

Bardziej zaawansowana terminologia 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 commity 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
• HEAD - to symboliczne oznaczenie commitu na którym obecnie jesteście
• checkout - to zmienienie obecnego HEADa, można w ten sposób eksplorować historię repozytorium oraz zmieniać obecne branche
• 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")