Home

Welcome to the TokenOwO wiki! This is a github cheatsheet that we've created in order to learn how to properly work with version-control environment on github.

Tworzenie brancha i praca na nim

• git pull origin master - upewniam się, że jestem aktualny z masterem
• git checkout -b nazwa_brancha - tworzy nowego brancha i tam nas przenosi
• git checkout nazwa brancha - przejście na brancha

Kończymy pracę na swoim branchu, chcemy go oddać do code review

Idziemy na mastera i upewniamy się że mamy jego najnowszą wersję

• git checkout master
• git pull origin master Wracamy na swojego brancha:
• git checkout nazwa_brancha Robimy rebase, który aplikuje zmiany w masterze w naszym branchu, ale nasze zmiany lądują na wierzchu (tak jakby nasz branch powstał z najnowszej wersji mastera i potem możemy zrobić czysty merge z fast-forward
• git rebase -i master I to tryb interaktywny. Odpali się domyślny na naszej konsoli edytor, w którym zobaczymy listę commitów z naszego brancha. Teraz możemy nimi manipulować. Finalnie będziemy chcieli dla każdej PRki mieć jeden commit, który opisuje co ona robi i dlaczego to zostało wprowadzone. Lista poleceń w trybie interaktywnym jest wyświetlana w edytorze, najważniejsze to:
• pick, p - zatrzymaj commit w takiej formie w jakiej jest
• squash, s - połącz z commitem wyżej. Potem będzie możliwa edycja opisu tego nowego commita powstałego z połączenia
• drop, d - wywal commit, nie uwzględniaj w branch. To samo uzyskamy kompletnie linikę dotyczącej danego wpis
• reword, r - zmień opis danego commitu Jeśli odpala Ci się VIM, to poniżej najważniejsze komendy. Albo zmień sobie w stawienia konsoli/gita na inni edytor:
• I - przejdź do trybu edycji. W tym trybie możesz wprowadzać zmiany w teksteście, jak jak wszędzie indziej
• ESC - wyjdź z trybu edycji
• :w - zapisz
• :q - zamknij
• :wq - zapisz i zamknij
• :q! - zamknij porzucając zmiany

Pushujemy zmiany na githuba

• git push origin nazwa_brancha Tworzymy nową PRkę na githubie - link do tego wyświetli się nam w konsoli, github to też zasugeruje po wejści przez www w repo Puszujemy zmiany na staging (staging deployment) repo aplikacji stagingu z heroku musisz mieć dodane w konfigu gita jako staging Wszystkie rzeczy, które trafiają na staging, muszą być mergowane do brancha staging Nie przejmujemy się fast forward, może być syf Jeśli nie jesteśmy w stanie rozwiązać konfliktu, to pytamy sie reszty teamu na messangerze, czy są okej, z resetem stagingu do mastera. Jak tak, to wtedy robimy reset i potem mergujemy swój branch
• git checkout staging
• git fetch
• git reset --hard origin/master - zresetuj stan lokalnego brancha, to stanu mastera z repozytorium na githubie Wysyłamy branch staging, pod zdalną nazwą master, do repozytowium aplikacji stagingowej na heroku:
• git push staging staging:master Co się tłumaczy na
• git push nazwa_repozytorium kolalna_nazwa_brancha:nazwa brancha_w_repozytorium Czyli Wyśli na staging lokalny branch staging, ale tam traktuj go jako master

Mergowanie po approve z code review

Upewnij się, że twój branch jest zrebejsowany z aktualnym masterem

• git checkout master - przejście na mastera
• git merge --ff-only nazwa_brancha - włączenie zmian z brancha do mastera. Nie robimy merga, jeśli nie można fast-forward. Aby to rozwiązać, zrób rebase brancha do aktualnego mastera Wysłanie mastera na githuba
• git push origin master Deploy ma produkcje (zakłada, że repo apki produkcyjnej na heroku masz dodane jako production)
• git push production master

Inne przydatne komendy

• Git add . dodaje do repo wszystkie pliki
• Git pull --rebase origin master - zmiany które są na masterze są wrzucane do twojego repo

Video about git rebase (record of call on zoom in polish language): https://www.youtube.com/watch?v=Vydv7Bzy4BQ&fbclid=IwAR2b8NnoUxR3RnQsEHw9B2_iF5x4rXY0oCSASITPLYZdrHvsU_CmsXjkdlA