{"id":23257035,"url":"https://github.com/solvro/git-wprowadzenie","last_synced_at":"2025-04-06T04:41:39.124Z","repository":{"id":129983361,"uuid":"176459079","full_name":"Solvro/git-wprowadzenie","owner":"Solvro","description":null,"archived":false,"fork":false,"pushed_at":"2019-03-19T08:12:24.000Z","size":7,"stargazers_count":13,"open_issues_count":0,"forks_count":1,"subscribers_count":6,"default_branch":"master","last_synced_at":"2025-02-12T10:52:51.113Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/Solvro.png","metadata":{"files":{"readme":"readme.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2019-03-19T08:11:36.000Z","updated_at":"2024-11-14T00:20:13.000Z","dependencies_parsed_at":null,"dependency_job_id":"98079328-914d-4303-9f72-00ff01d2158d","html_url":"https://github.com/Solvro/git-wprowadzenie","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Solvro%2Fgit-wprowadzenie","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Solvro%2Fgit-wprowadzenie/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Solvro%2Fgit-wprowadzenie/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Solvro%2Fgit-wprowadzenie/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Solvro","download_url":"https://codeload.github.com/Solvro/git-wprowadzenie/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247436142,"owners_count":20938532,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-12-19T12:26:43.065Z","updated_at":"2025-04-06T04:41:38.981Z","avatar_url":"https://github.com/Solvro.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# Git Prelelekcja\n\n## Po co się używa Gita? Dlaczego warto\n\nGit dba o to, by każdy uczestnik projektu miał zawsze jego najnowszą wersję. Git należy do rozproszonych systemów kontroli wersji, a więc oprócz tego, że projekt jest na serwerze, to każdy z uczestników projektu ma swoją lokalną wersję u siebie. Zatem jeśli serwer szlag trafi, to nic złego nie powinno się stać. Git potrafi sobie radzić także z takimi sytuacjami, jak edycja tego samego pliku przez dwie osoby. System po prostu postara się połączyć wprowadzone zmiany i jednej i drugiej osoby. Co więcej, Git przechowuje wszystkie wersje danego pliku, dlatego jeśli coś się popsuje, nie ma problemu by odzyskać poprzednią wersję. Dlatego chociażby dlatego warto używać Gita nawet jeśli pracuje się solo.\n\nPracując samemu:\n\n1. Możliwość łatwego cofnięcia katastrofy\n2. Eksperymentowanie bez niszczenia\n3. Łatwa praca z wielu miejsc\n4. Łatwe włączenie nowych osób\n5. Dwie pieczenie na jednym ogniu (CV)\n\n### Co to jest Git\n\nGit to rozproszony system kontroli wersji, u którego podstaw leżą bardzo proste założenia. To jest jednak jego potęgą — elastyczność oraz kilka sprytnych pomysłów spowodowała że powstało narzędzie proste w użyciu, pasujące zarówno do prostych projektów jak i ogromnych przedsięwzięć (jak np. jądro systemu linux).\n\nGit jest praktycznie wymaganą kompetencją w wielu firmach i ponieważ praca programisty opiera się na pracy w zespole, jest to technologia, którą powinieneś mieć opanowaną.\n\n__SCM__ — to akronim od Source Code Management, czyli dosłownie kontrola kodu (w języku polskim funkcjonuje określenie system kontroli wersji); jest to system który pozwala na archiwizowanie i śledzenie zmian w kodzie, dzięki czemu możemy cofać się w historii lub podejrzeć, kto był autorem konkretnej zmiany\n\n__Repozytorium__ — ‘kontener’ na określony zbiór kodu, najczęściej jeden projekt; repozytorium pozwala grupować kod i zmiany, dzięki czemu możemy przeglądać wszystkie zmiany wykonane w ramach jednego repozytorium, przyznawać uprawnienia do repozytoriów oraz pobierać / kopiować je\n\n__Commit__ — jest to proces ‘wysłania’ na repozytorium określonych zmian w kodzie — jeśli pobierasz kod z repozytorium, następnie dokonujesz modyfikacji i wysyłasz te zmiany z powrotem do repozytorium, proces ten nosi nazwę commitowania, a same zmiany wysłane razem nazywamy commitem lub rewizją\n\n__pull / push__ — odpowiednio pobranie i wysłanie zmian (jednego lub wielu commitów) z/do innego repozytorium\n\n__diff__ — (ang. różnica) — jest to różnica pomiędzy różnymi rewizjami — dzięki temu możemy zobaczyć, które fragmenty uległy zmianie oraz w jaki sposób; pozwala to także zoptymalizować transfer danych pomiędzy repozytoriami\n\n__fork__ — kopia repozytorium; szczególnie popularne w przypadku projektów open-source, dzięki czemu możemy skopiować cały projekt i rozwijać go niezależnie (np. dopasowując do naszych potrzeb)\n\n__branch__ — odgałęzienie, wersja wewnątrz repozytorium; branche pozwalają na prace wielu osobom równocześnie, bez ciągłego wchodzenia sobie w drogę i nadpisywania zmian — każdy może pracować na swoim branchu, dopiero po zakończeniu pracy łącząc zmiany z innymi i rozwiązując problemy\n\n__merge__ — połączenie wielu zmian z różnych źródeł, które może skutkować niekompatybilnymi zmianami wymagającymi ręcznych modyfikacji; merge pozwala łączyć prace wykonywane w różnych obszarach, które mogą się zazębiać, w jedną całość w sposób kontrolowany i świadomy\n\n## Instalacja Gita\n\n### Linux\n\nFedora:\n\u003e sudo yum install git-core\n\nDebianowe:\n\u003e sudo apt-get install git\n\n### Mac\n\nhttp://sourceforge.net/projects/git-osx-installer/\n\n### Windows\n\nhttp://msysgit.github.com/\n\n## Klient Gita\n\nOsobiście, szczerze was zachęcam do korzystania z oryginalnego Git Basha, albo, w przypadku systemów unixowych - z konsoli wbudowanej w system. Uważam, że warto się przełamać do używania konsoli i nie jest to narzędzie tak skomplikowane jak się wydaje, pozwala ponadto dużo szybciej załapać o co w tym Gicie chodzi i jak to wszystko działa. Dla tych jednak, którzy na samą myśl o wklepywaniu literek do commandline dostają dreszczy, powstało wiele narzędzi takich jak SmarGit, SourceTree, lub GitKraken.\n\n## Repozytorium Git\n\nNa wykładzie korzystać będziemy z najpopularniejszej chyba platformy - GitHuba. Polecam oswoić się z nią, jest to również wizytówka ciebie jako programisty. Możesz na GitHuba wstawiać swoje projekty, od niedawna GitHub oferuje darmowe repozytoria prywatne, więc możesz też tam trzymać na przykład zadania na zajęcia. Warto zdawać sobie sprawe z tego ze GitHub nie równa się Git i istnieje więcej tego typu platform - np Gitlab czy Bitbucket.\n\n## Jednorazowa konfiguracja\n\n\u003e git config --global user.name \"John Doe\"  \n\u003e git config --global user.email \"john.doe@solvro.pl\"\n\n## Tworzenie nowego repozytorium / klonowanie isniejącego\n\n### Inicjacja repozytorium\n\n\u003e git init\n\nTo polecenie stworzy nowy podkatalog o nazwie .git, zawierający wszystkie niezbędne pliki — szkielet repozytorium Gita. W tym momencie żadna część twojego projektu nie jest jeszcze śledzona.\n\nAby rozpocząć kontrolę wersji istniejących plików powinieneś rozpocząć ich śledzenie i utworzyć początkową rewizję. Możesz tego dokonać kilkoma poleceniami add (dodaj) wybierając pojedyncze pliki, które chcesz śledzić, a następnie zatwierdzając zmiany poleceniem commit:\n\n\u003e git add README  \n\u003e git add \\*.js  \n\u003e git add .  \n\u003e git commit -m \"komentarz dla commita\"  \n\n### Stworzenie repzytorium na GitHubie - poruszanie się po platformie, remote add\n\n\u003e git remote add origin https://github.com/okkindel/sample.git\n\u003e git push origin master\n\n### Sklonowanie repozutorium, wypchnięcie kolejnego pliku\n\n\u003e git clone https://github.com/okkindel/sample.git\n\n## Praca z Gitem\n\nSprawdzanie stanu plików:\n\nPodstawowe narzędzie używane do sprawdzenia stanu plików to polecenie git status. Jeśli uruchomisz je bezpośrednio po sklonowaniu repozytorium, zobaczysz wynik podobny do poniższego:\n\n\u003e git status  \n\n```\nOn branch master\nnothing to commit, working tree clean\n```\n\nOznacza to, że posiadasz czysty katalog roboczy — innymi słowy nie zawiera on śledzonych i zmodyfikowanych plików. Git nie widzi także żadnych plików nieśledzonych, w przeciwnym wypadku wyświetliłby ich listę. W końcu polecenie pokazuje również gałąź, na której aktualnie pracujesz. Póki co, jest to zawsze master, wartość domyślna.\n\n#### Dodanie pliku, status, śledzenie, status\n\nPowiedzmy, że dodajesz do repozytorium nowy, prosty plik. Jeżeli nie istniał on wcześniej, po uruchomieniu git status zobaczysz go jako plik nieśledzony, jak poniżej. Widać, że twój nowy plik nie jest jeszcze śledzony, ponieważ znajduje się pod nagłówkiem „Untracked files” (Nieśledzone pliki) w informacji o stanie. Nieśledzony oznacza, że Git widzi plik, którego nie miałeś w poprzedniej migawce (zatwierdzonej kopii); Git nie zacznie umieszczać go w przyszłych migawkach, dopóki sam mu tego nie polecisz. Zachowuje się tak, by uchronić cię od przypadkowego umieszczenia w migawkach wyników działania programu lub innych plików, których nie miałeś zamiaru tam dodawać.\n\nAby rozpocząć śledzenie nowego pliku, użyj polecenia git add. Jeśli uruchomisz teraz ponownie polecenie status, zobaczysz, że twój plik jest już śledzony i znalazł się pod nagłówkiem 'zmiany do zatwierdzenia'.\n\n```\nokkindel@hajduk  ~/Dokumenty/SOLVRO/Prelekcje/dump   master  git status\n\tOn branch master\n\tnothing to commit, working tree clean\nokkindel@hajduk  ~/Dokumenty/SOLVRO/Prelekcje/dump   master  touch file1\nokkindel@hajduk  ~/Dokumenty/SOLVRO/Prelekcje/dump   master  git status\n\tOn branch master\n\tUntracked files:\n  \t(use \"git add \u003cfile\u003e...\" to include in what will be committed)\n    file1\n\tnothing added to commit but untracked files present (use \"git add\" to track)\nokkindel@hajduk  ~/Dokumenty/SOLVRO/Prelekcje/dump   master  git add file1\nokkindel@hajduk  ~/Dokumenty/SOLVRO/Prelekcje/dump   master ✚  git status\n\tOn branch master\n\tChanges to be committed:\n  \t(use \"git reset HEAD \u003cfile\u003e...\" to unstage)\n\tnowy plik:     file1\n```\n\n#### Zmodyfikowanie istniejącego pliku, śledzenie\n\nZmodyfikujmy teraz plik, który był już śledzony. Jeśli zmienisz śledzony wcześniej plik, a następnie uruchomisz polecenie status, zobaczysz coś podobnego:\n\n```\nOn branch master\nChanges to be committed:\n  (use \"git reset HEAD \u003cfile\u003e...\" to unstage)\n\n        nowy plik:     file1\n\nChanges not staged for commit:\n  (use \"git add \u003cfile\u003e...\" to update what will be committed)\n  (use \"git checkout -- \u003cfile\u003e...\" to discard changes in working directory)\n\n        zmodyfikowany: LICENCE.md\n```\n\nPlik pojawia się w sekcji „Changes not staged for commit“ (Zmienione ale nie zaktualizowane), co oznacza, że śledzony plik został zmodyfikowany, ale zmiany nie trafiły jeszcze do poczekalni. Aby je tam wysłać, uruchom polecenie git add (jest to wielozadaniowe polecenie — używa się go do rozpoczynania śledzenia nowych plików, umieszczania ich w poczekalni, oraz innych zadań, takich jak oznaczanie rozwiązanych konfliktów scalania). Uruchom zatem git add by umieścić plik w poczekalni, a następnie ponownie wykonaj git status:\n\n```\nOn branch master\nChanges to be committed:\n  (use \"git reset HEAD \u003cfile\u003e...\" to unstage)\n\n        zmodyfikowany: LICENCE.md\n        nowy plik:     file1\n```\n\n#### Powtórne zmodyfikowanie istniejącego pliku\n\nOba pliki znajdują się już w poczekalni i zostaną uwzględnione podczas kolejnego zatwierdzenia zmian. Załóżmy, że w tym momencie przypomniałeś sobie o dodatkowej małej zmianie, którą koniecznie chcesz wprowadzić do pliku jeszcze przed zatwierdzeniem. Otwierasz go zatem, wprowadzasz zmianę i jesteś gotowy do zatwierdzenia. Uruchom jednak git status raz jeszcze.\n\nCo do licha? Plik widnieje teraz jednocześnie w poczekalni i poza nią. Jak to możliwe? Okazuje się, że Git umieszcza plik w poczekalni dokładnie z taką zawartością, jak w momencie uruchomienia polecenia git add. Jeśli w tej chwili zatwierdzisz zmiany, zostanie użyta wersja dokładnie z momentu uruchomienia polecenia git add, nie zaś ta, którą widzisz w katalogu roboczym w momencie wydania polecenia git commit. Jeśli modyfikujesz plik po uruchomieniu git add, musisz ponownie użyć git add, aby najnowsze zmiany zostały umieszczone w poczekalni\n\n### Wyłączenie śledzenia\n\nJeżeli się rozmyślimy i nie chcemy jednak śledzić naszego pliku aby go potem commitować możemy użyć polecenia git reset:\n\n\u003e git reset file\n\n## Ignorowanie plików\n\nCzęsto spotkasz się z klasą plików, w przypadku których nie chcesz, by Git automatycznie dodawał je do repozytorium, czy nawet pokazywał je jako nieśledzone. Są to ogólnie pliki generowane automatycznie, takie jak dzienniki zdarzeń, czy pliki tworzone w czasie budowania projektu. W takich wypadkach tworzysz plik zawierający listę wzorców do nich pasujących i nazywasz go .gitignore.\n\n## Zatwierdzanie zmian\n\nTeraz, kiedy twoja poczekalnia zawiera dokładnie to, co powinna, możesz zatwierdzić swoje zmiany. Pamiętaj, że wszystko czego nie ma jeszcze w poczekalni — każdy plik, który utworzyłeś lub zmodyfikowałeś, a na którym później nie uruchomiłeś polecenia git add — nie zostanie uwzględnione wśród zatwierdzanych zmian. Pozostanie wyłącznie w postaci zmodyfikowanych plików na twoim dysku.\n\nW tym wypadku, kiedy ostatnio uruchamiałeś git status, zobaczyłeś, że wszystkie twoje zmiany są już w poczekalni, więc jesteś gotowy do ich zatwierdzenia. Najprostszy sposób zatwierdzenia zmian to wpisanie git commit:\n\n\u003e git commit\n\nZostanie uruchomiony edytor tekstu. Po opuszczeniu edytora, Git stworzy nową migawkę opatrzoną twoim opisem zmian (uprzednio usuwając z niego komentarze i podsumowanie zmian). Alternatywnie opis rewizji możesz podać już wydając polecenie commit, poprzedzając go flagą -m. \n\nSama operacja rewizji zwróciła dodatkowo garść informacji, między innymi, gałąź do której dorzuciłeś zmiany (master), ich sumę kontrolną SHA-1, ilość zmienionych plików oraz statystyki dodanych i usuniętych linii kodu.\n\nAby następnie wypchnąć zaakceptowane zmiany na zewnętrzne repozytorium (w naszym przypadku GitHub), użyj polecenia push:\n\n\u003e git push\n\nPolecenie to zbiera wszystkie zatwoerdzone migawki i zapisuje je w skonfigurowanym wcześniej repozytorium.\n\n## Usuwanie plików\n\nAby usunąć plik z Gita, należy go najpierw wyrzucić ze zbioru plików śledzonych, a następnie zatwierdzić zmiany. Służy do tego polecenie git rm, które dodatkowo usuwa plik z katalogu roboczego. Nie zobaczysz go już zatem w sekcji plików nieśledzonych przy następnej okazji.\n\nJeżeli po prostu usuniesz plik z katalogu roboczego i wykonasz polecenie git status zobaczysz go w sekcji \"Zmienione ale nie zaktualizowane\" (Changes not staged for commit) (czyli, poza poczekalnią).\n\n### Cofanie zmian w zmodyfikowanym pliku\n\nZ pomocą przybywa raz jeszcze polecenie git status. Git konkretnie wskazuje jak pozbyć się dokonanych zmian. Zróbmy zatem co każe Git:\n\n\u003e git checkout -- file\n\nMożesz teraz przeczytać, że zmiany zostały cofnięte. Powinieneś sobie już także zdawać sprawę, że jest to dość niebezpieczne polecenie: wszelkie zmiany jakie wykonałeś w pliku przepadają - w rzeczy samej został on nadpisany poprzednią wersją. Nigdy nie używaj tego polecenia dopóki nie jesteś absolutnie pewny, że nie chcesz i nie potrzebujesz już danego pliku.\n\n## Podgląd historii\n\nPo kilku rewizjach, lub w przypadku sklonowanego repozytorium zawierającego już własną historię, przyjdzie czas, że będziesz chciał spojrzeć w przeszłość i sprawdzić dokonane zmiany. Najprostszym, a zarazem najsilniejszym, służącym do tego narzędziem jest git log.\n\n\u003e git log\n\nKomenda ta przyda nam się jeszcze później.\n\n## Praca ze zdalnym repozytorium\n\nW momencie, gdy chcemy wypchnąć zmiany na zewnętrzne repozytorium, okazuje się, że ktoś wprowadził swoje zmiany przed nami. Świadczy o tym wpis\n\n```\nTo https://github.com/okkindel/sample.git\n ! [rejected]        master -\u003e master (fetch first)\nerror: failed to push some refs to 'https://github.com/okkindel/sample.git'\npodpowiedź: Updates were rejected because the remote contains work that you do\npodpowiedź: not have locally. This is usually caused by another repository pushing\npodpowiedź: to the same ref. You may want to first integrate the remote changes\npodpowiedź: (e.g., 'git pull ...') before pushing again.\npodpowiedź: See the 'Note about fast-forwards' in 'git push --help' for details.\n```\n\nPo raz kolejny najlepiej będzie zrobić, to co podpowiada nam program. Użyjemy polecenia git pull:\n\n\u003e git pull\n\nJeśli znajdujesz się w gałęzi master i uruchomisz polecenie git pull, zmiany ze zdalnego repozytorium zaraz po pobraniu automatycznie zostaną scalone z gałęzią master w twoim, lokalnym repozytorium.\n\n## Gałęzie\n\nPrawie każdy system kontroli wersji posiada wsparcie dla gałęzi. Rozgałęzienie oznacza odbicie od głównego pnia linii rozwoju i kontynuację pracy bez wprowadzania tam bałaganu. W wielu narzędziach kontroli wersji jest to proces dość kosztowny, często wymagający utworzenia nowej kopii katalogu z kodem, co w przypadku dużych projektów może zająć sporo czasu.\n\nNiektórzy uważają model gałęzi Gita za jego „killer feature” i z całą pewnością wyróżnia go spośród innych narzędzi tego typu. Co w nim specjalnego? Sposób, w jaki Git obsługuje gałęzie, jest niesamowicie lekki, przez co tworzenie nowych gałęzi jest niemalże natychmiastowe, a przełączanie się pomiędzy nimi trwa niewiele dłużej. W odróżnieniu od wielu innych systemów, Git zachęca do częstego rozgałęziania i scalania projektu, nawet kilkukrotnie w ciągu jednego dnia. Zrozumienie i opanowanie tego wyjątkowego i potężnego mechanizmu może dosłownie zmienić sposób, w jaki pracujesz.\n\nJak utworzyć nową gałąź? Jest to bardzo proste i wymaga jedynie wpisania jednej komendy:\n\n\u003e git branch testing\n\nSkąd Git wie, na której gałęzi się aktualnie znajdujesz? Utrzymuje on specjalny wskaźnik o nazwie HEAD. W Gicie jest to wskaźnik na lokalną gałąź, na której właśnie się znajdujesz. W tym wypadku, wciąż jesteś na gałęzi master. Polecenie git branch utworzyło jedynie nową gałąź, ale nie przełączyło cię na nią.\n\nAby przełączyć się na istniejącą gałąź, używasz polecenia git checkout. Przełączmy się zatem do nowo utworzonej gałęzi testing:\n\n\u003e git checkout testing\n\nIstnieje sposób na utworzenie nowej gałęzi i jednoczesne przełączenie się na nią. Robimy to komendą:\n\n\u003e git checkout -b testing\n\nNowa gałąź zawiera migawkę z momentu tworzenia tej gałęzi, oznaca to, że od tej chwili na obu gałęziach możemy tworzyć zupełnie różne zmiany a Git będzie rozpatrywał je osobno dla każdej gałęzi.\n\n### Podgląd wszystkich gałęzi\n\nPolecenie:\n\n\u003e git branch\n\npozwala na wylistowanie nazw wszystkich lokalnych gałęzi. Aby zobaczyć wszystkie gałęzie w repozytorium, polecenie to musimy poprzedzić komendą:\n\n\u003e git pull\n\n## Scalanie gałęzi\n\n* Pod warunkiem, że nie ma konfliktu zmian pomiędzy galęziami\n\n\t\u003e git merge nazwa_gałęzi\n\n* Rozwiązywanie konflików na przykładzie VS Code\n\nJeżeli chcemy przełączyć się na inną gałąź podczas pisania kodu, Git poinformuje nas, że mamy niezaakceptowane zmiany. Mamy w tym momencie 3 wyjścia:\n\n1. Usunięcie swoich zmian od czasu ostatniego commita:\n\n\t\u003e git reset --hard\n\n2. Zaakceptowanie wszystkich zmian:\n\n\t\u003e git add .  \n\t\u003e git commit -m \"commit message\"  \n\n3. Skopiowanie zmian do schowka:\n\n\t\u003e git stash\n\n\taby przywrócić zmiany, po ponownym przełączeniu się na odpowiednią gałąź wpisujemy\n\n\t\u003e git stash pop\n\n## Poruszanie się po historii repozytorium\n\nPolecenie\n\n\u003e git log\n\nlistuje wszystkie commity na zadanym branchu. Przełączać możemy się nie tylko pomiędzy gałęziami ale również pomiędzy commitami w historii. W tym celu kopiujemy hash commita z historii i używamy komendy:\n\n\u003e git checkout hash\n\nMożemy się również przełączyć o zadaną ilość migawek do tyłu.\n\n\u003e git checkout HEAD~2\n\nMożemy z takiej pozycji utworzyć nowego brancha. Aby wrócić do najświeższych zmian, możemy przełączyć się spowrotem na gałąź, np:\n\n\u003e git checkout master\n\n## Merge requesty\n\n*Na przykładzie GitHuba*\n\n## Przydatne programy\n\n- zsh + ohmyzsh + git plugin\n- fuzzy finder\n- zsh autocomplete\n- fuck\n\n## skróty w git plugin dla zsh\n\n- g\n- gp\n- gcmsg\n- gst\n- glg\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsolvro%2Fgit-wprowadzenie","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fsolvro%2Fgit-wprowadzenie","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsolvro%2Fgit-wprowadzenie/lists"}