PL translation added

src/levels/remote/fetchArgs.js

@@ -17,7 +17,8 @@ exports.level = {
     "ko": "Fetch의 인자들",
     "uk": "Аргументи для fetch",
     "vi": "Tham số fetch",
-    "sl_SI": "Fetch argumenti"
+    "sl_SI": "Fetch argumenti",
+    "pl": "Argumenty fetch"
   },
   "hint": {
     "en_US": "Pay attention how the commit ids may have swapped! You can read slides again with \"help level\"",
@@ -34,7 +35,8 @@ exports.level = {
     "ko": "커밋 ID가 바뀔수도있으니 주의하세요! \"help level\"을 입력하면 슬라이드들을 다시 읽어볼수 있습니다.",
     "uk": "Зверни увагу на те, що номери комітів можуть змінюватися! Слайди уроку можна переглянути ще раз командою \"help level\"",
     "vi": "Lưu ý id của các commit bị tráo đổi, bạn có thể dùng \"help level\" để đọc lại hội thoại",
-    "sl_SI": "Bodi pozoren kako so se commit id-ji morda zamenjali! Ponovno lahko prebereš navodila z \"help level\"."
+    "sl_SI": "Bodi pozoren kako so se commit id-ji morda zamenjali! Ponovno lahko prebereš navodila z \"help level\".",
+    "pl": "Zauważ, że identyfikatory commitów mogły zostać zamienione! Slajdy możesz przeczytać jeszcze raz po wpisaniu: \"help level\""
   },
   "startDialog": {
     "en_US": {
@@ -1896,6 +1898,129 @@ exports.level = {
           }
         }
       ]
+    },
+    "pl": {
+      "childViews": [
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "## Argumenty git fetch",
+              "",
+              "No to właśnie nauczyliśmy się o argumentach git push, o tym fajnym parametrze `<place>`, a nawet o refspec z dwukropkiem (`<źródło>:<cel>`). Czy możemy tę samą wiedzę zastosować też przy `git fetch`?",
+              "",
+              "No ba... Argumenty `git fetch` są w gruncie rzeczy *bardzo, bardzo* podobne do tych z `git push`. To ta sama idea, tyle że zastosowana w odwrotną stronę (przecież nie wysyłasz commitów, tylko je pobierasz).",
+              "",
+              "Powtórzmy krok po kroku na czym to polega..."
+            ]
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "###  Parametr `<place>` (miejsce)",
+              "",
+              "Jeśli w git fetch określisz miejsce, tak jak w tym poleceniu:",
+              "",
+              "`git fetch origin foo`",
+              "",
+              "Git przejdzie do gałęzi `foo` w zdalnym repozytorium, weźmie wszystkie commity, których brakuje lokalnie i zrzuci je nam na lokalną gałąź `o/foo`.",
+              "",
+              "Zobaczmy, jak to działa (tylko dla odświeżenia pamięci)."
+            ]
+          }
+        },
+        {
+          "type": "GitDemonstrationView",
+          "options": {
+            "beforeMarkdowns": [
+              "Określając miejsce..."
+            ],
+            "afterMarkdowns": [
+              "pobraliśmy tylko commity z `foo` i umieściliśmy je na `o/foo`."
+            ],
+            "command": "git fetch origin foo",
+            "beforeCommand": "git branch foo; git clone; git fakeTeamwork foo 2"
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "Może się zastanawiasz, dlaczego Git zrzucił te commity na zdalną gałąź `o/foo`, a nie tylko na lokalną gałąź `foo`? Wydawało się, że parametr `<place>` to miejsce istniejące zarówno lokalnie, jak i na zdalnym repozytorium.",
+              "",
+              "Cóż... Git robi w tym miejscu bardzo wyjątkowy wyjątek, bo wie, że możesz mieć na gałęzi `foo` pracę, w której nie chcesz namieszać!!! Łączy się to z wcześniejszą lekcją o `git fetch`. To polecenie nie aktualizuje twoich lokalnych gałęzi - ono tylko pobiera commity (a ty możesz je sobie obejrzeć i scalić później).",
+              ""
+            ]
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "\"No to co się w takim razie stanie, jeśli samodzielnie określę źródło i cel za pomocą `<source>:<destination>`?\"",
+              "",
+              "Jeśli naprawdę czujesz wewnętrzną potrzebę, żeby robić fetch *bezpośrednio* na lokalną gałąź, to proszę bardzo, możesz wykorzystać refspec z dwukropkiem. Nie możesz tylko ściągnąć przy użyciu fetch commitów na aktualnie wybraną za pomocą checkout gałąź. Poza tym Git pozwoli ci zrobić, co chcesz..",
+              "",
+              "Jest jednak jeden haczyk -- `<źródło>` to teraz *zdalne* miejsce, a `<cel>` jest *lokalnym* miejscem, na które trafią commity. To dokładne przeciwieństwo git push, i to ma sens, skoro przenosimy teraz dane w odwrotnym kierunku!",
+              "",
+              "No ale w praktyce mało kto tak robi. Tłumaczę to głównie po to, żeby uzmysłowić ci, że `fetch` i `push` są dość podobne, tylko działają w odwrotne strony."
+            ]
+          }
+        },
+        {
+          "type": "GitDemonstrationView",
+          "options": {
+            "beforeMarkdowns": [
+              "Zobaczmy, jak to szaleństwo działa:"
+            ],
+            "afterMarkdowns": [
+              "Nieźle! Spójrz. Git zinterpretował `foo~1` jako miejsce na origin i pobrał z niego commity do `bar` (czyli lokalną gałąź). Zauważ, że ani `foo` ani `o/foo` nie zostały zaktualizowane, ponieważ określiliśmy cel."
+            ],
+            "command": "git fetch origin foo~1:bar",
+            "beforeCommand": "git branch foo; git clone; git branch bar; git fakeTeamwork foo 2"
+          }
+        },
+        {
+          "type": "GitDemonstrationView",
+          "options": {
+            "beforeMarkdowns": [
+              "A co, jeśli cel nie istnieje przed wykonaniem polecenia? Spójrzmy jeszcze na ostatni slajd, na którym `bar` na początku nie ma."
+            ],
+            "afterMarkdowns": [
+              "Widzisz, to działa DOKŁADNIE jak git push. Git stworzył lokalnie cel przed wykonaniem fetch, dokładnie tak samo jak zrobiłby to na zdalnym repozytorium przed zrobieniem push (gdyby cel tam nie istniał)."
+            ],
+            "command": "git fetch origin foo~1:bar",
+            "beforeCommand": "git branch foo; git clone; git fakeTeamwork foo 2"
+          }
+        },
+        {
+          "type": "GitDemonstrationView",
+          "options": {
+            "beforeMarkdowns": [
+              "Bez argumentów?",
+              "",
+              "Jeśli `git fetch` nie dostanie żadnych argumentów, to po prostu ściągnie wszystkie commity ze zdalnego repozytorium do wszystkich zdalnych gałęzi..."
+            ],
+            "afterMarkdowns": [
+              "Niby proste, ale warto to zobaczyć chociaż raz."
+            ],
+            "command": "git fetch",
+            "beforeCommand": "git branch foo; git clone; git fakeTeamwork foo; git fakeTeamwork main"
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "Dobra, dość gadania! Żeby ukończyć ten poziom, użyj fetch tylko do commitów określonych w wizualizacji celu. Pokombinuj trochę z tymi poleceniami!",
+              "",
+              "Dla obu poleceń fetch musisz określić źródło i cel. Przyjrzyj się dokładnie wizualizacji celu; identyfikatory mogą być zamienione miejscami!"
+            ]
+          }
+        }
+      ]
     }
   }
 };

src/levels/remote/lockedMain.js

@@ -15,7 +15,8 @@ exports.level = {
     "ko": "로컬 저장소의 main 브랜치로부터 feature 브랜치를 만드세요. 그리고 o/main과 같아질 수 있도록 로컬 저장소의 main 브랜치를 reset 하세요.",
     "sl_SI": "Naredi feature branch iz lokalnega masterja preden ga ponastaviš, da bo enak kot origin main.",
     "es_AR": "Crea la rama feature desde la rama main en local antes de restablecerlo para que sea el mismo que la rama main de origen.",
-    "ja": "mainブランチをoriginのmainと同じ状態になるようにリセットする前に、ローカルのmainからfeatureブランチを作成します。"
+    "ja": "mainブランチをoriginのmainと同じ状態になるようにリセットする前に、ローカルのmainからfeatureブランチを作成します。",
+    "pl": "Stwórz boczną gałąź tematyczną (feature) z lokalnego main, a późnej zsynchronizuj ją z main na origin"
   },
   "name": {
     "en_US": "Locked Main",
@@ -30,7 +31,8 @@ exports.level = {
     "ko": "잠겨버린 main 브랜치",
     "sl_SI": "Zaklenjen Main",
     "es_AR": "Main bloqueado",
-    "ja": "ロックされたmain"
+    "ja": "ロックされたmain",
+    "pl": "Zablokowany main"
   },
   "startDialog": {
     "en_US": {
@@ -564,5 +566,45 @@ exports.level = {
         }
       ]
     },
+    "pl": {
+      "childViews": [
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "## Remote odrzuca!",
+              "",
+              "Jeśli pracujesz w dużym zespole, to może się zdarzyć, że main będzie zablokowany i przed scaleniem zmian trzeba będzie zrobić pull request. Jeśli commitujesz bezpośrednio do lokalnego main i spróbujesz zrobić push, to możesz dostać wiadomość podobną do tej:",
+              "",
+              "```",
+              " ! [remote rejected] main -> main (TF402455: Pushes to this branch are not permitted; you must use a pull request to update this branch.)",
+              "```"
+            ]
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "## Skąd to odrzucenie?",
+              "",
+              "Remote odrzuca pushowanie twoich commitów bezpośrednio do main ze względu na regułę wymagającą korzystania z pull requestów.",
+              "",
+              "Twoim zamiarem było najpierw stworzyć gałąź, a potem wypchnąć ją do zdalnego repozytorium i zrobić pull request, ale zamiast tego commitujesz bezpośrednio do main. Dlatego masz problem i nie możesz wypchnąć swoich zmian."
+            ]
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "## Rozwiązanie",
+              "",
+              "Stwórz inną gałąź, nazywaną często boczną albo tematyczną, a po angielsku: feature (funkcyjną) i wypchnij ją do remote. Zresetuj również swój main, tak aby był zsynchronizowany ze zdalnym repozytorium. Jeśli tego nie zrobisz, to możesz mieć problem następnym razem, kiedy zrobisz pull, a czyjś commit będzie miał konflikt z twoim."
+            ]
+          }
+        }
+      ]
+    },
   }
 };

src/levels/remote/mergeManyFeatures.js

@@ -17,7 +17,8 @@ exports.level = {
     "ko": "원격 작업과 merge하기",
     "uk": "Мердж з віддаленим репозиторієм",
     "vi": "Hợp nhất nhánh từ xa",
-    "sl_SI": "Merganje z oddaljenim repozitorijem"
+    "sl_SI": "Merganje z oddaljenim repozitorijem",
+    "pl": "Scalanie z remote"
   },
   "hint": {
     "en_US": "Pay attention to the goal tree!",
@@ -34,7 +35,8 @@ exports.level = {
     "ko": "goal을 잘 살펴보세요!",
     "uk": "Уважно подивись як має виглядати результат!",
     "vi": "Hãy để ý đến cây mục tiêu!",
-    "sl_SI": "Poglej si ciljno drevo!"
+    "sl_SI": "Poglej si ciljno drevo!",
+    "pl": "Zwróć uwagę, jak wygląda docelowe drzewo!"
   },
   "compareOnlyMain": true,
   "startDialog": {
@@ -712,6 +714,51 @@ exports.level = {
           }
         }
       ]
+    },
+    "pl": {
+      "childViews": [
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "## Dlaczego nie merge?",
+              "",
+              "Aby wypchnąć nowe wersje, musisz tylko *nanieść* najnowsze zmiany ze zdalnego repozytorium. A to znaczy, że możesz zrobić albo rebase, *albo* merge gałęzi w zdalnym repozytorium (np. `o/main`).",
+              "",
+              "Skoro można to zrobić na oba sposoby, to dlaczego lekcje skupiały się do tej pory na przebazowaniu? Dlaczego `merge` nie jest lubianym poleceniem przy pracy na zdalnych repo?",
+              ""
+            ]
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "Wśród osób zajmujących się programowaniem toczą się spory, co jest lepsze: merge czy rebase. Oto ogólne za i przeciw rebase'owania:",
+              "",
+              "Za:",
+              "",
+              "* Przebazowanie sprawi, że twoje drzewo commitów będzie wyglądać bardzo czysto, ponieważ wszystko znajdzie się w jednej linii",
+              "",
+              "Przeciw:",
+              "",
+              "* Rebase zmienia (pozornie) historię drzewa commitów.",
+              "",
+              "Na przykład: commit `C1` można przebazować *za* `C3`. Pozornie będzie to wyglądać tak, jakby praca na `C1'` została wykonana później niż na `C3`, a w rzeczywistości było zupełnie odwrotnie.",
+              "",
+              "Część osób ceni sobie oryginalną historię i dlatego woli merdżować. Inni (w tym ja) wolą mieć czyste drzewo commitów i dlatego używają rebase. To po prostu kwestia osobistych preferencji :D"
+            ]
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "Na tym poziomie spróbujemy rozwiązać zadanie z poprzedniego, ale tym razem użyjemy *merge*. Może się to wydawać lekko pogmatwane, ale dobrze pokazuje tę metodę."
+            ]
+          }
+        }
+      ]
     }
   }
 };

src/levels/remote/pullArgs.js

@@ -17,7 +17,8 @@ exports.level = {
     "ko": "pull 인자들",
     "uk": "Аргументи pull",
     "vi": "Tham số pull",
-    "sl_SI": "Pull argumenti"
+    "sl_SI": "Pull argumenti",
+    "pl": "Argumenty pull"
   },
   "hint": {
     "en_US": "Remember that you can create new local branches with fetch/pull arguments",
@@ -34,7 +35,8 @@ exports.level = {
     "ko": "fetch/pull 과 인자들로 새 로컬 브랜치를 생성할수 있다는것을 기억하세요.",
     "uk": "Пам'ятай, що ти можеш створювати нові гілки, використовуючи fetch/pull з аргументами",
     "vi": "Nhớ rằng,bạn có thể tạo nhánh cục bộ mới với tham số của fetch/pull",
-    "sl_SI": "Zapomni si, da lahko ustvariš nove lokalne branche s fetch/pull argumenti."
+    "sl_SI": "Zapomni si, da lahko ustvariš nove lokalne branche s fetch/pull argumenti.",
+    "pl": "Pamiętaj, że za pomocą argumentów fetch/pull możesz tworzyć nowe lokalne gałęzie"
   },
   "startDialog": {
     "en_US": {
@@ -1155,6 +1157,80 @@ exports.level = {
           }
         }
       ]
+    },
+    "pl": {
+      "childViews": [
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "## Argumenty git pull",
+              "",
+              "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.",
+              "",
+              "I działa to w ten sposób, nawet jeśli określisz kompletnie szalone argumenty. Zobaczmy kilka przykładów:"
+            ]
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "Oto kilka równoważnych poleceń w Gicie:",
+              "",
+              "`git pull  origin foo` nie różni się od:",
+              "",
+              "`git fetch origin foo; git merge o/foo`",
+              "",
+              "A...",
+              "",
+              "`git pull  origin bar~1:bugFix` daje taki sam efekt jak:",
+              "",
+              "`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).",
+              "",
+              "Zobaczmy demo:"
+            ]
+          }
+        },
+        {
+          "type": "GitDemonstrationView",
+          "options": {
+            "beforeMarkdowns": [
+              "Jeśli określimy dla fetch miejsce, to wszystko potoczy się tak jak wcześniej, ale scalimy wszystko, co zostało pobrane przez fetch."
+            ],
+            "afterMarkdowns": [
+              "Zobacz! Określając `main`, pobraliśmy commity do `o/main` tak jak zawsze. Potem scaliliśmy `o/main` z aktualnie wybranym miejscem, którym *nie* jest lokalna gałąź `main`. Właśnie z tego powodu może mieć sens wykonanie git pull wiele razy (z tymi samymi argumentami) z różnych lokalizacji, aby zaktualizować wiele gałęzi."
+            ],
+            "command": "git pull origin main",
+            "beforeCommand": "git clone; go -b bar; git commit; git fakeTeamwork"
+          }
+        },
+        {
+          "type": "GitDemonstrationView",
+          "options": {
+            "beforeMarkdowns": [
+              "Czy w przypadku źródła i celu będzie tak samo? Jasne, że tak! Zobaczmy:"
+            ],
+            "afterMarkdowns": [
+              "No nieźle, jedno polecenie, a tyle się dzieje. Stworzyliśmy nową lokalną gałąź `foo`, pobraliśmy commity ze zdalnej gałęzi `main` do `foo`, a potem jeszcze scaliliśmy ją z aktualnie wybraną gałęzią `bar`. Grubo ponad osiem tysięcy!"
+            ],
+            "command": "git pull origin main:foo",
+            "beforeCommand": "git clone; git fakeTeamwork; go -b bar; git commit"
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "Oki, żeby ukończyć poziom, doprowadź drzewo do takiego stanu jak na wizualizacji. Musisz pobrać parę commitów, stworzyć kilka gałęzi i scalić je z innymi, ale nie powinno to wymagać zbyt wielu poleceń :P"
+            ]
+          }
+        }
+      ]
     }
   }
 };

src/levels/remote/pushArgs.js

@@ -21,7 +21,8 @@ exports.level = {
     "ko": "git push의 인자들",
     "uk": "Аргументи git push",
     "vi": "Tham số git push",
-    "sl_SI": "Git push argumenti"
+    "sl_SI": "Git push argumenti",
+    "pl": "Argumenty git push"
   },
   "hint": {
     "en_US": "You can always look at the last slide of the dialog with \"objective\"",
@@ -38,7 +39,8 @@ exports.level = {
     "ko": "대화창의 마지막 슬라이드를 \"objective\"로 다시 볼 수 있습니다.",
     "uk": "Завжди можна подивитися останній слайд діалогу за допомогою \"objective\"",
     "vi": "Bạn có thể sử dụng \"objective\" để đọc trang cuối của cửa sổ hộp thoại",
-    "sl_SI": "Vedno lahko pogledaš zadnji dialog z \"objective\"."
+    "sl_SI": "Vedno lahko pogledaš zadnji dialog z \"objective\".",
+    "pl": "Możesz wpisać \"objective\", żeby zobaczyć ostatni slajd z każdego poziomu"
   },
   "startDialog": {
     "en_US": {
@@ -1144,6 +1146,81 @@ exports.level = {
           }
         }
       ]
+    },
+    "en_US": {
+      "childViews": [
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "## Argumenty push",
+              "",
+              "Świetnie! Teraz, kiedy wiesz już, jak działa śledzenie zdalnych gałęzi, możemy zacząć zgłębiać tajemnice pracy z git push, fetch i pull. Zmierzymy się z tymi poleceniami po kolei, ale idea działania każdego z nich jest bardzo podobna.",
+              "",
+              "Najpierw spójrzmy na `git push`. Z lekcji o remote tracking wiesz, że Git określa zdalne repozytorium *oraz* gałąź docelową dzięki właściwościom aktualnie wybranej gałęzi (\"śledzącej\" zdalną). Tak to działa, jeśli nie określisz żadnych argumentów, ale git push może też przyjąć opcjonalnie następujące argumenty:",
+              "",
+              "`git push <remote> <place>`",
+              "",
+              ""
+            ]
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "Pytasz, czego dotyczy parametr `<place>`? Zaraz zajmiemy się tym konkretnie, ale najpierw przykład. Polecenie Gita:",
+              "",
+              "`git push origin main`",
+              "",
+              "to, mówiąc po ludzku:",
+              "",
+              "*Przejdź do gałęzi o nazwie \"main\" w moim repozytorium, weź wszystkie commity, a potem idź do gałęzi \"main\" na zdalnym repozytorium, które nazywa się \"origin\". Umieść na tej gałęzi wszystkie commity, których tam jeszcze nie ma, i daj znać, jak skończysz.*",
+              "",
+              "Wpisując `main` w miejscu argumentu \"place\" (miejsce), powiedzieliśmy Gitowi, *skąd ma wziąć* commity i *gdzie je umieścić*. To w zasadzie właśnie \"miejsce\", czyli \"lokalizacja\" do zsynchronizowania na obu repozytoriach.",
+              "",
+              "Pamiętaj, że skoro powiedzieliśmy Gitowi wszystko, co musi wiedzieć (podając oba argumenty), będzie kompletnie ignorować, jakie miejsce mamy aktualnie wybrane!"
+            ]
+          }
+        },
+        {
+          "type": "GitDemonstrationView",
+          "options": {
+            "beforeMarkdowns": [
+              "Spójrzmy na przykład określający argumenty. Zwróć uwagę na wybrany commit (checkout)."
+            ],
+            "afterMarkdowns": [
+              "No i proszę! Zaktualizowaliśmy `main` na zdalnym repozytorium, ponieważ określiliśmy argumenty."
+            ],
+            "command": "git checkout C0; git push origin main",
+            "beforeCommand": "git clone; git commit"
+          }
+        },
+        {
+          "type": "GitDemonstrationView",
+          "options": {
+            "beforeMarkdowns": [
+              "A gdybyśmy nie określili argumentów? Co by się stało?"
+            ],
+            "afterMarkdowns": [
+              "Polecenie (jak widzisz) nie działa, ponieważ `HEAD` nie jest wybrany na gałęzi śledzącej."
+            ],
+            "command": "git checkout C0; git push",
+            "beforeCommand": "git clone; git commit"
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "Oki, na tym poziomie uaktualnijmy zarówno `foo`, jak i `main` na zdalnym repozytorium. Haczyk polega na tym, że zablokowaliśmy na tym poziomie `git checkout`!",
+              "",
+              "*Uwaga: Zdalne gałęzie mają przedrostek `o/`, ponieważ pełna nazwa `origin/` nie mieści się w naszym interfejsie. Nie przejmuj się tym... ",
+              "po prostu użyj `origin` jako nazwy zdalnego repozytorium.*"
+            ]
+          }
+        }
+      ]
     }
   }
 };

src/levels/remote/pushArgs2.js

@@ -17,7 +17,8 @@ exports.level = {
     "ko": "git push 인자 -- 확장판!",
     "uk": "Розширені аргументи git push!",
     "vi": "Tham số git push -- bản mở rộng!",
-    "sl_SI": "Git push argumenti -- Razširjeni!"
+    "sl_SI": "Git push argumenti -- Razširjeni!",
+    "pl": "Argumenty git push -- Głębiej!"
   },
   "hint": {
     "en_US": "Remember you can admit defeat and type in \"show solution\" :P",
@@ -34,7 +35,8 @@ exports.level = {
     "ko": "혹시 아세요? 패배를 인정하고 \"show solution\"을 입력할 수 있다는 걸요 :P",
     "uk": "Пам'ятай, ти завжди можеш визнати поразку і підглянути рішення командою \"show solution\" :P",
     "vi": "Nhớ rằng, bạn có thể thừa nhận thất bại và gõ \"show solution\" :P",
-    "sl_SI": "Vedno se lahko predaš in napišeš \"show solution\". :P"
+    "sl_SI": "Vedno se lahko predaš in napišeš \"show solution\". :P",
+    "pl": "Pamiętaj, że możesz się poddać i zobaczyć gotowe rozwiązanie, wpisując \"show solution\" :P",
   },
   "startDialog": {
     "en_US": {
@@ -1096,6 +1098,76 @@ exports.level = {
           }
         }
       ]
+    },
+    "pl": {
+      "childViews": [
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "## Szczegóły argumentu `<place>`",
+              "",
+              "Przypomnij sobie, że na poprzedniej lekcji określając `main` jako argument miejsca dla polecenia git push, wybraliśmy zarówno *źródło*, z którego mają pochodzić commity, jak i *cel*, do którego mają trafić.",
+              "",
+              "No i może zastanawiasz się teraz-- co by było, gdybyśmy chcieli, żeby źródło i cel były różne od siebie? Co, gdybyśmy chcieli wypchać commity z lokalnej gałęzi `foo` do zdalnej gałęzi `bar`?",
+              "",
+              "Cóż... niestety w Gicie nie da się tego zrobić... Żart! Jasne, że się da :) Git jest bardzo, bardzo elastyczny (może aż za bardzo).",
+              "",
+              "Zobaczmy, jak bardzo, na następnym slajdzie..."
+            ]
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "Aby określić zarówno źródło, jak i cel dla `<place>`, po prostu połącz je dwukropkiem:",
+              "",
+              "`git push origin <source>:<destination>`",
+              "",
+              "To nic innego jak refspec z dwukropkiem. Refspec to tylko wymyślny termin oznaczający lokalizację, którą Git potrafi zidentyfikować (na przykład gałąź `foo` albo po prostu `HEAD~1`).",
+              "",
+              "Kiedy już zaczniesz określać niezależnie źródła i cele, to możesz trochę zaszaleć na zdalnych repozytoriach. Zobaczmy demo!"
+            ]
+          }
+        },
+        {
+          "type": "GitDemonstrationView",
+          "options": {
+            "beforeMarkdowns": [
+              "Pamiętaj, że `source` (źródło) to dowolna lokalizacja, którą Git zrozumie:"
+            ],
+            "afterMarkdowns": [
+              "Łaaał! Niezły odlot, ale jest w tym poleceniu jakiś sens -- Git zinterpretował `foo^` jako konkretną lokalizację, wrzucił tam wszystkie commity, jakich brakowało jeszcze w zdalnym repo, i na koniec zaktualizował cel."
+            ],
+            "command": "git push origin foo^:main",
+            "beforeCommand": "git clone; go -b foo; git commit; git commit"
+          }
+        },
+        {
+          "type": "GitDemonstrationView",
+          "options": {
+            "beforeMarkdowns": [
+              "A co, jeśli miejsce, do którego chcesz zrobić push, nie istnieje? Żaden problem! Wybierz tylko nazwę dla gałęzi, a Git stworzy ją dla ciebie w zdalnym repozytorium."
+            ],
+            "afterMarkdowns": [
+              "Pięknie! Całkiem sprytne! :D"
+            ],
+            "command": "git push origin main:newBranch",
+            "beforeCommand": "git clone; git commit"
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "Na tym poziomie postaraj się uzyskać drzewo, takie jak na wizualizacji, i pamiętaj o formacie:",
+              "",
+              "`<źródło>:<cel>`"
+            ]
+          }
+        }
+      ]
     }
   }
 };

src/levels/remote/pushManyFeatures.js

@@ -17,7 +17,8 @@ exports.level = {
     "ko": "명령어를 undo와 reset으로 되돌릴 수 있다는 것을 잊지마세요",
     "uk": "Пам'ятай, ти в будь-який момент можеш використовувати команди undo або reset",
     "vi": "Nhớ rằng bạn luôn luôn có thể hoàn tác hoặc soạn lại câu lệnh ",
-    "sl_SI": "Vedno lahko razveljaviš ukaz ali ponastaviš stopnjo."
+    "sl_SI": "Vedno lahko razveljaviš ukaz ali ponastaviš stopnjo.",
+    "pl": "Pamiętaj, że zawsze możesz skorzystać z poleceń undo i reset",
   },
   "name": {
     "en_US": "Push Main!",
@@ -34,7 +35,8 @@ exports.level = {
     "ko": "Push Main!",
     "uk": "Push Maйстер!",
     "vi": "Push Main!",
-    "sl_SI": "Push Main!"
+    "sl_SI": "Push Main!",
+    "pl": "Wypychanie dla wytrwałych!"
   },
   "compareOnlyMainHashAgnostic": true,
   "startDialog": {
@@ -832,6 +834,59 @@ exports.level = {
           }
         }
       ]
+    },
+    "pl": {
+      "childViews": [
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "## Scalanie gałęzi feature",
+              "",
+              "Teraz, kiedy fetch, pull ani push nie mają już przed tobą tajemnic, sprawdźmy, jak poradzisz sobie z inną kolejnością działań.",
+              "",
+              "W dużych projektach często pracuje się na gałęziach tematycznych (zazwyczaj nazywanych `feature`), a nie na `main`, i scala się je dopiero po ukończeniu pracy. To sytuacja zbliżona do tej z poprzedniej lekcji (gałęzie boczne wypychaliśmy do remote), ale tu dodamy jeszcze jeden krok.",
+              "",
+              "Niektórzy używają push i pull, tylko będąc na gałęzi `main` - dzięki temu `main` zawsze odzwierciedla to, co jest na zdalnej gałęzi (`o/main`).",
+              "",
+              "Dlatego tym razem połączymy dwie rzeczy:",
+              "",
+              "* integrację pracy na gałęzi `feature` z `main` oraz",
+              "* push i pull ze zdalnego repozytorium"
+            ]
+          }
+        },
+        {
+          "type": "GitDemonstrationView",
+          "options": {
+            "beforeMarkdowns": [
+              "Przypomnijmy sobie w skrócie, jak uaktualnić `main` i wypchnąć naszą pracę."
+            ],
+            "afterMarkdowns": [
+              "Wykonaliśmy dwa polecenia, które:",
+              "",
+              "* przebazowały naszą pracę ponad nowymi commitami ze zdalnego repozytorium oraz",
+              "* opublikowały naszą pracę na remote"
+            ],
+            "command": "git pull --rebase; git push",
+            "beforeCommand": "git clone; git commit; git fakeTeamwork"
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "Ten poziom jest dość ciężki: oto ogólny zarys problemu do rozwiązania:",
+              "",
+              "* Mamy trzy boczne gałęzie: `side1` `side2` i `side3`",
+              "* Każdą z nich chcemy kolejno wypchnąć do zdalnego repozytorium",
+              "* Zdalne repo było w tym czasie zmieniane, więc te zmiany również musimy nanieść",
+              "",
+              ":O Ciężka sprawa... Powodzenia! Ukończenie tego poziomu to duży krok naprzód."
+            ]
+          }
+        }
+      ]
     }
   }
 };

src/levels/remote/sourceNothing.js

@@ -23,7 +23,8 @@ exports.level = {
     "ko": "Source가 없다",
     "uk": "Нема джерела",
     "vi": "Không có nguồn",
-    "sl_SI": "Izvor Ničesar"
+    "sl_SI": "Izvor Ničesar",
+    "pl": "Źródło nicości"
   },
   "hint": {
     "en_US": "The branch command is disabled for this level so you'll have to use fetch!",
@@ -40,7 +41,8 @@ exports.level = {
     "ko": "branch 명령이 비활성화 되어있습니다. fetch를 사용해야 되요!",
     "uk": "Команда branch недоступна на цьому уроці, користуйся командою fetch!",
     "vi": "Lệnh branch đã bị vô hiệu hóa ở cấp độ này nên bạn sẽ phải dùng fetch!",
-    "sl_SI": "Ukaz za branchanje je v tej stopnji onemogočen, zato boš moral uporabiti fetch!"
+    "sl_SI": "Ukaz za branchanje je v tej stopnji onemogočen, zato boš moral uporabiti fetch!",
+    "pl": "Polecenie branch jest zablokowane na tym poziomie, musisz skorzystać z fetch!"
   },
   "startDialog": {
     "en_US": {
@@ -841,6 +843,59 @@ exports.level = {
           }
         }
       ]
+    },
+    "pl": {
+      "childViews": [
+        {
+          "type": "ModalAlert",
+          "options": {
+            "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 push origin :side`",
+              "* `git fetch origin :bugFix`",
+              "",
+              "Zobaczmy, co z tego wyniknie..."
+            ]
+          }
+        },
+        {
+          "type": "GitDemonstrationView",
+          "options": {
+            "beforeMarkdowns": [
+              "Co daje wypchnięcie \"nicości\" na zdalną gałąź? Usuwa ją!"
+            ],
+            "afterMarkdowns": [
+              "Oto właśnie usunęliśmy skutecznie gałąź `foo` na zdalnym repozytorium, wypychając do niej ideę \"nicości\". To nawet ma jakiś sens..."
+            ],
+            "command": "git push origin :foo",
+            "beforeCommand": "git clone; git push origin main:foo"
+          }
+        },
+        {
+          "type": "GitDemonstrationView",
+          "options": {
+            "beforeMarkdowns": [
+              "Natomiast ściągnięcie \"nicości\" za pomocą fetch do lokalnego miejsca tworzy nową gałąź."
+            ],
+            "afterMarkdowns": [
+              "Osobliwe i dziwaczne, ale nic nie poradzisz... Git tak ma!"
+            ],
+            "command": "git fetch origin :bar",
+            "beforeCommand": "git clone"
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "To jest krótki poziom -- żeby go ukończyć, po prostu usuń jedną zdalną gałąź i stwórz jedną nową, używając `git fetch`!"
+            ]
+          }
+        }
+      ]
     }
   }
 };

src/levels/remote/tracking.js

@@ -17,7 +17,8 @@ exports.level = {
     "ko": "원격 저장소 추적하기",
     "uk": "Слідкуємо за віддаленим репозиторієм",
     "vi": "Theo dõi từ xa",
-    "sl_SI": "Sledenje Oddaljenega Repota"
+    "sl_SI": "Sledenje Oddaljenega Repota",
+    "pl": "Śledzenie zdalnych repo"
   },
   "hint": {
     "en_US": "Remember there are two ways to set remote tracking!",
@@ -34,7 +35,8 @@ exports.level = {
     "ko": "원격 추적하기를 설정하는데에는 두가지 방법이 있습니다!",
     "uk": "Пам'ятай, є два способи слідкувати за віддаленим репозиорієм!",
     "vi": "Hãy nhớ rằng, có 2 cách để thiết lập theo dõi từ xa!",
-    "sl_SI": "Spomni se, da obstajata dva načina za sledenje oddaljenega repota."
+    "sl_SI": "Spomni se, da obstajata dva načina za sledenje oddaljenega repota.",
+    "pl": "Pamiętaj, zdalne repo można śledzić na dwa sposoby!"
   },
   "startDialog": {
     "en_US": {
@@ -1927,6 +1929,124 @@ exports.level = {
           }
         }
       ]
+    },
+    "pl": {
+      "childViews": [
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "### Gałęzie śledzące",
+              "",
+              "Może ci się wydawać od kilku lekcji, że Git jakoś \"magicznie\" wie, że gałąź `main` jest powiązana z `o/main`. Co prawda nazwy tych gałęzi są podobne i, logicznie rzecz biorąc, `main` na zdalnym repo można skojarzyć z lokalną gałęzią `main`, ale na dwóch przykładach pokażemy, jak to działa w rzeczywistości:",
+              "",
+              "* Podczas operacji pull, commity są pobierane do `o/main`, a następnie za pomocą *merge* scalane z gałęzią `main`. Na podstawie tego połączenia określa się pośrednio cel scalania.",
+              "* Podczas operacji push praca z gałęzi `main` jest wypychana do zdalnej gałęzi `main` (lokalnie reprezentowanej przez `o/main`). *Cel* polecenia push jest określony przez połączenie pomiędzy `main` a `o/main`.",
+              ""
+            ]
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "## Remote tracking",
+              "",
+              "Żeby nie przedłużać: połączenie pomiędzy `main` i `o/main` da się wyjaśnić po prostu jedną z właściwości gałęzi: \"remote tracking\". Gałąź `main` ma ustawione śledzenie gałęzi `o/main` -- a to oznacza, że dla operacji merge i push określony jest domyślny cel.",
+              "",
+              "Może się zastanawiasz, jak to się stało, że `main` ma już ustawione śledzenie, skoro nie robiliśmy tego żadnym poleceniem. Otóż, kiedy klonujesz repozytorium w Gicie, ta właściwość jest ustawiana za ciebie automatycznie. ",
+              "",
+              "Przy klonowaniu Git tworzy zdalną gałąź dla każdej z gałęzi zdalnego repozytorium (czyli gałęzie takie jak `o/main`). Następnie tworzy lokalną gałąź, która śledzi aktualnie aktywną gałąź na zdalnym repo - czyli najczęściej `main`.",
+              "",
+              "Po zakończeniu klonowania lokalnie masz tylko jedną gałąź (żeby nie zawracać sobie niepotrzebnie głowy), ale możesz zobaczyć wszystkie gałęzie na zdalnym repozytorium (jeśli aż tak cię to ciekawi). To idealne dwa w jednym!",
+              "",
+              "A przy okazji to wyjaśnia, dlaczego przy klonowaniu możesz zobaczyć:",
+              "",
+              "    local branch \"main\" set to track remote branch \"o/main\""
+            ]
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "### A czy mogę to określić samodzielnie?",
+              "",
+              "Jasne, że tak! Możesz kazać dowolnej gałęzi śledzić `o/main`, i w takim wypadku będzie miała taki sam domyślny cel operacji push i merge, co `main`. To znaczy, że możesz zrobić `git push` na gałęzi o nazwie `totallyNotMain`, a twoja praca i tak zostanie wypchnięta do gałęzi `main` w zdalnym repozytorium!",
+              "",
+              "Są dwa sposoby ustawienia tej właściwości. Pierwszym jest checkout nowej gałęzi wykorzystujący zdalną gałąź jako określoną referencję. Polecenie",
+              "",
+              "`git checkout -b totallyNotMain o/main`",
+              "",
+              "tworzy nową gałąź o nazwie `totallyNotMain` i każe jej śledzić `o/main`."
+            ]
+          }
+        },
+        {
+          "type": "GitDemonstrationView",
+          "options": {
+            "beforeMarkdowns": [
+              "Dość gadania, pora zobaczyć, jak to działa! Będziemy checkoutować nową gałąź o nazwie `foo` i każemy jej śledzić `main` na zdalnym repozytorium."
+            ],
+            "afterMarkdowns": [
+              "Jak widzisz, użyliśmy domyślnego celu scalania `o/main`, żeby zaktualizować gałąź `foo`. Zwróć uwagę, że `main` się nie aktualizuje!!!"
+            ],
+            "command": "git checkout -b foo o/main; git pull",
+            "beforeCommand": "git clone; git fakeTeamwork"
+          }
+        },
+        {
+          "type": "GitDemonstrationView",
+          "options": {
+            "beforeMarkdowns": [
+              "Dotyczy to również git push."
+            ],
+            "afterMarkdowns": [
+              "Tadam! Wypchnęliśmy naszą pracę do `main` na `remote`, mimo że nasza gałąź nazywała się zupełnie inaczej."
+            ],
+            "command": "git checkout -b foo o/main; git commit; git push",
+            "beforeCommand": "git clone"
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "### Sposób #2",
+              "",
+              "Inny sposób na ustawienie remote tracking na branchu to po prostu użycie opcji `git branch -u`. Polecenie",
+              "",
+              "`git branch -u o/main foo`",
+              "",
+              "spowoduje, że gałąź `foo` będzie śledzić `o/main`. Jeśli aktualnie wybraną gałęzią jest `foo`, to możesz nawet pominąć jej nazwę:",
+              "",
+              "`git branch -u o/main`",
+              ""
+            ]
+          }
+        },
+        {
+          "type": "GitDemonstrationView",
+          "options": {
+            "beforeMarkdowns": [
+              "Spójrzmy jeszcze szybko, jak to wygląda w praktyce..."
+            ],
+            "afterMarkdowns": [
+              "Tak samo jak poprzednio, tylko wyraźniej widać to w poleceniu. Pięknie!"
+            ],
+            "command": "git branch -u o/main foo; git commit; git push",
+            "beforeCommand": "git clone; git checkout -b foo"
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "Oki! Na tym poziomie wypchnijmy (push) pracę do gałęzi `main`na zdalnym repozytorium, *nie* checkoutując `main` lokalnie. Wymyśl samodzielnie, jak to zrobić. To przecież zaawansowana część kursu :P"
+            ]
+          }
+        }
+      ]
     }
   }
 };