Fix Polish translation

src/levels/intro/branching.js

@@ -1408,8 +1408,8 @@ exports.level = {
             "markdowns": [
               "*Uwaga: w wersji 2.23 Gita zostało wprowadzono nowe polecenie o nazwie \n`git switch`, które zastępuje polecenie `git checkout`, ",
               "a jest nieco przeciążone (robi kilka oddzielnych rzeczy). Tutaj nadal będziemy używać",
-              "`checkout` zamiast `switch`, ponieważ wciąż jest to najczęściej stosowane polecenie",
+              "`checkout` zamiast `switch`, ponieważ wciąż jest to najczęściej stosowane polecenie.",
-              "Jeśli chcesz, możesz je wypróbować, ta aplikacja jest na to gotowa! Jeśli chcesz dowiedzieć się więcej o poleceniu <a href=\"https://git-scm.com/docs/git-switch\" target=\"_blank\">, zajrzyj tutaj</a>.* "
+              "Jeśli chcesz, możesz je wypróbować, ta aplikacja jest na to gotowa! Jeśli chcesz dowiedzieć się więcej o poleceniu, <a href=\"https://git-scm.com/docs/git-switch\" target=\"_blank\">zajrzyj tutaj</a>.* "
             ]
           }
         },

src/levels/mixed/describe.js

@@ -1000,7 +1000,7 @@ exports.level = {
               "",
               "Ponieważ znaczniki służą jako świetne \"kotwice\" w bazie kodu, git ma polecenie *opisujące*, gdzie jesteś w stosunku do najbliższej \"kotwicy\". I jest to `git describe`!",
               "",
-              "`Git describe` może pomóc ci zorientować się w sytuacji, gdy przesuniesz wiele commitów wstecz lub do przodu w historii; może się to zdarzyć po użyciu git bisect (na potrzeby debugowania) lub gdy siedzisz przy komputerze współpracownika, który właśnie wrócił z wakacji."
+              "Polecenie `git describe` może pomóc ci zorientować się w sytuacji, gdy przesuniesz wiele commitów wstecz lub do przodu w historii; może się to zdarzyć po użyciu `git bisect` (na potrzeby debugowania) lub gdy siedzisz przy komputerze współpracownika, który właśnie wrócił z wakacji."
             ]
           }
         },

src/levels/mixed/grabbingOneCommit.js

@@ -685,11 +685,11 @@ exports.level = {
             "markdowns": [
               "## Lokalnie nałożone commity",
               "",
-              "Oto sytuacja, która często się zdarza podczas pisania kodu: próbuję wytropić buga, ale on jest nieuchwytny. Aby pomóc sobie w poszukiwaniach, dodaję kilka poleceń debugowania i kilka instrukcji print.",
+              "Oto sytuacja, która często się zdarza podczas pisania kodu: próbuję wytropić buga, ale jest on nieuchwytny. Aby pomóc sobie w poszukiwaniach, dodaję kilka poleceń debugowania i kilka instrukcji print.",
               "",
               "Wszystkie te polecenia debugowania / drukowania znajdują się w osobnych commitach. W końcu namierzam błąd, naprawiam go i cieszę się!",
               "",
-              "Jedynym problemem jest to, że teraz muszę przywrócić mój `bugFix` do gałęzi `main`. Jeśli po prostu zrobiłbym fast-foward `main`, wtedy `main` dostałby wszystkie moje deklaracje debugowania, a tego bym nie chciał. Musi być na to inny sposób. . ."
+              "Jedynym problemem jest to, że teraz muszę przywrócić mój `bugFix` do gałęzi `main`. Jeśli po prostu zrobiłbym fast-foward `main`, wtedy `main` dostałby wszystkie moje deklaracje debugowania, a tego bym nie chciał. Musi być na to inny sposób..."
             ]
           }
         },

src/levels/mixed/jugglingCommits.js

@@ -632,7 +632,7 @@ exports.level = {
               "* Na koniec przeniesiemy się do tej zaktualizowanej części drzewa, aby ukończyć ten poziom (w wybrany przez ciebie sposób)",
               "",
               "Istnieje wiele sposobów na osiągnięcie tego ogólnego celu (widzę, że masz na oku cherry-pick), i później zobaczymy ich więcej, ale na razie skupmy się na tej technice.",
-              "Na koniec zwróć uwagę na stan celu - ponieważ przenosimy commity dwukrotnie, oba otrzymują apostrof. Dodajemy jeszcze jeden apostrof dla commitu, który zmieniamy, co daje nam ostateczną postać drzewa",
+              "Na koniec zwróć uwagę na stan celu - ponieważ przenosimy commity dwukrotnie, oba otrzymują apostrof. Dodajemy jeszcze jeden apostrof dla commitu, który zmieniamy, co daje nam ostateczną postać drzewa.",
               "",
               "Uwzględniając to, mogę teraz porównać poziomy w oparciu o strukturę i względne różnice apostrofów. Tak długo, jak gałąź `main` twojego drzewa ma taką samą strukturę, rozwiązanie zostanie uznane."
             ]

src/levels/mixed/jugglingCommits2.js

@@ -760,7 +760,7 @@ exports.level = {
           "type": "GitDemonstrationView",
           "options": {
             "beforeMarkdowns": [
-              "Pamiętaj, że git cherry-pick zrzuci commit z dowolnego miejsca drzewa na HEAD (o ile ten commit nie jest przodkiem HEAD).",
+              "Pamiętaj, że `git cherry-pick` zrzuci commit z dowolnego miejsca drzewa na HEAD (o ile ten commit nie jest przodkiem HEAD).",
               "",
               "Oto małe demo na odświeżenie pamięci:"
             ],

src/levels/mixed/tags.js

@@ -884,7 +884,7 @@ exports.level = {
             "markdowns": [
               "## Tagi Gita",
               "",
-              "Jak wiesz z poprzednich lekcji, gałęzie łatwo przemieszczać, i w momencie ukończenia pracy nad nimi często odnoszą się do różnych commitów. Gałęzie łatwo ulegają mutacjom, często są tymczasowe i zawsze się zmieniają.",
+              "Jak wiesz z poprzednich lekcji, gałęzie łatwo przemieszczać, a w momencie ukończenia pracy nad nimi, często odnoszą się do różnych commitów. Gałęzie łatwo ulegają mutacjom, często są tymczasowe i zawsze się zmieniają.",
               "",
               "A skoro tak, to możesz się zastanawiać, czy istnieje sposób na *trwałe* zaznaczanie ważnych punktów  w historii projektu. Czy istnieje jakiś sposób na oznaczenie tych commitów czymś bardziej trwałym niż gałąź, w przypadku takich rzeczy jak duże wydania i duże scalenia/ merge?",
               ""

src/levels/rampup/interactiveRebase.js

@@ -1124,7 +1124,7 @@ exports.level = {
           "type": "ModalAlert",
           "options": {
             "markdowns": [
-              "Kiedy otworzy się okno dialogowe do interaktywnego przeabazowania, masz możliwość zrobienia dwóch rzeczy w naszej aplikacji edukacyjnej:",
+              "Kiedy otworzy się okno dialogowe do interaktywnego przebazowania, masz możliwość zrobienia dwóch rzeczy w naszej aplikacji edukacyjnej:",
               "",
               "* Możesz zmienić kolejność commitów, po prostu przeciągając i upuszczając je myszką w oknie.",
               "* Możesz zdecydować się zachować wszystkie commity lub pominąć niektóre z nich. Jest to oznaczone przez aktywny przycisk `pick`. Wyłączenie przycisku spowoduje pominięciu commitu.",

src/levels/rampup/relativeRefs.js

@@ -1248,7 +1248,7 @@ exports.level = {
           "type": "ModalAlert",
           "options": {
             "markdowns": [
-              "## Relatywne referencje",
+              "## Referencje względne",
               "",
               "Poruszanie się w Gicie poprzez określanie haszy commitów może być trochę nudne. W prawdziwym świecie nie zobaczysz ładnej wizualizacji drzewa commitów obok swojego terminala (chyba, że używasz Forka lub TortoiseGita). Musisz użyć `git log`, aby zobaczyć hasze.",
               "",
@@ -1277,13 +1277,13 @@ exports.level = {
           "type": "GitDemonstrationView",
           "options": {
             "beforeMarkdowns": [
-              "Spójrzmy najpierw na operator Karety / daszek (^). Za każdym razem, gdy dodajesz go do referencji względnej, mówisz Gitowi, aby znalazł rodzica określonego commita.",
+              "Spójrzmy najpierw na operator karety / daszek (^). Za każdym razem, gdy dodajesz go do referencji względnej, mówisz Gitowi, aby znalazł rodzica określonego commita.",
               "",
-              "Więc wpisując `main^`, mamy na myśli \"pierwszego rodzica z gałęzi `main`\".",
+              "Wpisując zatem `main^`, mamy na myśli \"pierwszego rodzica z gałęzi `main`\".",
               "",
-              "`main^^` to dziadek (przodek drugiego stopnia) gałęzi `main`",
+              "`main^^` to dziadek (przodek drugiego stopnia) gałęzi `main`.",
               "",
-              "checkoutujmy commit powyżej `main`."
+              "Zcheckoutujmy commit powyżej `main`:"
             ],
             "afterMarkdowns": [
               "Tadam! Gotowe! O wiele łatwiej niż wpisując hasz commita."

src/levels/rampup/reversingChanges.js

@@ -1064,7 +1064,7 @@ exports.level = {
               "",
               "Istnieje wiele sposobów na odwrócenie zmian w Gicie. Podobnie jak w przypadku commitowania, odwracanie zmian w Gicie ma zarówno komponent niskopoziomowy (zapisywanie stanów plików lub ich fragmentów), jak i wysokopoziomowy (sposób, w jaki zmiany są faktycznie odwracane). Nasza aplikacja skupi się na tym ostatnim.",
               "",
-              "Istnieją dwa podstawowe sposoby na cofnięcie zmian w Gicie - jeden z nich to `git reset`, a drugi `git revert`. Przyjrzymy się każdemu z nich w następnym oknie",
+              "Istnieją dwa podstawowe sposoby na cofnięcie zmian w Gicie - jeden z nich to `git reset`, a drugi `git revert`. W następnym oknie przyjrzymy się każdemu z nich.",
               ""
             ]
           }
@@ -1075,7 +1075,7 @@ exports.level = {
             "beforeMarkdowns": [
               "## Git Reset",
               "",
-              "`git reset` odwraca zmiany poprzez przesunięcie referencji gałęzi wstecz w czasie do starszego commita. Można myśleć o tym jako \"przepisywaniu historii\", \"resetowanie\" spowoduje cofnięcie gałęzi, tak jakby commit nigdy nie został dodany.",
+              "`git reset` odwraca zmiany poprzez przesunięcie referencji gałęzi wstecz w czasie do starszego commita. Można myśleć o tym jako \"przepisywaniu historii\"; \"resetowanie\" spowoduje cofnięcie gałęzi, tak jakby commit nigdy nie został dodany.",
               "",
               "Sprawdźmy, jak to działa:"
             ],

src/levels/rebase/selectiveRebase.js

@@ -352,7 +352,7 @@ exports.level = {
             "markdowns": [
               "## Spaghetti gałęzi",
               "",
-              "Łałałiła! Na tym poziomie mamy poważny cel do osiągnięcia..",
+              "Łałałiła! Na tym poziomie mamy poważny cel do osiągnięcia.",
               "",
               "Mamy tutaj gałąź `main`, która jest kilka commitów przed gałęziami `one`, `two` i `three`. Z jakiegoś powodu musimy zaktualizować te trzy inne gałęzie zmodyfikowanymi wersjami ostatnich kilku commitów na main.",
               "",

src/levels/remote/clone.js

@@ -922,7 +922,7 @@ exports.level = {
               "",
               "Do tego momentu kurs Learn Git Branching skupiał się na nauczaniu podstaw pracy z repozytoriami _lokalnymi_ (branch, merge, rebase itp.). Jednak teraz, gdy chcemy dowiedzieć się więcej o pracy ze zdalnym repozytorium, potrzebujemy polecenia, aby skonfigurować środowisko tych lekcji. Tym poleceniem będzie `git clone`.",
               "",
-              "Technicznie rzecz biorąc, `git clone` w prawdziwym świecie jest poleceniem, którego będziesz używać do tworzenia _lokalnych_ kopii zdalnych repozytoriów (na przykład z github). Używamy tego polecenia nieco inaczej w Learn Git Branching -- `git clone` faktycznie tworzy zdalne repozytorium z lokalnego. Jasne, jest to technicznie odwrotne znaczenie prawdziwego polecenia, ale pomaga zrozumieć zależność między klonowaniem a pracą na zdalnym repozytorium, więc na razie zobaczmy, jak to wygląda w działaniu.",
+              "Technicznie rzecz biorąc, `git clone` w prawdziwym świecie jest poleceniem, którego będziesz używać do tworzenia _lokalnych_ kopii zdalnych repozytoriów (na przykład z GitHuba). Używamy tego polecenia nieco inaczej w Learn Git Branching -- `git clone` faktycznie tworzy repozytorium zdalne z lokalnego. Jasne, jest to technicznie odwrotne znaczenie prawdziwego polecenia, ale pomaga zrozumieć zależność między klonowaniem a pracą na zdalnym repozytorium, więc na razie zobaczmy, jak to wygląda w działaniu.",
               ""
             ]
           }

src/levels/remote/fetch.js

@@ -1189,7 +1189,7 @@ exports.level = {
             "markdowns": [
               "### Czego fetch nie robi",
               "",
-              "Zauważ, że `git fetch` nie zmienia nic w _twoim_ stanie lokalnym. Nie zaktualizuje twjej gałęzi `main` ani nie zmieni niczego w wyglądzie twojego systemu plików.",
+              "Zauważ, że `git fetch` nie zmienia nic w _twoim_ stanie lokalnym. Nie zaktualizuje twojej gałęzi `main` ani nie zmieni niczego w wyglądzie twojego systemu plików.",
               "",
               "Zrozumienie tego to ważna sprawa! Wielu programistów uważa, że uruchomienie `git fetch` spowoduje, że ich lokalna praca będzie odzwierciedlać stan zdalny. Mimo że `git fetch` pobiera wszystkie niezbędne do tego dane, _nie zmienia_ żadnego z plików lokalnych. Poleceń, które służą właśnie do tego celu, nauczymy się później. :D",
               "",

src/levels/remote/fetchRebase.js

@@ -2205,7 +2205,7 @@ exports.level = {
             "markdowns": [
               "Wyobraźmy sobie, że klonujesz repozytorium w poniedziałek i zaczynasz pracować nad dodatkową funkcjonalnością. W piątek chcesz opublikować swoje zmiany -- ale, o nie! Współpracownicy napisali w ciągu tygodnia mnóstwo kodu, który sprawił, że twoja praca stała się nieaktualna (przestarzała). Opublikowali również te poprawki we wspólnym zdalnym repozytorium, więc teraz *twoja* praca jest oparta na *starej* wersji projektu, która nie jest już aktualna.",
               "",
-              "W tym przypadku komenda `git push` jest niejednoznaczna. Jeśli uruchomisz `git push`: czy Git powinien zmienić zdalne repozytorium z powrotem na takie, jakie było w poniedziałek? Czy powinien próbować dodać twój kod, nie usuwając jednocześnie nowego kodu? Czy też ma całkowicie zignorować twoje zmiany, ponieważ są one zupełnie przestarzałe?",
+              "W tym przypadku komenda `git push` jest niejednoznaczna. Jeśli uruchomisz `git push`, to czy Git powinien zmienić zdalne repozytorium z powrotem na takie, jakie było w poniedziałek? Czy może powinien próbować dodać twój kod, nie usuwając jednocześnie nowego kodu? Czy może też ma całkowicie zignorować twoje zmiany, ponieważ są one zupełnie przestarzałe?",
               "",
               "Ponieważ w tej sytuacji (gdzie historia się rozbiegła) jest tak wiele niejasności, Git nie pozwala ci na `push` twoich zmian. W rzeczywistości zmusza cię do połączenia najnowszego stanu remote'a, zanim pozwoli ci udostępnić swoją pracę."
             ]

src/levels/remote/pullArgs.js

@@ -1168,7 +1168,7 @@ exports.level = {
               "",
               "Teraz, kiedy wiesz już właściwie *wszystko*, co można wiedzieć o argumentach `git fetch` oraz `git push`, naprawdę nie zostało już prawie nic do omówienia przy `git pull` :)",
               "",
-              "To dlatego, że w zasadzie git pull to *naprawdę* tylko skrót polecenia fetch i scalania wszystkiego, co zostało nim pobrane. Możesz to sobie wyobrazić jako uruchomienie git fetch z określonymi *tymi samymi* argumentami, a potem scalenie pobranych commitów *tam*, dokąd trafiły.",
+              "To dlatego, że w zasadzie `git pull` to *naprawdę* tylko skrót polecenia fetch i scalania wszystkiego, co zostało nim pobrane. Możesz to sobie wyobrazić jako uruchomienie `git fetch` z określonymi *tymi samymi* argumentami, a potem scalenie pobranych commitów *tam*, dokąd trafiły.",
               "",
               "I działa to w ten sposób, nawet jeśli określisz kompletnie szalone argumenty. Zobaczmy kilka przykładów:"
             ]
@@ -1190,7 +1190,7 @@ exports.level = {
               "",
               "`git fetch origin bar~1:bugFix; git merge bugFix`",
               "",
-              "Widzisz? git pull to naprawdę tylko skrót dla fetch + merge i jedyne, co się liczy dla git pull, to gdzie trafią commity (argument `celu`, który Git zinterpretuje sobie, wykonując fetch).",
+              "Widzisz? Polecenie `git pull` to naprawdę tylko skrót dla fetch + merge i jedyne, co się liczy dla `git pull`, to gdzie trafią commity (argument `celu`, który Git zinterpretuje sobie, wykonując fetch).",
               "",
               "Zobaczmy demo:"
             ]

src/levels/remote/push.js

@@ -695,9 +695,9 @@ exports.level = {
               "",
               "Możesz myśleć o `git push` jak o poleceniu do \"publikowania\" swojej pracy. Ma ono wiele szczegółów, które wkrótce omówimy, ale zacznijmy od małych kroczków...",
               "",
-              "*uwaga -- zachowanie `git push` bez argumentów różni się w zależności od jednego z ustawień Git o nazwie `push.default`. Domyślna wartość tego ustawienia zależy od wersji Git, której używasz. W naszych lekcjach będziemy używać wartości `upstream`. Nie jest to wielka sprawa, ale warto sprawdzić swoje ustawienia przed użyciem `push` we własnych projektach.*",
+              "*Uwaga 1 -- zachowanie `git push` bez argumentów różni się w zależności od jednego z ustawień Git o nazwie `push.default`. Domyślna wartość tego ustawienia zależy od wersji Git, której używasz. W naszych lekcjach będziemy używać wartości `upstream`. Nie jest to wielka sprawa, ale warto sprawdzić swoje ustawienia przed użyciem `push` we własnych projektach.*",
               "",
-              "*uwaga 2 -- odpowiednik gałęzi na zdalnym repozytorium będziemy nazywać remote'em. Nazwa ta jest wykorzystywana w Polsce, dlatego będziemy jej używać, aby nie wprowadzać zawiłego nazewnictwa*"
+              "*Uwaga 2 -- odpowiednik gałęzi na zdalnym repozytorium będziemy nazywać remote'em. Nazwa ta jest wykorzystywana w Polsce, dlatego będziemy jej używać, aby nie wprowadzać zawiłego nazewnictwa.*"
             ]
           }
         },

src/levels/remote/sourceNothing.js

@@ -852,7 +852,7 @@ exports.level = {
             "markdowns": [
               "### Osobliwości `<source>`",
               "",
-              "Git pozwala wykorzystać parametr `<source>` (źródło) na dwa osobliwe sposoby. Oba są dziwaczne dlatego, że - technicznie rzecz biorąc - możesz określić \"nic\" jako poprawne `źródło` zarówno dla git push, jak i git fetch. Tę \"nicość\" określasz za pomocą pustego argumentu:",
+              "Git pozwala wykorzystać parametr `<source>` (źródło) na dwa osobliwe sposoby. Oba są dziwaczne dlatego, że - technicznie rzecz biorąc - możesz określić \"nic\" jako poprawne `źródło` zarówno dla `git push`, jak i `git fetch`. Tę \"nicość\" określasz za pomocą pustego argumentu:",
               "",
               "* `git push origin :side`",
               "* `git fetch origin :bugFix`",