diff --git a/src/levels/advanced/multipleParents.js b/src/levels/advanced/multipleParents.js index fa1b7426..bede4471 100644 --- a/src/levels/advanced/multipleParents.js +++ b/src/levels/advanced/multipleParents.js @@ -909,7 +909,7 @@ exports.level = { "", "Так само як модифікатор `~`, модифікатор `^` також приймає необов’язкове число після нього.", "", - "Замість того щоб вказувати кількість генерацій щоб переміститись назад (те що робить `~`), число після `^` вказує на яке батьківське посилання мерджу потрібно перейти. Зауважте що так як мерджевий коміт має декілька батьків, використання '^' без числа є неоднозначним.", + "Замість того, щоб вказувати кількість генерацій щоб переміститись назад (те що робить `~`), число після `^` вказує на яке батьківське посилання мерджу потрібно перейти. Зауважте що так як мерджевий коміт має декілька батьків, використання '^' без числа є неоднозначним.", "", "Git зазвичай перейде на \"першого\" з батьків вверх з мерджевого коміту, але вказання числа після `^` змінює цю поведінку. ", "", @@ -924,7 +924,7 @@ exports.level = { "beforeMarkdowns": [ "Ось ми маємо мерджевий коміт. Якщо зробимо checkout `master^` без числа, ми потрапимо на першого з предків ", "", - "(*В нашій візуалізації, перший предок знаходиться прямо над мержевим комітом*)" + "(*В нашій візуалізації перший предок знаходиться прямо над мерджевим комітом*)" ], "afterMarkdowns": [ "Легко -- те до чого ми всі звикли." @@ -953,7 +953,7 @@ exports.level = { "Модифікатори `^` та `~` дозволяють легко переміщатись по дереву комітів:" ], "afterMarkdowns": [ - "Суперово швидко!" + "Супер швидко!" ], "command": "git checkout HEAD~; git checkout HEAD^2; git checkout HEAD~2", "beforeCommand": "git commit; git checkout C0; git commit; git commit; git commit; git checkout master; git merge C5; git commit" @@ -966,7 +966,7 @@ exports.level = { "Більше того, ці модифікатори можна використовувати разом! Заціни:" ], "afterMarkdowns": [ - "Теж саме, що й перед цим, але одною командою." + "Те саме, що й перед цим, але одною командою." ], "command": "git checkout HEAD~^2~2", "beforeCommand": "git commit; git checkout C0; git commit; git commit; git commit; git checkout master; git merge C5; git commit" @@ -980,7 +980,7 @@ exports.level = { "", "Щоб завершити цей рівень, створи нову гілку на вказаному місці.", "", - "Очевидно що в данному випадку досить легко вказати коміт напряму (щось на зразок checkout `C6`), але для закріплення матеріалу, використай модифікатори про які ми щойно говорили!" + "Очевидно, що в данному випадку досить легко вказати коміт напряму (щось на зразок checkout `C6`), але для закріплення матеріалу, використай модифікатори про які ми щойно говорили!" ] } } diff --git a/src/levels/index.js b/src/levels/index.js index afd4128a..b8fac579 100644 --- a/src/levels/index.js +++ b/src/levels/index.js @@ -221,7 +221,7 @@ var sequenceInfo = exports.sequenceInfo = { 'zh_CN': 'Git 技术、技巧与贴士杂烩', 'zh_TW': 'git 的技術，招數與技巧', 'ru_RU': 'Ассорти из приёмов работы с Git, хитростей и советов', - 'uk' : 'Різні прийоми роботи з Git, хитрості та поради' + 'uk' : 'Різні прийоми роботи з Git, хитрощі та поради' } }, advanced: { diff --git a/src/levels/intro/commits.js b/src/levels/intro/commits.js index 409e5642..46cd7b4d 100644 --- a/src/levels/intro/commits.js +++ b/src/levels/intro/commits.js @@ -475,7 +475,7 @@ exports.level = { "", "Git намагається зберігати коміти якнайпростіше й ефективніше, тому він не просто копіює всю директорію при кожному коміті. Він може стиснути коміт в набір правок чи \"дельту\" між двома версіями репозиторію.", "", - "Git також зберігає історію коли і ким був створений той чи інший коміт. Тому більшість комітів мають комітів-предків, що знаходяться вище в ієрархії \u2014 ми це зоображуємо стрілочками в нашій візуалізації. Історія \u2014 це необхідна річ для кожного, хто працює з конкретним проектом.", + "Git також зберігає історію коли і ким був створений той чи інший коміт. Тому більшість комітів мають комітів-предків, що знаходяться вище в ієрархії \u2014 ми це зображуємо стрілочками в нашій візуалізації. Історія \u2014 це необхідна річ для кожного, хто працює з конкретним проектом.", "", "Тут є багато над чим подумати, але наразі ти можеш уявляти коміти як моментальні знімки проекту. Коміти майже невагомі й перемикання між ними дуже швидке." ] @@ -485,7 +485,7 @@ exports.level = { "type": "GitDemonstrationView", "options": { "beforeMarkdowns": [ - "Давай подивимось, як це виглядає на практиці. Справа зоображена візуалізація маленького Git-репозиторію. Наразі ми бачимо два коміти: початковий коміт `C0`, та наступний коміт `C1`, який містить якісь змістовні зміни.", + "Давай подивимось, як це виглядає на практиці. Справа зображена візуалізація маленького Git-репозиторію. Наразі ми бачимо два коміти: початковий коміт `C0`, та наступний коміт `C1`, який містить якісь змістовні зміни.", "", "Натисни кнопку нижче, щоб створити новий коміт." ], diff --git a/src/levels/intro/merging.js b/src/levels/intro/merging.js index 450fb4c5..ee747fe9 100644 --- a/src/levels/intro/merging.js +++ b/src/levels/intro/merging.js @@ -729,9 +729,9 @@ exports.level = { "markdowns": [ "## Гілки та їх Злиття", "", - "Чудово! Ми знаємо як комітити та створювати гілки. Тепер потрібно навчитися в якийсь спосіб поєднувати інфу з двох чи більше гілок. Це дозволить нам відгілкуватись, зробити нову фічу, й потім інтегрувати її взад.", + "Чудово! Ми знаємо як комітити та створювати гілки. Тепер потрібно навчитися в якийсь спосіб поєднувати інфу з двох чи більше гілок. Це дозволить нам відгілкуватись, зробити нову фічу, й потім інтегрувати її назад.", "", - "Перший спосіб об’єднувати робочу інфу з яким ми розберемось це `git merge`. Команда merge (злити) в Git створює спеціяльний коміт який має двох унікальних батьків. Здорова сім’я прям. Коміт з двома батьками в приниципі просто значить що в нього включена інфа з обох батьків і всіх їх попередників.", + "Перший спосіб об’єднувати робочу інфу з яким ми розберемось це `git merge`. Команда merge (злити) в Git створює спеціальний коміт який має двох унікальних батьків. Коміт з двома батьками в приниципі просто значить що в нього включена інфа з обох батьків і всіх їх попередників.", "", "Це простіше сприймається візуально, тому розберемо це в наступному слайді" ] @@ -741,12 +741,12 @@ exports.level = { "type": "GitDemonstrationView", "options": { "beforeMarkdowns": [ - "Тут ми маємо дві гілки; кожна з них містить унікальний коміт. Це означає що жодна з них не містить повного набору \"робочої інфи\" в цьому репозиторії. Давайте зіллємо всю інфу до купи за допомогою merge.", + "Тут ми маємо дві гілки; кожна з них містить унікальний коміт. Це означає що жодна з них не містить повного набору \"робочої інфи\" в цьому репозиторії. Давайте зіллємо всю інфу докупи за допомогою merge.", "", "Ми `змержимо` гілку `bugFix` в `master`" ], "afterMarkdowns": [ - "Нічосі! Ви то виділи? По-перше, `master` тепер вказує на коміт з двома батьками. Якщо ти піднімешся вверх з цього коміту по дереву, починаючи з `master`, на шляху ти зустрінеш кожен коміт аж до кореневого. Це означає що гілка `master` тепер містить всю інфу в цьому репозиторії.", + "Нічого собі! Ви це бачили? По-перше, `master` тепер вказує на коміт з двома батьками. Якщо ти піднімешся вверх з цього коміту по дереву, починаючи з `master`, на шляху ти зустрінеш кожен коміт аж до кореневого. Це означає що гілка `master` тепер містить всю інфу в цьому репозиторії.", "", "А ти помітив як змінилися кольори комітів? Для кращого розуміння процесу я додав певну кольорову диференціацію. Кожен бранч виділено окремим кольором. Колір кожного коміту це суміш кольорів всіх гілок що місять цей коміт.", "", @@ -763,7 +763,7 @@ exports.level = { "Давай змержимо `master` в `bugFix`:" ], "afterMarkdowns": [ - "Так як `bugFix` є нащадком `master`, git'у непотрібно нічого робити; він просто пересунув `bugFix` на тей самий коміт, на якому знаходиться `master`.", + "Так як `bugFix` є нащадком `master`, git'у не потрібно нічого робити; він просто пересунув `bugFix` на тей самий коміт, на якому знаходиться `master`.", "", "Тепер всі коміти одного кольору, що означає що кожен бранч включає в собі всю корисну інфу яка є в цьому репозиторії! Ура!" ], diff --git a/src/levels/intro/rebasing.js b/src/levels/intro/rebasing.js index fbadbf5a..b4269880 100644 --- a/src/levels/intro/rebasing.js +++ b/src/levels/intro/rebasing.js @@ -721,12 +721,12 @@ exports.level = { "beforeMarkdowns": [ "Ми знову маємо дві гілки; зауваж, що наразі вибрана гілка bugFix (вважай зірочку)", "", - "Ми хочемо перемістити наші зміни з гілки bugFix прямо до змін з гілки master. Тоді це буде виглядати наче ці зміни були додані одна за одною, коли насправді вони були додані одночасно.", + "Ми хочемо перемістити наші зміни з гілки bugFix прямо до змін з гілки master. Тоді це буде виглядати наче ці зміни були додані одна за одною, хоча насправді вони були додані одночасно.", "", "Давайте зробимо це за допомогою команди `git rebase`" ], "afterMarkdowns": [ - "Файно! Тепер зміни з гілки bugFix знаходяться прямо попереду змін з master й ми отримали зручну лінійну послідовність комітів.", + "Добре! Тепер зміни з гілки bugFix знаходяться прямо попереду змін з master й ми отримали зручну лінійну послідовність комітів.", "", "Вважай що коміт C3 досі десь існує (в дереві він тьмяніший за решту), й C3' це \"копія\" яку ми заребейсили в master.", "", diff --git a/src/levels/mixed/describe.js b/src/levels/mixed/describe.js index acd1acd4..656b31f1 100644 --- a/src/levels/mixed/describe.js +++ b/src/levels/mixed/describe.js @@ -669,7 +669,7 @@ "", "Через те що таги є такими чудовими \"орієнтирами\" по коду, git також має команду *описати* (describe) де ти є відносно найближчого \"орієнтира\" (тобто тага). Й ця команда називається `git describe`!", "", - "Git describe допоможе тобі знайти себе після того як ти перепригнеш на кілька комітів по історії вперед чи назад; це може статися після того як ти закінчив git bisect (пошук-дебаггер) чи коли тебе попросили підійти до колеги котрий щойно прийшов з відпустки." + "Git describe допоможе тобі знайти себе після того як ти перестрибнеш на кілька комітів по історії вперед чи назад; це може статися після того як ти закінчив git bisect (пошук-дебаггер) чи коли тебе попросили підійти до колеги, котрий щойно прийшов з відпустки." ] } }, diff --git a/src/levels/mixed/grabbingOneCommit.js b/src/levels/mixed/grabbingOneCommit.js index 71aaa4e1..0c7defa9 100644 --- a/src/levels/mixed/grabbingOneCommit.js +++ b/src/levels/mixed/grabbingOneCommit.js @@ -442,9 +442,9 @@ exports.level = { "", "Ось ситуація з життя рядового програміста: я намагаюся відслідкувати баг але це не завжди вдається. Щоб допомогти собі, я додаю кілька дебаг команд та ще кілька println'ів.", "", - "Всі ці команди для відладки та виводу данних знаходяться в своїх власних комітах. Врешті-решт я знаходжу баг, фікшу її та щиро радію!", + "Всі ці команди для відлагодження та виводу данних знаходяться в своїх власних комітах. Врешті-решт я знаходжу баг, фікшу його та щиро радію!", "", - "От тіки лишається проблема що потрібно мій фікс перенести з `bugFix` назад в гілку `master`. Якщо я просто зроблю фастфорвард (fast-forwarded) в `master`, тоді в `master` попадуть всі мої println'и що є зайвим. Має бути інший шлях..." + "От тільки лишається проблема що потрібно мій фікс перенести з `bugFix` назад в гілку `master`. Якщо я просто зроблю фастфорвард (fast-forwarded) в `master`, тоді в `master` попадуть всі мої println'и, що є зайвим. Має бути інший шлях..." ] } }, diff --git a/src/levels/mixed/jugglingCommits.js b/src/levels/mixed/jugglingCommits.js index 50dd4180..7a589beb 100644 --- a/src/levels/mixed/jugglingCommits.js +++ b/src/levels/mixed/jugglingCommits.js @@ -393,9 +393,9 @@ exports.level = { "markdowns": [ "## Жонглюємо комітами", "", - "Ось інакша ситуація що доволі часто трапляється. В тебе є якісь зміни (`newImage`) та ще якийсь набір комітів (`caption`) що є зв’язані між собою, тому вони знаходяться один над одним в твоєму репозиториї (або один за одним).", + "Ось інша ситуація, що доволі часто трапляється. В тебе є якісь зміни (`newImage`) та ще якийсь набір комітів (`caption`), які зв’язані між собою, тому вони знаходяться один над одним в твоєму репозиторії (або один за одним).", "", - "Штука в тому що іноді потрібно зробити невелику модифікацію до попереднього коміту. В цьому випадку, дизайнери хочуть щоб ми трохи змінили розміри `newImage`, не дивлячись на те що цей коміт знаходиться досить глибоко в історії!!" + "Штука в тому що іноді потрібно зробити невелику модифікацію до попереднього коміту. В цьому випадку, дизайнери хочуть щоб ми трохи змінили розміри `newImage`, не зважаючи на те, що цей коміт знаходиться досить глибоко в історії!!" ] } }, @@ -405,15 +405,15 @@ exports.level = { "markdowns": [ "Ми поборимо цю складність наступним чином:", "", - "* Ми відсортуємо коміти таким чином, щоб той який ми хочемо змінити був останнім за допомогою `git rebase -i`", + "* Ми відсортуємо коміти таким чином, щоб той, який ми хочемо змінити, був останнім за допомогою `git rebase -i`", "* Ми виконаємо `commit --amend` щоб внести невелику правку до останнього коміту", "* Тоді ми відсортуємо коміти в попередньому порядку, за допомогою `git rebase -i`", "* І на останок, ми пересунемо master на змінену частину дерева щоб закінчити цей рівень(ти можеш вибрати метод)", "", - "Насправді є кілька способів як виконати поставлену задачу (Я бачу ти поглядаєш на cherry-pick), й ми розберемося з ними всіма трохи пізніше, але зараз, давай, скористаємося цим методом.", + "Насправді є кілька способів як виконати поставлену задачу (Я бачу ти поглядаєш на cherry-pick), і ми розберемося з ними всіма трохи пізніше, але зараз, давай, скористаємося цим методом.", "Зверни увагу на фінальний стан в цьому рівні -- так як ми перемістили коміти двічі, кожен з них отримає по апострофу. Ще один апостроф додастся коли ми виконаємо commit --amend.", "", - "Враховуючи вищесказане, я буду порівнювати дерево як по назві коміта так і за кількістю апострофів. Як тільки дерево цілей та master співпадуть, ти пройдеш цей рівень." + "Враховуючи сказане вище, я буду порівнювати дерево як по назві коміта так і за кількістю апострофів. Як тільки дерево цілей та master співпадуть, ти пройдеш цей рівень." ] } } diff --git a/src/levels/mixed/jugglingCommits2.js b/src/levels/mixed/jugglingCommits2.js index 24a1f630..7d7cc725 100644 --- a/src/levels/mixed/jugglingCommits2.js +++ b/src/levels/mixed/jugglingCommits2.js @@ -1,512 +1,512 @@ -exports.level = { - "goalTreeString": "%7B%22branches%22%3A%7B%22master%22%3A%7B%22target%22%3A%22C3%27%22%2C%22id%22%3A%22master%22%7D%2C%22newImage%22%3A%7B%22target%22%3A%22C2%22%2C%22id%22%3A%22newImage%22%7D%2C%22caption%22%3A%7B%22target%22%3A%22C3%22%2C%22id%22%3A%22caption%22%7D%7D%2C%22commits%22%3A%7B%22C0%22%3A%7B%22parents%22%3A%5B%5D%2C%22id%22%3A%22C0%22%2C%22rootCommit%22%3Atrue%7D%2C%22C1%22%3A%7B%22parents%22%3A%5B%22C0%22%5D%2C%22id%22%3A%22C1%22%7D%2C%22C2%22%3A%7B%22parents%22%3A%5B%22C1%22%5D%2C%22id%22%3A%22C2%22%7D%2C%22C3%22%3A%7B%22parents%22%3A%5B%22C2%22%5D%2C%22id%22%3A%22C3%22%7D%2C%22C2%27%22%3A%7B%22parents%22%3A%5B%22C1%22%5D%2C%22id%22%3A%22C2%27%22%7D%2C%22C2%27%27%22%3A%7B%22parents%22%3A%5B%22C1%22%5D%2C%22id%22%3A%22C2%27%27%22%7D%2C%22C3%27%22%3A%7B%22parents%22%3A%5B%22C2%27%27%22%5D%2C%22id%22%3A%22C3%27%22%7D%7D%2C%22HEAD%22%3A%7B%22target%22%3A%22master%22%2C%22id%22%3A%22HEAD%22%7D%7D", - "solutionCommand": "git checkout master;git cherry-pick C2;git commit --amend;git cherry-pick C3", - "disabledMap": { - "git revert": true - }, - "startTree": "{\"branches\":{\"master\":{\"target\":\"C1\",\"id\":\"master\"},\"newImage\":{\"target\":\"C2\",\"id\":\"newImage\"},\"caption\":{\"target\":\"C3\",\"id\":\"caption\"}},\"commits\":{\"C0\":{\"parents\":[],\"id\":\"C0\",\"rootCommit\":true},\"C1\":{\"parents\":[\"C0\"],\"id\":\"C1\"},\"C2\":{\"parents\":[\"C1\"],\"id\":\"C2\"},\"C3\":{\"parents\":[\"C2\"],\"id\":\"C3\"}},\"HEAD\":{\"target\":\"caption\",\"id\":\"HEAD\"}}", - "compareOnlyMasterHashAgnosticWithAsserts": true, - "goalAsserts": { - "master": [ - function(data) { - return data.C2 > data.C3; - }, - function(data) { - return data.C2 > data.C1; - } - ] - }, - "name": { - "ko": "커밋 갖고 놀기 #2", - "en_US": "Juggling Commits #2", - "fr_FR": "Jongler avec les commits #2", - "es_AR": "Haciendo malabares con los commits #2", - "pt_BR": "Malabarismo com commits #2", - "de_DE": "Jonglieren mit Commits Teil 2", - "ja": "コミットをやりくりする その2", - "zh_CN": "提交交换戏法 #2", - "zh_TW": "commit 的戲法 #2", - "ru_RU": "Жонглируем коммитами №2", - "uk": "Жонглюємо комітами #2" - }, - "hint": { - "en_US": "Don't forget to forward master to the updated changes!", - "fr_FR": "N'oubliez pas de forwarder la branch master dans la nouvelle branch", - "es_AR": "¡No te olvides de avanzar master a los cambios actualizados!", - "pt_BR": "Não se esqueça de avançar a referência do master para as mudanças efetuadas!", - "de_DE": "Vergiss nicht den master auf die aktuelle Version vorzuspulen", - "ja": "masterのポインタを先に進めることを忘れずに！", - "ko": "master를 변경 완료한 커밋으로 이동(forward)시키는 것을 잊지 마세요!", - "zh_CN": "别忘记了将 master 快进到最新的更新上！", - "zh_TW": "別忘記了將 master 推到最新的 commit 上面！", - "ru_RU": "Не забудь переместить master на последние изменения.", - "uk": "Не забудь перемістити master на останні зміни!" - }, - "startDialog": { - "en_US": { - "childViews": [ - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "## Juggling Commits #2", - "", - "*If you haven't completed Juggling Commits #1 (the previous level), please do so before continuing*", - "", - "As you saw in the last level, we used `rebase -i` to reorder the commits. Once the commit we wanted to change was on top, we could easily --amend it and re-order back to our preferred order.", - "", - "The only issue here is that there is a lot of reordering going on, which can introduce rebase conflicts. Let's look at another method with `git cherry-pick`" - ] - } - }, - { - "type": "GitDemonstrationView", - "options": { - "beforeMarkdowns": [ - "Remember that git cherry-pick will plop down a commit from anywhere in the tree onto HEAD (as long as that commit isn't an ancestor of HEAD).", - "", - "Here's a small refresher demo:" - ], - "afterMarkdowns": [ - "Nice! Let's move on" - ], - "command": "git cherry-pick C2", - "beforeCommand": "git checkout -b bugFix; git commit; git checkout master; git commit" - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "So in this level, let's accomplish the same objective of amending `C2` once but avoid using `rebase -i`. I'll leave it up to you to figure it out! :D", - "", - "Remember, the exact number of apostrophe's (') on the commit are not important, only the relative differences. For example, I will give credit to a tree that matches the goal tree but has one extra apostrophe everywhere" - ] - } - } - ] - }, - "fr_FR": { - "childViews": [ - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "## Jongler avec les commits #2", - "", - "*Si vous n'avez pas fait le défi Jongler avec les commits #1 (le niveau précédent), vous devriez le faire avant de continuer*", - "", - "Comme vu dans le niveau précédent, nous utilisons `rebase -i` pour réordonner les commits. Une fois que le commit à modifier est celui à la tête, nous pouvons facilement faire un --amend et réordonner dans l'ordre voulu.", - "", - "La difficulté ici est qu'il y a beaucoup de changements, ce qui peut introduire des conflits de rebase. Essayons avec l'autre méthode `git cherry-pick`" - ] - } - }, - { - "type": "GitDemonstrationView", - "options": { - "beforeMarkdowns": [ - "N'oubliez pas que git cherry-pick va prendre un commit de n'importe où dans l'arbre de git et le mettre devant HEAD (sauf s'il est un ancêtre de HEAD).", - "", - "Un petit rappel :" - ], - "afterMarkdowns": [ - "Bien ! continuons." - ], - "command": "git cherry-pick C2", - "beforeCommand": "git checkout -b bugFix; git commit; git checkout master; git commit" - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "Dans ce niveau, nous voulons modifier `C2` sans utiliser `rebase -i`. À vous maintenant de trouver comment ! :D", - "", - "Petit rappel, le nombre exact d'apostrophes (') sur le commit n'est pas important. Par exemple, nous donnerons les points à une structure qui colle au résultat mais qui a une apostrophe en trop partout." - ] - } - } - ] - }, - "es_AR": { - "childViews": [ - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "## Haciendo malabares con los commits #2", - "", - "*Si no completaste Haciendo malabares con los commits #1 (el nivel anterior), hacelo antes de continuar*", - "", - "Como viste en el último nivel, usamos `rebase -i` para reordenar los commits. Una vez que el commit que queríamos cambiar estaba arriba de todo, pudimos `--amend`earlo fácilmente y reordenarlo a como queríamos.", - "", - "El único problema con esto es que hay mucho reordenamiento, que puede generar conflictos al rebasear. Veamos otro método usando `git cherry-pick`" - ] - } - }, - { - "type": "GitDemonstrationView", - "options": { - "beforeMarkdowns": [ - "Acordate de que git cherry-pick va a traer un commit de cualquier parte del árbol sobre HEAD (siempre que ese otro commit no sea un ancestro de HEAD).", - "", - "Una pequeña demo para refrescar la idea:" - ], - "afterMarkdowns": [ - "¡Bien! Sigamos..." - ], - "command": "git cherry-pick C2", - "beforeCommand": "git checkout -b bugFix; git commit; git checkout master; git commit" - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "Entonces, en este nivel vamos a lograr el mismo objetivo de corregir `C2`, pero sin usar `rebase -i`. Te dejo a vos el darte cuenta cómo :D", - "", - "Acordate, la cantidad exacta de apóstrofes (') en el commit no es importante, sólo la diferencia relativa. Por ejemplo, le voy a dar puntaje a un árbol que matchee el objetivo pero cuyos commits tengan todos un apóstrofe extra" - ] - } - } - ] - }, - "pt_BR": { - "childViews": [ - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "## Malabarismo com commits #2", - "", - "*Caso você não tenha completado o nível anterior (Malabarismo com commits #1), por favor faça-o antes de continuar*", - "", - "Como você viu no nível anterior, usamos `rebase -i` para reordenar os commits. Uma vez que o commit que queríamos mudar estava no topo, pudemos facilmente usar o `--amend` e depois reordená-lo de volta para obter nossa ordem preferida.", - "", - "O único problema aqui é que há muita reordenação ocorrendo, o que pode introduzir conflitos de rebase. Vamos dar uma olhada em outro método, usando o `git cherry-pick`" - ] - } - }, - { - "type": "GitDemonstrationView", - "options": { - "beforeMarkdowns": [ - "Lembre-se que o git cherry-pick copiará um commit de qualquer lugar na árvore sob o HEAD (desde que esse commit não seja um ancestral do HEAD).", - "", - "Aqui está uma demonstração para refrescar sua memória:" - ], - "afterMarkdowns": [ - "Ótimo! Vamos em frente" - ], - "command": "git cherry-pick C2", - "beforeCommand": "git checkout -b bugFix; git commit; git checkout master; git commit" - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "Então, neste nível, vamos alcançar o mesmo objetivo de fazer \"amend\" no `C2`, mas evitaremos usar o `rebase -i`. Agora vou deixar com você a tarefa de descobrir como fazer! :D", - "", - "Lembre-se, o número exato de apóstrofos (') nos commits não é importante, apenas as diferenças relativas. Por exemplo, darei todos os pontos nesta tarefa se você obtiver o mesmo resultado da árvore da visualização de objetivo com um apóstrofo extra em todos os commits" - ] - } - } - ] - }, - "de_DE": { - "childViews": [ - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "## Jonglieren mit Commits Teil 2", - "", - "Du solltest \"Jonglieren mit Commits\" (den vorherigen Level) bestanden haben, bevor du dich an diesem hier versuchst.", - "", - "Wie du im letzten Level gesehen hast haben wir `git rebase -i` genutzt, um die Commits neu anzuordnen. Sobald der Commit, den wir ändern wollte, ganz oben war, konnten wir das auch einfach mit `git commit --amend` tun. Danach haben wir die alte Reihenfolge wiederhergestellt.", - "", - "Das einzige Problem ist hier, dass da eine Menge Umsortieren stattfindet, was zu Rebase-Konflikten führen kann. Schauen wir uns also eine Methode mit `git cherry-pick` an." - ] - } - }, - { - "type": "GitDemonstrationView", - "options": { - "beforeMarkdowns": [ - "Wie du dich erinnerst macht `git cherry-pick` eine Kopie des angegebenen Commits und fügt sie an `HEAD` an (es sei denn der Commit ist ein Vorgänger von `HEAD`).", - "", - "Hier eine kleine Demo zur Erinnerung:" - ], - "afterMarkdowns": [ - "Schick! Und weiter geht's." - ], - "command": "git cherry-pick C2", - "beforeCommand": "git checkout -b bugFix; git commit; git checkout master; git commit" - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "In diesem Level geht es also auch um das Ziel den Commit `C2` zu modifizieren, aber ohne `git rebase -i` zu benutzen. Ich überlass es dir herauszufinden, wie das gehen soll. :D", - "", - "Nicht vergessen, die genaue Anzahl von Kopien (d.h. Apostrophen) ist nicht ausschlaggebend, nur die Differenz. Der Level ist zum Beispiel auch gelöst, wenn dein fertiger Baum dieselbe Struktur wie der Ziel-Baum hat, aber *überall* ein Apostroph mehr aufweist." - ] - } - } - ] - }, - "ja": { - "childViews": [ - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "## コミットをやりくりする その2", - "", - "*注：この一つ前のレベル「コミットをやりくりする」をクリアしていない人は、まずそちらの問題をクリアしてきてください！*", - "", - "前回見てきたように、コミット順序の変更のために、私たちは`rebase -i`コマンドを利用しました。ツリーの先頭に変更対象のコミットがあれば、--amendオプションを使うことで容易に変更を書きかえて、元の順序に戻すことができます。", - "", - "この場合に心配なことが一つだけあって、それは複数回の順序の変更が行われるので、rebaseのコンフリクト（衝突）が起こりうることです。こういうケースへの対策として、`git cherry-pick`を使った別の解決法について考えてみましょう。" - ] - } - }, - { - "type": "GitDemonstrationView", - "options": { - "beforeMarkdowns": [ - "git cherry-pickを使うと、ツリーの中から複数のコミットを選んで、HEADの下に新しく作ることができましたね。", - "", - "簡単なデモを見てみましょう：" - ], - "afterMarkdowns": [ - "できました！次へ進みましょう" - ], - "command": "git cherry-pick C2", - "beforeCommand": "git checkout -b bugFix; git commit; git checkout master; git commit" - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "このレベルでは、`C2`をamendすることで前回と同じ目的を達成しましょう。但し`rebase -i`は使わずにクリアしてください。どんな方法で進めるかはあなたにおまかせします！:D" - ] - } - } - ] - }, - "zh_CN": { - "childViews": [ - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "## 提交变换戏法 #2", - "", - "*假如你还没有完成提交变换戏法 #1（前一关），这关不让玩哦！*", - "", - "如你在上一关所见，我们使用 `rebase -i` 来重排那些提交。只要把我们想要的提交挪到最顶端，我们就可以很容易地改变它，然后把它们重新排成我们想要的顺序。", - "", - "但唯一的问题就是这样做就要排很多次，有可能造成衍合冲突（rebase conflicts）。下面就看看用另外一种方法 `git cherry-pick` 是怎么做的吧。" - ] - } - }, - { - "type": "GitDemonstrationView", - "options": { - "beforeMarkdowns": [ - "要在心理牢记 cherry-pick 可以从提交树的任何地方拿一个提交来放在 HEAD 上（尽管那个提交不在上游）。", - "", - "下面是一个小小的演示：" - ], - "command": "git cherry-pick C2", - "afterMarkdowns": [ - "好滴咧，我们继续" - ], - "beforeCommand": "git checkout -b bugFix; git commit; git checkout master; git commit" - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "那么这关呢，和上一关一样要改变提交 `C2`，但你要避免使用 `rebase -i`。自己想想要怎么解决吧，骚年！ :D" - ] - } - } - ] - }, - "zh_TW": { - "childViews": [ - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "## commit 的戲法 #2", - "", - "*假如你還沒有完成 commit 的戲法 #1（前面那一個關卡），請先完成之後再來這一關！*", - "", - "如你在上一個關卡所看到的，我們使用 `rebase -i` 來重新排列那些 commit。只要把我們想要修改的 commit 移到最前面，我們就可以很容易地重新修改它，然後再把它們重新排成我們想要的順序。", - "", - "但唯一的問題就是這樣做就要排很多次，有可能造成 rebase conflict。下面就看看用另外一種方法 `git cherry-pick` 是怎麼做的吧！" - ] - } - }, - { - "type": "GitDemonstrationView", - "options": { - "beforeMarkdowns": [ - "要記住喔！ cherry-pick 可以從 commit tree 的任何地方拿一個 commit 來放在 HEAD 上（只要那個 commit 不是 HEAD 的 parent）。", - "", - "下面是一個簡單清楚的 demo：" - ], - "command": "git cherry-pick C2", - "afterMarkdowns": [ - "太棒了，我們繼續吧！" - ], - "beforeCommand": "git checkout -b bugFix; git commit; git checkout master; git commit" - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "在這一關和上一關一樣要去修改一個 commit 叫做`C2`，但你要避免使用 `rebase -i`。自己想想看要怎麼解決吧！" - ] - } - } - ] - }, - "ko": { - "childViews": [ - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "## 커밋 갖고 놀기 #2", - "", - "*만약 이전 레벨의 커밋 갖고 놀기 #1을 풀지 않으셨다면, 계속하기에 앞서서 꼭 풀어보세요*", - "", - "이전 레벨에서 보셨듯이 `rebase -i` 명령으로 커밋의 순서를 바꿀 수 있습니다. 정정할 커밋이 바로 직전(top)에 있으면 간단히 --amend로 수정할 수 있고, 그리고 나서 다시 원하는 순서로 되돌려 놓으면 됩니다.", - "", - "이번에 한가지 문제는 순서를 꽤 많이 바꿔야한다는 점인데요, 그러다가 리베이스중에 충돌이 날 수 있습니다. 이번에는 다른 방법인 `git cherry-pick`으로 해결해 봅시다." - ] - } - }, - { - "type": "GitDemonstrationView", - "options": { - "beforeMarkdowns": [ - "git cherry-pick으로 HEAD에다 어떤 커밋이든 떨어 뜨려 놓을 수 있다고 알려드린것 기억나세요? (단, 그 커밋이 현재 가리키고 있는 커밋이 아니어야합니다)", - "", - "간단한 데모로 다시 알려드리겠습니다:" - ], - "afterMarkdowns": [ - "좋아요! 계속할게요" - ], - "command": "git cherry-pick C2", - "beforeCommand": "git checkout -b bugFix; git commit; git checkout master; git commit" - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "그럼 이번 레벨에서는 아까와 마찬가지로 `C2` 커밋의 내용을 정정하되, `rebase -i`를 쓰지 말고 해보세요. ^.~" - ] - } - } - ] - }, - "ru_RU": { - "childViews": [ - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "## Жонглируем коммитами №2", - "", - "*Перед прохождением этого уровня обязательно надо пройти предыдущий уровень – 'Жонглируем коммитами №1'*", - "", - "В прошлом уровне мы использовали `rebase -i`, чтобы переставлять коммиты. Как только нужный нам коммит оказывался в конце, мы могли спокойно изменить его при помощи `--amend` и переставить обратно.", - "", - "Единственная проблема тут - это множество перестановок, которые могут спровоцировать конфликты. Посмотрим, как с этой же задачей справится cherry-pick." - ] - } - }, - { - "type": "GitDemonstrationView", - "options": { - "beforeMarkdowns": [ - "Важно помнить, что cherry-pick поместит любой коммит сразу после HEAD (только если этот коммит не является предком HEAD)", - "", - "Вот небольшое демо для напоминания:" - ], - "afterMarkdowns": [ - "Ок! Едем дальше!" - ], - "command": "git cherry-pick C2", - "beforeCommand": "git checkout -b bugFix; git commit; git checkout master; git commit" - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "Итак, в этом уровне нужно достичь того же эффекта, но без использования `rebase -i`. Остальное – по усмотрению.", - "", - "Важно, чтобы совпадало не только дерево коммитов, но и количество апострофов." - ] - } - } - ] - }, - "uk": { - "childViews": [ - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "## Жонглюємо комітами #2", - "", - "*Якщо ти ще не пройшов Жонглюємо комітами #1 (попередній рівень), будь-ласка, зроби це перед тим як продовжити*", - "", - "Як ти бачив в попередньому рівні, ми використали `rebase -i` щоб впорядкувати набір комітів. Як тільки потрібний коміт опиняється на горі його досить легко змінити його за допомогою --amend й потім відсортувати коміти в попередньому порядку.", - "", - "Єдина проблема з таким підходом, що виконується досить багато перестановок комітів, що може призвести до конфліктів при виконанні rebase. Давайте спробуємо інший підхід який використовує `git cherry-pick`" - ] - } - }, - { - "type": "GitDemonstrationView", - "options": { - "beforeMarkdowns": [ - "Не забувай що git cherry-pick втицьне коміт з будь якого місця в HEAD (якщо це не коміт-предок HEAD).", - "", - "Ось невелике демо, щоб пригадати:" - ], - "afterMarkdowns": [ - "Файно! Продовжуємо" - ], - "command": "git cherry-pick C2", - "beforeCommand": "git checkout -b bugFix; git commit; git checkout master; git commit" - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "Отже в цьому рівні, давайте досягнемо тієї ж мети модифікації `C2` але не використовуючи `rebase -i`. Я думаю ти розберешся як це зробити! :D", - "", - "Зверни увагу що точне число апострофів (') в коміті не важливе, важлива тільки відносна різниця. Наприклад, якщо кожен коміт буде містити додатковий апостроф, я все одно зарахую такий розв’язок." - ] - } - } - ] - } - } -}; +exports.level = { + "goalTreeString": "%7B%22branches%22%3A%7B%22master%22%3A%7B%22target%22%3A%22C3%27%22%2C%22id%22%3A%22master%22%7D%2C%22newImage%22%3A%7B%22target%22%3A%22C2%22%2C%22id%22%3A%22newImage%22%7D%2C%22caption%22%3A%7B%22target%22%3A%22C3%22%2C%22id%22%3A%22caption%22%7D%7D%2C%22commits%22%3A%7B%22C0%22%3A%7B%22parents%22%3A%5B%5D%2C%22id%22%3A%22C0%22%2C%22rootCommit%22%3Atrue%7D%2C%22C1%22%3A%7B%22parents%22%3A%5B%22C0%22%5D%2C%22id%22%3A%22C1%22%7D%2C%22C2%22%3A%7B%22parents%22%3A%5B%22C1%22%5D%2C%22id%22%3A%22C2%22%7D%2C%22C3%22%3A%7B%22parents%22%3A%5B%22C2%22%5D%2C%22id%22%3A%22C3%22%7D%2C%22C2%27%22%3A%7B%22parents%22%3A%5B%22C1%22%5D%2C%22id%22%3A%22C2%27%22%7D%2C%22C2%27%27%22%3A%7B%22parents%22%3A%5B%22C1%22%5D%2C%22id%22%3A%22C2%27%27%22%7D%2C%22C3%27%22%3A%7B%22parents%22%3A%5B%22C2%27%27%22%5D%2C%22id%22%3A%22C3%27%22%7D%7D%2C%22HEAD%22%3A%7B%22target%22%3A%22master%22%2C%22id%22%3A%22HEAD%22%7D%7D", + "solutionCommand": "git checkout master;git cherry-pick C2;git commit --amend;git cherry-pick C3", + "disabledMap": { + "git revert": true + }, + "startTree": "{\"branches\":{\"master\":{\"target\":\"C1\",\"id\":\"master\"},\"newImage\":{\"target\":\"C2\",\"id\":\"newImage\"},\"caption\":{\"target\":\"C3\",\"id\":\"caption\"}},\"commits\":{\"C0\":{\"parents\":[],\"id\":\"C0\",\"rootCommit\":true},\"C1\":{\"parents\":[\"C0\"],\"id\":\"C1\"},\"C2\":{\"parents\":[\"C1\"],\"id\":\"C2\"},\"C3\":{\"parents\":[\"C2\"],\"id\":\"C3\"}},\"HEAD\":{\"target\":\"caption\",\"id\":\"HEAD\"}}", + "compareOnlyMasterHashAgnosticWithAsserts": true, + "goalAsserts": { + "master": [ + function(data) { + return data.C2 > data.C3; + }, + function(data) { + return data.C2 > data.C1; + } + ] + }, + "name": { + "ko": "커밋 갖고 놀기 #2", + "en_US": "Juggling Commits #2", + "fr_FR": "Jongler avec les commits #2", + "es_AR": "Haciendo malabares con los commits #2", + "pt_BR": "Malabarismo com commits #2", + "de_DE": "Jonglieren mit Commits Teil 2", + "ja": "コミットをやりくりする その2", + "zh_CN": "提交交换戏法 #2", + "zh_TW": "commit 的戲法 #2", + "ru_RU": "Жонглируем коммитами №2", + "uk": "Жонглюємо комітами #2" + }, + "hint": { + "en_US": "Don't forget to forward master to the updated changes!", + "fr_FR": "N'oubliez pas de forwarder la branch master dans la nouvelle branch", + "es_AR": "¡No te olvides de avanzar master a los cambios actualizados!", + "pt_BR": "Não se esqueça de avançar a referência do master para as mudanças efetuadas!", + "de_DE": "Vergiss nicht den master auf die aktuelle Version vorzuspulen", + "ja": "masterのポインタを先に進めることを忘れずに！", + "ko": "master를 변경 완료한 커밋으로 이동(forward)시키는 것을 잊지 마세요!", + "zh_CN": "别忘记了将 master 快进到最新的更新上！", + "zh_TW": "別忘記了將 master 推到最新的 commit 上面！", + "ru_RU": "Не забудь переместить master на последние изменения.", + "uk": "Не забудь перемістити master на останні зміни!" + }, + "startDialog": { + "en_US": { + "childViews": [ + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "## Juggling Commits #2", + "", + "*If you haven't completed Juggling Commits #1 (the previous level), please do so before continuing*", + "", + "As you saw in the last level, we used `rebase -i` to reorder the commits. Once the commit we wanted to change was on top, we could easily --amend it and re-order back to our preferred order.", + "", + "The only issue here is that there is a lot of reordering going on, which can introduce rebase conflicts. Let's look at another method with `git cherry-pick`" + ] + } + }, + { + "type": "GitDemonstrationView", + "options": { + "beforeMarkdowns": [ + "Remember that git cherry-pick will plop down a commit from anywhere in the tree onto HEAD (as long as that commit isn't an ancestor of HEAD).", + "", + "Here's a small refresher demo:" + ], + "afterMarkdowns": [ + "Nice! Let's move on" + ], + "command": "git cherry-pick C2", + "beforeCommand": "git checkout -b bugFix; git commit; git checkout master; git commit" + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "So in this level, let's accomplish the same objective of amending `C2` once but avoid using `rebase -i`. I'll leave it up to you to figure it out! :D", + "", + "Remember, the exact number of apostrophe's (') on the commit are not important, only the relative differences. For example, I will give credit to a tree that matches the goal tree but has one extra apostrophe everywhere" + ] + } + } + ] + }, + "fr_FR": { + "childViews": [ + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "## Jongler avec les commits #2", + "", + "*Si vous n'avez pas fait le défi Jongler avec les commits #1 (le niveau précédent), vous devriez le faire avant de continuer*", + "", + "Comme vu dans le niveau précédent, nous utilisons `rebase -i` pour réordonner les commits. Une fois que le commit à modifier est celui à la tête, nous pouvons facilement faire un --amend et réordonner dans l'ordre voulu.", + "", + "La difficulté ici est qu'il y a beaucoup de changements, ce qui peut introduire des conflits de rebase. Essayons avec l'autre méthode `git cherry-pick`" + ] + } + }, + { + "type": "GitDemonstrationView", + "options": { + "beforeMarkdowns": [ + "N'oubliez pas que git cherry-pick va prendre un commit de n'importe où dans l'arbre de git et le mettre devant HEAD (sauf s'il est un ancêtre de HEAD).", + "", + "Un petit rappel :" + ], + "afterMarkdowns": [ + "Bien ! continuons." + ], + "command": "git cherry-pick C2", + "beforeCommand": "git checkout -b bugFix; git commit; git checkout master; git commit" + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "Dans ce niveau, nous voulons modifier `C2` sans utiliser `rebase -i`. À vous maintenant de trouver comment ! :D", + "", + "Petit rappel, le nombre exact d'apostrophes (') sur le commit n'est pas important. Par exemple, nous donnerons les points à une structure qui colle au résultat mais qui a une apostrophe en trop partout." + ] + } + } + ] + }, + "es_AR": { + "childViews": [ + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "## Haciendo malabares con los commits #2", + "", + "*Si no completaste Haciendo malabares con los commits #1 (el nivel anterior), hacelo antes de continuar*", + "", + "Como viste en el último nivel, usamos `rebase -i` para reordenar los commits. Una vez que el commit que queríamos cambiar estaba arriba de todo, pudimos `--amend`earlo fácilmente y reordenarlo a como queríamos.", + "", + "El único problema con esto es que hay mucho reordenamiento, que puede generar conflictos al rebasear. Veamos otro método usando `git cherry-pick`" + ] + } + }, + { + "type": "GitDemonstrationView", + "options": { + "beforeMarkdowns": [ + "Acordate de que git cherry-pick va a traer un commit de cualquier parte del árbol sobre HEAD (siempre que ese otro commit no sea un ancestro de HEAD).", + "", + "Una pequeña demo para refrescar la idea:" + ], + "afterMarkdowns": [ + "¡Bien! Sigamos..." + ], + "command": "git cherry-pick C2", + "beforeCommand": "git checkout -b bugFix; git commit; git checkout master; git commit" + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "Entonces, en este nivel vamos a lograr el mismo objetivo de corregir `C2`, pero sin usar `rebase -i`. Te dejo a vos el darte cuenta cómo :D", + "", + "Acordate, la cantidad exacta de apóstrofes (') en el commit no es importante, sólo la diferencia relativa. Por ejemplo, le voy a dar puntaje a un árbol que matchee el objetivo pero cuyos commits tengan todos un apóstrofe extra" + ] + } + } + ] + }, + "pt_BR": { + "childViews": [ + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "## Malabarismo com commits #2", + "", + "*Caso você não tenha completado o nível anterior (Malabarismo com commits #1), por favor faça-o antes de continuar*", + "", + "Como você viu no nível anterior, usamos `rebase -i` para reordenar os commits. Uma vez que o commit que queríamos mudar estava no topo, pudemos facilmente usar o `--amend` e depois reordená-lo de volta para obter nossa ordem preferida.", + "", + "O único problema aqui é que há muita reordenação ocorrendo, o que pode introduzir conflitos de rebase. Vamos dar uma olhada em outro método, usando o `git cherry-pick`" + ] + } + }, + { + "type": "GitDemonstrationView", + "options": { + "beforeMarkdowns": [ + "Lembre-se que o git cherry-pick copiará um commit de qualquer lugar na árvore sob o HEAD (desde que esse commit não seja um ancestral do HEAD).", + "", + "Aqui está uma demonstração para refrescar sua memória:" + ], + "afterMarkdowns": [ + "Ótimo! Vamos em frente" + ], + "command": "git cherry-pick C2", + "beforeCommand": "git checkout -b bugFix; git commit; git checkout master; git commit" + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "Então, neste nível, vamos alcançar o mesmo objetivo de fazer \"amend\" no `C2`, mas evitaremos usar o `rebase -i`. Agora vou deixar com você a tarefa de descobrir como fazer! :D", + "", + "Lembre-se, o número exato de apóstrofos (') nos commits não é importante, apenas as diferenças relativas. Por exemplo, darei todos os pontos nesta tarefa se você obtiver o mesmo resultado da árvore da visualização de objetivo com um apóstrofo extra em todos os commits" + ] + } + } + ] + }, + "de_DE": { + "childViews": [ + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "## Jonglieren mit Commits Teil 2", + "", + "Du solltest \"Jonglieren mit Commits\" (den vorherigen Level) bestanden haben, bevor du dich an diesem hier versuchst.", + "", + "Wie du im letzten Level gesehen hast haben wir `git rebase -i` genutzt, um die Commits neu anzuordnen. Sobald der Commit, den wir ändern wollte, ganz oben war, konnten wir das auch einfach mit `git commit --amend` tun. Danach haben wir die alte Reihenfolge wiederhergestellt.", + "", + "Das einzige Problem ist hier, dass da eine Menge Umsortieren stattfindet, was zu Rebase-Konflikten führen kann. Schauen wir uns also eine Methode mit `git cherry-pick` an." + ] + } + }, + { + "type": "GitDemonstrationView", + "options": { + "beforeMarkdowns": [ + "Wie du dich erinnerst macht `git cherry-pick` eine Kopie des angegebenen Commits und fügt sie an `HEAD` an (es sei denn der Commit ist ein Vorgänger von `HEAD`).", + "", + "Hier eine kleine Demo zur Erinnerung:" + ], + "afterMarkdowns": [ + "Schick! Und weiter geht's." + ], + "command": "git cherry-pick C2", + "beforeCommand": "git checkout -b bugFix; git commit; git checkout master; git commit" + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "In diesem Level geht es also auch um das Ziel den Commit `C2` zu modifizieren, aber ohne `git rebase -i` zu benutzen. Ich überlass es dir herauszufinden, wie das gehen soll. :D", + "", + "Nicht vergessen, die genaue Anzahl von Kopien (d.h. Apostrophen) ist nicht ausschlaggebend, nur die Differenz. Der Level ist zum Beispiel auch gelöst, wenn dein fertiger Baum dieselbe Struktur wie der Ziel-Baum hat, aber *überall* ein Apostroph mehr aufweist." + ] + } + } + ] + }, + "ja": { + "childViews": [ + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "## コミットをやりくりする その2", + "", + "*注：この一つ前のレベル「コミットをやりくりする」をクリアしていない人は、まずそちらの問題をクリアしてきてください！*", + "", + "前回見てきたように、コミット順序の変更のために、私たちは`rebase -i`コマンドを利用しました。ツリーの先頭に変更対象のコミットがあれば、--amendオプションを使うことで容易に変更を書きかえて、元の順序に戻すことができます。", + "", + "この場合に心配なことが一つだけあって、それは複数回の順序の変更が行われるので、rebaseのコンフリクト（衝突）が起こりうることです。こういうケースへの対策として、`git cherry-pick`を使った別の解決法について考えてみましょう。" + ] + } + }, + { + "type": "GitDemonstrationView", + "options": { + "beforeMarkdowns": [ + "git cherry-pickを使うと、ツリーの中から複数のコミットを選んで、HEADの下に新しく作ることができましたね。", + "", + "簡単なデモを見てみましょう：" + ], + "afterMarkdowns": [ + "できました！次へ進みましょう" + ], + "command": "git cherry-pick C2", + "beforeCommand": "git checkout -b bugFix; git commit; git checkout master; git commit" + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "このレベルでは、`C2`をamendすることで前回と同じ目的を達成しましょう。但し`rebase -i`は使わずにクリアしてください。どんな方法で進めるかはあなたにおまかせします！:D" + ] + } + } + ] + }, + "zh_CN": { + "childViews": [ + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "## 提交变换戏法 #2", + "", + "*假如你还没有完成提交变换戏法 #1（前一关），这关不让玩哦！*", + "", + "如你在上一关所见，我们使用 `rebase -i` 来重排那些提交。只要把我们想要的提交挪到最顶端，我们就可以很容易地改变它，然后把它们重新排成我们想要的顺序。", + "", + "但唯一的问题就是这样做就要排很多次，有可能造成衍合冲突（rebase conflicts）。下面就看看用另外一种方法 `git cherry-pick` 是怎么做的吧。" + ] + } + }, + { + "type": "GitDemonstrationView", + "options": { + "beforeMarkdowns": [ + "要在心理牢记 cherry-pick 可以从提交树的任何地方拿一个提交来放在 HEAD 上（尽管那个提交不在上游）。", + "", + "下面是一个小小的演示：" + ], + "command": "git cherry-pick C2", + "afterMarkdowns": [ + "好滴咧，我们继续" + ], + "beforeCommand": "git checkout -b bugFix; git commit; git checkout master; git commit" + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "那么这关呢，和上一关一样要改变提交 `C2`，但你要避免使用 `rebase -i`。自己想想要怎么解决吧，骚年！ :D" + ] + } + } + ] + }, + "zh_TW": { + "childViews": [ + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "## commit 的戲法 #2", + "", + "*假如你還沒有完成 commit 的戲法 #1（前面那一個關卡），請先完成之後再來這一關！*", + "", + "如你在上一個關卡所看到的，我們使用 `rebase -i` 來重新排列那些 commit。只要把我們想要修改的 commit 移到最前面，我們就可以很容易地重新修改它，然後再把它們重新排成我們想要的順序。", + "", + "但唯一的問題就是這樣做就要排很多次，有可能造成 rebase conflict。下面就看看用另外一種方法 `git cherry-pick` 是怎麼做的吧！" + ] + } + }, + { + "type": "GitDemonstrationView", + "options": { + "beforeMarkdowns": [ + "要記住喔！ cherry-pick 可以從 commit tree 的任何地方拿一個 commit 來放在 HEAD 上（只要那個 commit 不是 HEAD 的 parent）。", + "", + "下面是一個簡單清楚的 demo：" + ], + "command": "git cherry-pick C2", + "afterMarkdowns": [ + "太棒了，我們繼續吧！" + ], + "beforeCommand": "git checkout -b bugFix; git commit; git checkout master; git commit" + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "在這一關和上一關一樣要去修改一個 commit 叫做`C2`，但你要避免使用 `rebase -i`。自己想想看要怎麼解決吧！" + ] + } + } + ] + }, + "ko": { + "childViews": [ + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "## 커밋 갖고 놀기 #2", + "", + "*만약 이전 레벨의 커밋 갖고 놀기 #1을 풀지 않으셨다면, 계속하기에 앞서서 꼭 풀어보세요*", + "", + "이전 레벨에서 보셨듯이 `rebase -i` 명령으로 커밋의 순서를 바꿀 수 있습니다. 정정할 커밋이 바로 직전(top)에 있으면 간단히 --amend로 수정할 수 있고, 그리고 나서 다시 원하는 순서로 되돌려 놓으면 됩니다.", + "", + "이번에 한가지 문제는 순서를 꽤 많이 바꿔야한다는 점인데요, 그러다가 리베이스중에 충돌이 날 수 있습니다. 이번에는 다른 방법인 `git cherry-pick`으로 해결해 봅시다." + ] + } + }, + { + "type": "GitDemonstrationView", + "options": { + "beforeMarkdowns": [ + "git cherry-pick으로 HEAD에다 어떤 커밋이든 떨어 뜨려 놓을 수 있다고 알려드린것 기억나세요? (단, 그 커밋이 현재 가리키고 있는 커밋이 아니어야합니다)", + "", + "간단한 데모로 다시 알려드리겠습니다:" + ], + "afterMarkdowns": [ + "좋아요! 계속할게요" + ], + "command": "git cherry-pick C2", + "beforeCommand": "git checkout -b bugFix; git commit; git checkout master; git commit" + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "그럼 이번 레벨에서는 아까와 마찬가지로 `C2` 커밋의 내용을 정정하되, `rebase -i`를 쓰지 말고 해보세요. ^.~" + ] + } + } + ] + }, + "ru_RU": { + "childViews": [ + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "## Жонглируем коммитами №2", + "", + "*Перед прохождением этого уровня обязательно надо пройти предыдущий уровень – 'Жонглируем коммитами №1'*", + "", + "В прошлом уровне мы использовали `rebase -i`, чтобы переставлять коммиты. Как только нужный нам коммит оказывался в конце, мы могли спокойно изменить его при помощи `--amend` и переставить обратно.", + "", + "Единственная проблема тут - это множество перестановок, которые могут спровоцировать конфликты. Посмотрим, как с этой же задачей справится cherry-pick." + ] + } + }, + { + "type": "GitDemonstrationView", + "options": { + "beforeMarkdowns": [ + "Важно помнить, что cherry-pick поместит любой коммит сразу после HEAD (только если этот коммит не является предком HEAD)", + "", + "Вот небольшое демо для напоминания:" + ], + "afterMarkdowns": [ + "Ок! Едем дальше!" + ], + "command": "git cherry-pick C2", + "beforeCommand": "git checkout -b bugFix; git commit; git checkout master; git commit" + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "Итак, в этом уровне нужно достичь того же эффекта, но без использования `rebase -i`. Остальное – по усмотрению.", + "", + "Важно, чтобы совпадало не только дерево коммитов, но и количество апострофов." + ] + } + } + ] + }, + "uk": { + "childViews": [ + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "## Жонглюємо комітами #2", + "", + "*Якщо ти ще не пройшов Жонглюємо комітами #1 (попередній рівень), будь ласка, зроби це перед тим як продовжити*", + "", + "Як ти бачив в попередньому рівні, ми використали `rebase -i` щоб впорядкувати набір комітів. Як тільки потрібний коміт опиняється на горі його досить легко змінити за допомогою --amend й потім відсортувати коміти в попередньому порядку.", + "", + "Єдина проблема з таким підходом, що виконується досить багато перестановок комітів, що може призвести до конфліктів при виконанні rebase. Давайте спробуємо інший підхід який використовує `git cherry-pick`" + ] + } + }, + { + "type": "GitDemonstrationView", + "options": { + "beforeMarkdowns": [ + "Не забувай, що git cherry-pick вставить коміт з будь-якого місця в HEAD (якщо це не коміт-предок HEAD).", + "", + "Ось невелике демо, щоб пригадати:" + ], + "afterMarkdowns": [ + "Добре! Продовжуємо" + ], + "command": "git cherry-pick C2", + "beforeCommand": "git checkout -b bugFix; git commit; git checkout master; git commit" + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "Отже в цьому рівні, давайте досягнемо тієї ж мети модифікації `C2` але не використовуючи `rebase -i`. Я думаю ти розберешся як це зробити! :D", + "", + "Зверни увагу, що точне число апострофів (') в коміті не важливе, важлива тільки відносна різниця. Наприклад, якщо кожен коміт буде містити додатковий апостроф, я все одно зарахую такий розв’язок." + ] + } + } + ] + } + } +}; diff --git a/src/levels/mixed/tags.js b/src/levels/mixed/tags.js index 430c663a..ccc5a378 100644 --- a/src/levels/mixed/tags.js +++ b/src/levels/mixed/tags.js @@ -1,605 +1,605 @@ -exports.level = { - "goalTreeString": "{\"branches\":{\"master\":{\"target\":\"C5\",\"id\":\"master\",\"remoteTrackingBranchID\":null},\"side\":{\"target\":\"C3\",\"id\":\"side\",\"remoteTrackingBranchID\":null}},\"commits\":{\"C0\":{\"parents\":[],\"id\":\"C0\",\"rootCommit\":true},\"C1\":{\"parents\":[\"C0\"],\"id\":\"C1\"},\"C2\":{\"parents\":[\"C1\"],\"id\":\"C2\"},\"C3\":{\"parents\":[\"C2\"],\"id\":\"C3\"},\"C4\":{\"parents\":[\"C1\"],\"id\":\"C4\"},\"C5\":{\"parents\":[\"C2\",\"C4\"],\"id\":\"C5\"}},\"tags\":{\"v1\":{\"target\":\"C2\",\"id\":\"v1\",\"type\":\"tag\"},\"v0\":{\"target\":\"C1\",\"id\":\"v0\",\"type\":\"tag\"}},\"HEAD\":{\"target\":\"C2\",\"id\":\"HEAD\"}}", - "solutionCommand": "git tag v1 side~1;git tag v0 master~2;git checkout v1", - "startTree": "{\"branches\":{\"master\":{\"target\":\"C5\",\"id\":\"master\",\"remoteTrackingBranchID\":null},\"side\":{\"target\":\"C3\",\"id\":\"side\",\"remoteTrackingBranchID\":null}},\"commits\":{\"C0\":{\"parents\":[],\"id\":\"C0\",\"rootCommit\":true},\"C1\":{\"parents\":[\"C0\"],\"id\":\"C1\"},\"C2\":{\"parents\":[\"C1\"],\"id\":\"C2\"},\"C3\":{\"parents\":[\"C2\"],\"id\":\"C3\"},\"C4\":{\"parents\":[\"C1\"],\"id\":\"C4\"},\"C5\":{\"parents\":[\"C2\",\"C4\"],\"id\":\"C5\"}},\"tags\":{},\"HEAD\":{\"target\":\"master\",\"id\":\"HEAD\"}}", - "name": { - "en_US": "Git Tags", - "de_DE": "Git Tags", - "ja" : "Gitのタグ", - "es_AR": "Tags en git", - "pt_BR": "Tags no Git", - "fr_FR": "Git Tags", - "zh_CN": "Git Tags", - "zh_TW": "git tag", - "ru_RU": "git tag", - "ko" : "Git 태그", - "uk" : "Git Tags" - }, - "hint": { - "en_US": "you can either check out the commit directly or simply checkout the tag!", - "fr_FR": "Vous pouvez faire le checkout sur le commit ou sur le tag !", - "de_DE": "Du kannst den Checkout entweder direkt auf den Commit oder das Tag machen.", - "ja" : "コミットを直接チェックアウトできますが、簡単にタグでチェックアウトすることも可能!", - "es_AR": "Podés checkoutear directamente el commit, ¡o simplemente el tag!", - "pt_BR": "Você pode fazer checkout diretamente no commit ou na tag correspondente!", - "zh_TW": "你可以直接 checkout 到 commit 上，或是簡單的 checkout 到 tag 上", - "zh_CN": "你可以直接 checkout 到 commit 上，或是简单地 checkout 到 tag 上", - "ru_RU": "Можно сделать checkout напрямую на коммит или же на тег", - "ko" : "커밋을 직접 또는 태그를 이용해서 체크아웃할수 있습니다!", - "uk" : "ти можеш або зробити checkout коміта напряму чи просто зачекаутити таг!" - }, - "startDialog": { - "en_US": { - "childViews": [ - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "## Git Tags", - "", - "As you have learned from previous lessons, branches are easy to move around and often refer to different commits as work is completed on them. Branches are easily mutated, often temporary, and always changing.", - "", - "If that's the case, you may be wondering if there's a way to *permanently* mark historical points in your project's history. For things like major releases and big merges, is there any way to mark these commits with something more permanent than a branch?", - "" - ] - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "You bet there is! Git tags support this exact use case -- they (somewhat) permanently mark certain commits as \"milestones\" that you can then reference like a branch.", - "", - "More importantly though, they never move as more commits are created. You can't \"check out\" a tag and then complete work on that tag -- tags exist as anchors in the commit tree that designate certain spots.", - "", - "Let's see what tags look like in practice." - ] - } - }, - { - "type": "GitDemonstrationView", - "options": { - "beforeMarkdowns": [ - "Let's try making a tag at `C1` which is our version 1 prototype" - ], - "afterMarkdowns": [ - "There! Quite easy. We named the tag `v1` and referenced the commit `C1` explicitly. If you leave the commit off, git will just use whatever `HEAD` is at" - ], - "command": "git tag v1 C1", - "beforeCommand": "git commit" - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "For this level just create the tags in the goal visualization and then check `v1` out. Notice how you go into detached `HEAD` state -- this is because you can't commit directly onto the `v1` tag.", - "", - "In the next level we'll examine a more interesting use case for tags." - ] - } - } - ] - }, - "fr_FR": { - "childViews": [ - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "## Git Tags", - "", - "Comme apris dans les niveaux précédents, les branches sont faciles à manipuler et réfèrent aux commits qui ont été fait pour compléter le travail fait sur celles-ci. Les branches sont donc constamment en mouvement.", - "", - "Dans ce cas, vous vous demandez peut-être s'il y a un moyen d'ajouter une marque *permanente* dans l'historique de votre projet. Pour des commits comme des release majeures ou d'importants merge, existe-t-il une façon plus stable qu'une branche de garder l'état d'une branche à un instant précis ?", - "" - ] - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "Vous l'avez deviné ! Git tags offre cette fonctionnalité : les tags marquent à jamais certains commits comme \"milestone\" auxquels vous pouvez vous référez comme à des branches.", - "", - "Encore plus important, il sont définitifs. Vous ne pouvez donc pas rajouter de commit dans un tag : les tags sont un peu comme un pointeur définitif dans l'arbre des commits.", - "", - "Voyons les tags en pratique." - ] - } - }, - { - "type": "GitDemonstrationView", - "options": { - "beforeMarkdowns": [ - "Essayons de faire un tag sur C1 (qui représente la version 1 de notre prototype)" - ], - "afterMarkdowns": [ - "Voila, facile non ? Nous nommons le tag `v1` et il pointe vers le commit `C1`. Si vous ne spécifiez pas le commit, le tag pointera là où se trouve `HEAD`." - ], - "command": "git tag v1 C1", - "beforeCommand": "git commit" - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "Pour ce niveau, créez simplement les tags visibles dans les objectifs puis faites un checkout sur le tag `v1`. Remarquez comment vous vous retrouvez dans l'état `HEAD` détachée -- c'est parce que vous ne pouvez pas commiter sur le tag `v1`.", - "", - "Dans les niveaux suivants vous verrez un cas plus intéressant d'utilisation des tags." - ] - } - } - ] - }, - "zh_TW": { - "childViews": [ - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "## git tag", - "", - "就像你之前學到的一樣，branch 很容易被移動，而且當有新的 commit 時，又會再移動，branch 經常指向不同的 commit，branch 很容易改變。", - "", - "你可能會有疑問，有沒有什麼方法可以*永遠*有一個指向 commit 的記號，例如，表示重大的軟體釋出，或者是修正很大的 bug，有沒有其它比 branch 更好的方法，可以永遠地指向這些 commit？", - "" - ] - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "你說對了！git tag 可以解決這個問題，它們可以永遠地指向某個特定的 commit，就像是表示一個\"里程碑\"一樣。", - "", - "更重要的是，當有新的 commit 時，它們也不會移動，你不可以 \"checkout\" 到 tag 上面 commit，tag 的存在就像是一個在 commit tree 上的表示特定訊息的一個錨。", - "", - "讓我們來實際看一下 tag 長什麼樣子..." - ] - } - }, - { - "type": "GitDemonstrationView", - "options": { - "beforeMarkdowns": [ - "讓我們試著建立一個 tag，指向 commit `C1`，表示這是我們第一個版本。" - ], - "afterMarkdowns": [ - "看吧！非常容易，我們命名這個 tag 叫做 `v1`，並且讓它指向 commit `C1`，如果你離開了該 commit，git 會根據 `HEAD` 所指向的位置才分辨。" - ], - "command": "git tag v1 C1", - "beforeCommand": "git commit" - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "在這個關卡中，建立一個如視覺化目標裡面的 tag，然後 checkout 到 `v1` 上面，要注意你會進到分離 `HEAD` 的狀態，這是因為你不能夠直接在 `v1` 上面做 commit。", - "", - "在下個關卡中我們會介紹更多 tag 的應用..." - ] - } - } - ] - }, - "zh_CN": { - "childViews": [ - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "## git tag", - "", - "就像你之前学到的一样，branch 很容易被移动，而且当有新的 commit 时，又会再移动，branch 经常指向不同的 commit，branch 很容易改变。", - "", - "你可能会有疑问，有没有什么方法可以*永远*有一个指向 commit 的记号，例如，表示重大的软体释出，或者是修正很大的 bug，有没有其它比 branch 更好的方法，可以永远地指向这些 commit？", - "" - ] - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "你说对了！git tag 可以解决这个问题，它们可以永远地指向某个特定的 commit，就像是表示一个\"里程碑\"一样。", - "", - "更重要的是，当有新的 commit 时，它们也不会移动，你不可以 \"checkout\" 到 tag 上面 commit，tag 的存在就像是一个在 commit tree 上的表示特定讯息的一个锚。", - "", - "让我们来实际看一下 tag 长什么样子..." - ] - } - }, - { - "type": "GitDemonstrationView", - "options": { - "beforeMarkdowns": [ - "让我们试着建立一个 tag，指向 commit `C1`，表示这是我们第一个版本。" - ], - "afterMarkdowns": [ - "看吧！非常容易，我们命名这个 tag 叫做 `v1`，并且让它指向 commit `C1`，如果你离开了该 commit，Git 会根据 `HEAD` 所指向的位置才分辨。" - ], - "command": "git tag v1 C1", - "beforeCommand": "git commit" - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "在这个关卡中，建立一个如视觉化目标里面的 tag，然后 checkout 到 `v1` 上面，要注意你会进到分离 `HEAD` 的状态，这是因为你不能够直接在`v1` 上面做 commit。", - "", - "在下个关卡中我们会介绍更多 tag 的应用..." - ] - } - } - ] - }, - "es_AR": { - "childViews": [ - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "## Tags en git", - "", - "Como aprendiste en lecciones anteriores, las ramas pueden moverse fácilmente, y en general van referenciando distintos commits a medida que el trabajo se va completando en ellas. Las ramas cambian fácilmente, suelen ser temporales, y siempre cambiantes.", - "", - "Si ese es el caso, te podrías estar preguntando si hay una manera de marcar *permanentemente* puntos en la historia de tu proyecto. Para cosas como releases mayores o grandes merges, ¿hay algún modo de marcar esos commits con algo más permanente que un branch?", - "" - ] - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "¡Seguro que hay! Los tags de git soportan exactamente este caso de uso -- marcan (bastante) permanentemente determinados commits como \"hitos\" que podés referenciar como a un branch.", - "", - "Aún más importante, los tags no avanzan cuando se crean nuevos commits. No podés \"checkoutear\" un tag y completar el trabajo en ese tag - los tags son marcas fijas en el árbol de commits que designan ciertos puntos.", - "", - "Veamos cómo se ven los tags en práctica..." - ] - } - }, - { - "type": "GitDemonstrationView", - "options": { - "beforeMarkdowns": [ - "Creemos un tag en `C1`, que es nuestro prototipo de la versión 1" - ], - "afterMarkdowns": [ - "¡Ahí está! Bastante simple. Nombramos al tag `v1` y referenciamos explícitamente al commit `C1`. Si no especificás el commit, git va a usar al apuntado por `HEAD`" - ], - "command": "git tag v1 C1", - "beforeCommand": "git commit" - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "Para este nivel, simplemente creá los tags en la visualización final y después checkouteá `v1`. Notá cómo entrás en el estado detached -- esto es porque no podés commitear directamente sobre el tag `v1`.", - "", - "En el próximo nivel vamos a examinar un caso de uso más interesante para los tags." - ] - } - } - ] - }, - "pt_BR": { - "childViews": [ - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "## Tags no Git", - "", - "Como você aprendeu nas lições anteriores, ramos são fáceis de mover e geralmente vão se referindo a diferentes commits conforme você vai trabalhando no código. Ramos são facilmente mutáveis, frequentemente temporários, e estão sempre mudando.", - "", - "Se este é o caso, você pode estar se perguntando se não existe uma forma de marcar *permanentemente* pontos históricos do projeto. Para coisas como grandes releases ou grandes merges, existe alguma forma de marcar commits com algo mais permanente que um ramo?", - "" - ] - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "Você acertou a aposta, existe sim! As tags do Git foram criadas exatamente para esse caso de uso -- elas marcam de forma (relativamente) permanente certos commits como se fossem \"pedras de kilometragem\" (\"milestones\") em uma estrada, e você pode referenciá-las exatamente como faz com ramos.", - "", - "O mais importante, no entanto, é que elas nunca se movem sozinhas quando novos commits são criados. Você pode fazer \"checkout\" em uma tag e então completar trabalho nessa tag -- tags existem como âncoras na árvore de commits que estão atreladas a certos pontos.", - "", - "Vejamos como as tags se comportam na prática." - ] - } - }, - { - "type": "GitDemonstrationView", - "options": { - "beforeMarkdowns": [ - "Criemos uma tag em `C1`, que é nosso protótipo da versão 1" - ], - "afterMarkdowns": [ - "Aqui! Bem fácil. Nós chamamos a tag de `v1` e referenciamos o commit `C1` explicitamente. Se você chamar o comando sem especificar um commit, o git vai usar seja lá qual commit para o qual o `HEAD` estiver apontando" - ], - "command": "git tag v1 C1", - "beforeCommand": "git commit" - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "Para completar esta tarefa, simplesmente crie as tags mostradas na visualização do objetivo, e então faça checkout em `v1`. Veja que você vai para o estado \"Detached HEAD\" -- isso é devido ao fato de que você não pode commitar diretamente na tag `v1`.", - "", - "No próximo nível, examinaremos mais um caso de uso interessante para as tags." - ] - } - } - ] - }, - "de_DE": { - "childViews": [ - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "## Git Tags", - "", - "Wie du aus den vorhergehenden Levels weißt sind Branches einfach durch die Gegend zu schieben und zeigen of auf verschiedene Commits, während die Arbeit in ihnen fortschreitet. Ein Branch wird oft verändert, manchmal nur temporär, und ist ständig in Bewegung.", - "", - "Da das so ist fragst du dich vielleicht, ob es nicht eine Möglichkeit gibt, eine bestimmte Stelle in deiner Projekt-History *permanent* zu kennzeichnen. Kann man nicht zum Beispiel für große Releases und Meilensteine nicht einen Commit mit etwas festerem kennzeichnen, als mit einem Branch-Namen?", - "" - ] - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "Aber klar! In Git gibt es genau zu diesem Zweck Tags -- sie kennzeichnen einen Commit (ziemlich) permanent als Meilenstein oder ähnliches, und man kann sie ansprechen wie Branch-Namen.", - "", - "Noch viel wichtiger, Tags verändern nicht ihre Position wenn man Commits hinzufügt. Du kannst ein Tag nicht in diesem Sinne auschecken und dann Modifikationen darauf committen. Tags sind Anker im Commit-Baum, die bestimmte Stellen anzeigen.", - "", - "Lass uns anschauen wie Tags in der Praxis funktionieren." - ] - } - }, - { - "type": "GitDemonstrationView", - "options": { - "beforeMarkdowns": [ - "Lass uns ein Tag bei `C1` anlegen und damit die Version 1 unseres Prototyps markieren." - ], - "afterMarkdowns": [ - "Peng! Ziemlich einfach. Wir haben das Tag `v1` genannt und lassen es auf `C1` zeigen. Wenn du den Commit weglässt wir das Tag für den Commit erzeugt, auf den `HEAD` zeigt." - ], - "command": "git tag v1 C1", - "beforeCommand": "git commit" - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "Um diesen Level zu schaffen, erstelle einfach die Tags wie sie in der Zielbeschreibung stehen und mach dann einen Checkout auf `v1`. Beachte wie du dabei in den \"Detached HEAD\" Zustand gehst -- das liegt daran, dass du keine Commits direkt auf das `v1` Tag machen kannst.", - "", - "Im nächsten Level schauen wir uns dann interessantere Anwendungsfälle für Tags an." - ] - } - } - ] - }, - "ja": { - "childViews": [ - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "## Gitのタグ", - "", - "私たちは、前回、ブランチが簡単に移動でき、またしばしば異なる作業の完了しているコミットを参照できることを学びました。ブランチは、簡単に変化させることができ、しばしば一時的で、いつも移動しています。", - "", - "そのような場合に、もしプロジェクトの歴史的な点に*恒久的*にマークをつける方法があったならと思うかもしれません。例えば、メジャーリリースや大きなマージを行った時などに、そのコミットにブランチより恒久的な印をつける方法はないのでしょうか？", - "" - ] - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "それは存在します！Gitのタグは当にそのような場面で最適です。 -- ブランチのように参照でき、「マイルストーン（標識）」のような確かで（多少）永久的な印をコミットにつけます。", - "", - "重要なことは、コミットを新たに作ってもタグは動かないということです。あなたは、タグにチェックアウトしてそのタグで作業を完了させるということはできません -- タグは、コミットツリーの特定の地点を指定する錨のようなものとして機能します。", - "", - "では、実際にタグがどのように動作するかを見てみましょう。" - ] - } - }, - { - "type": "GitDemonstrationView", - "options": { - "beforeMarkdowns": [ - "私たちのバージョン1の原本となる`C1`にタグを付けてみましょう" - ], - "afterMarkdowns": [ - "見てください！とても簡単ですね。私たちは、`v1`という名前のタグを明示的に`C1`コミットに付与しました。もし、コミットを指定しなかった場合、`HEAD`にあるものにタグがつけられることになります。" - ], - "command": "git tag v1 C1", - "beforeCommand": "git commit" - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "このレベルは、ゴールとして提示されている図のようにタグを作り、`v1`にチェックアウトすることで完了します。そうすると、あなたは`HEAD`分離状態になることに気づくでしょう -- これは、あなたが直接`v1`タグにコミットができないことを意味しています。", - "", - "次のレベルでは、タグのより興味深い使い方について学びます。" - ] - } - } - ] - }, - "ru_RU": { - "childViews": [ - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "## Теги", - "", - "В прошлых уроках мы усвоили, что ветки просто двигать туда-сюда и они часто ссылаются на разные коммиты как на изменения данных в ветке. Ветки просто изменить, они часто временны и постоянно меняют своё состояние.", - "", - "В таком случае, где взять *постоянную* ссылку на момент в истории изменений? Для таких вещей, как релиз, большие слияния нужно нечто более постоянное, чем ветка.", - "" - ] - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "Такое средство имеется. Git предоставляет нам теги, чья основная задача – ссылаться постоянно на конкретный коммит.", - "", - "Важно, что после создания они никогда не сменят своего положения, так что можно с лёгкостью сделать checkout конкретного момента в истории изменений", - "", - "Посмотрим на это на практике." - ] - } - }, - { - "type": "GitDemonstrationView", - "options": { - "beforeMarkdowns": [ - "Создадим тег на `C1`, который будет нашей версией 1" - ], - "afterMarkdowns": [ - "Готово! Всё просто. Мы назвали тег `v1` и заставили его ссылаться на `C1` явным образом. Если конкретный коммит не указан, гит пометит тегом `HEAD`" - ], - "command": "git tag v1 C1", - "beforeCommand": "git commit" - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "Чтобы пройти этот уровень, просто создай теги так, как показано на визуализации, и потом перейди на тег `v1`. Обрати внимание, что ты перейдёшь в состояние `detached HEAD`, так как нельзя сделать коммит прямо в тег `v1`.", - "", - "В следующем уровне мы попробуем более интересные способы применения тегов." - ] - } - } - ] - }, - "ko": { - "childViews": [ - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "## Git 태그", - "", - "이전 강의에서 배웠듯이, 브랜치는 이동하기 쉽습니다. 작업의 완료, 진행에따라 이리저리 이동하면서 서로다른 커밋을 참조하게 됩니다. 브랜치는 쉽게 변하며 임시적인 것입니다 항상 바뀌고 있죠.", - "", - "이런 상황에서, 여러분은 여러분의 프로젝트의 역사(작업 이력)에서 중요한 지점들에 *영구적으로* 표시를 할 방법이 없을까 궁금할것입니다. 주요 릴리즈나 큰 브랜치 병합(merge)이 있을때가 그런 상황이겠군요. 이런 상황에 커밋들을 표시할 브랜치보다 영구적인 방법이 있을까요?", - "" - ] - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "당연히 있습니다! Git 태그는 딱 이런 상황을 위해 존재합니다 -- Git 태그는 특정 커밋들을 브랜치로 참조하듯이 영구적인 \"milestone(이정표)\"으로 표시합니다.", - "", - "중요한 점은, Git 태그는 커밋들이 추가적으로 생성되어도 절대 움직이지 않는다는 것입니다. 여러분은 태그를 \"체크아웃\"한 후에 그 태그에서 어떤 작업을 완료할 수 없습니다 -- 태그는 커밋 트리에서 특정 지점을 표시하기위한 닻같은 역할을 합니다.", - "", - "자 태그가 무엇을 하는지 예제를 통해 알아봅시다" - ] - } - }, - { - "type": "GitDemonstrationView", - "options": { - "beforeMarkdowns": [ - " 프로토타입의 첫 버전인 `C1`에 태그를 만들어 봅시다." - ], - "afterMarkdowns": [ - "자! 아주 쉽죠. 우리는 태그의 이름을 `v1`이라고 지었고 커밋 `C1`을 지정해서 참조했습니다. 만약 커밋을 지정해주지 않으면 git은 `HEAD`가 있는지점에 태그를 붙일 것입니다." - ], - "command": "git tag v1 C1", - "beforeCommand": "git commit" - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "이번 레벨에서는 goal에 나타난것과 같이 태그를 만들고 `v1`을 체크아웃하면 됩니다. 분리된 `HEAD` 상태로 변하는것을 확인 해 보십시오 -- 이것은 `v1` 태그에 직접 커밋을 할 수 없기 때문입니다.", - "", - "다음 레벨에서는 태그의 더 흥미로운 활용 방법을 확인해 볼 것입니다." - ] - } - } - ] - }, - "uk": { - "childViews": [ - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "## Таги в Git", - "", - "Як ти вже знаєш з попередніх уроків, гілки досить просто переносити в інші місця й вони постійно вказують на різні коміти в процесі того як ті в них додаються. Гілки легко модифікувати, часто тимчасово, й вони постійно змінюються.", - "", - "В такому разі, де взяти *постійне* посилання на момент в історії твого проекту? Для таких речей як релізи чи великі мерджі потрібно щось більш стале ніж гілка.", - "" - ] - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "Єсть один спосіб! Таги в гіт якраз для цього й були створені -- вони (більш-менш) постійно вказують на певні коміти, й відмічають певні \"віхи\" в житті проекту, на які ти можеш потім посилатись так само як на гілки.", - "", - "Але що важливіше, вони ніколи не переміщуються коли створюються нові коміти. Ти не зможеш \"зачекаутити\" таг а потім закомітити якісь зміни в цей таг -- таги просто відмічають корисні чи символічні місця в дереві комітів.", - "", - "Давайте подивимось на практиці" - ] - } - }, - { - "type": "GitDemonstrationView", - "options": { - "beforeMarkdowns": [ - "Давайте спробуємо зробити новий таг на `C1` що є прототипом нашої першої версії (вигаданого проекту)" - ], - "afterMarkdowns": [ - "Ось маєш! Все досить просто. Ми назвали наш таг `v1` й він явно посилається на `C1`. Якщо пропустити коміт, git просто відмітить те на чому знаходиться `HEAD` в данний момент" - ], - "command": "git tag v1 C1", - "beforeCommand": "git commit" - } - }, - { - "type": "ModalAlert", - "options": { - "markdowns": [ - "Для того щоб пройти цей рівень достатньо створити кілька тагів, як показано на візуалізації цілей й потім зачекаутити `v1`. Зауваж що ти потрапиш в стан detached `HEAD` -- це тому що ти не можеш напряму комітити в таг `v1`.", - "", - "В наступному рівні ми розглянемо більш цікавий приклад роботи з тагами." - ] - } - } - ] - } - } -}; +exports.level = { + "goalTreeString": "{\"branches\":{\"master\":{\"target\":\"C5\",\"id\":\"master\",\"remoteTrackingBranchID\":null},\"side\":{\"target\":\"C3\",\"id\":\"side\",\"remoteTrackingBranchID\":null}},\"commits\":{\"C0\":{\"parents\":[],\"id\":\"C0\",\"rootCommit\":true},\"C1\":{\"parents\":[\"C0\"],\"id\":\"C1\"},\"C2\":{\"parents\":[\"C1\"],\"id\":\"C2\"},\"C3\":{\"parents\":[\"C2\"],\"id\":\"C3\"},\"C4\":{\"parents\":[\"C1\"],\"id\":\"C4\"},\"C5\":{\"parents\":[\"C2\",\"C4\"],\"id\":\"C5\"}},\"tags\":{\"v1\":{\"target\":\"C2\",\"id\":\"v1\",\"type\":\"tag\"},\"v0\":{\"target\":\"C1\",\"id\":\"v0\",\"type\":\"tag\"}},\"HEAD\":{\"target\":\"C2\",\"id\":\"HEAD\"}}", + "solutionCommand": "git tag v1 side~1;git tag v0 master~2;git checkout v1", + "startTree": "{\"branches\":{\"master\":{\"target\":\"C5\",\"id\":\"master\",\"remoteTrackingBranchID\":null},\"side\":{\"target\":\"C3\",\"id\":\"side\",\"remoteTrackingBranchID\":null}},\"commits\":{\"C0\":{\"parents\":[],\"id\":\"C0\",\"rootCommit\":true},\"C1\":{\"parents\":[\"C0\"],\"id\":\"C1\"},\"C2\":{\"parents\":[\"C1\"],\"id\":\"C2\"},\"C3\":{\"parents\":[\"C2\"],\"id\":\"C3\"},\"C4\":{\"parents\":[\"C1\"],\"id\":\"C4\"},\"C5\":{\"parents\":[\"C2\",\"C4\"],\"id\":\"C5\"}},\"tags\":{},\"HEAD\":{\"target\":\"master\",\"id\":\"HEAD\"}}", + "name": { + "en_US": "Git Tags", + "de_DE": "Git Tags", + "ja" : "Gitのタグ", + "es_AR": "Tags en git", + "pt_BR": "Tags no Git", + "fr_FR": "Git Tags", + "zh_CN": "Git Tags", + "zh_TW": "git tag", + "ru_RU": "git tag", + "ko" : "Git 태그", + "uk" : "Git Tags" + }, + "hint": { + "en_US": "you can either check out the commit directly or simply checkout the tag!", + "fr_FR": "Vous pouvez faire le checkout sur le commit ou sur le tag !", + "de_DE": "Du kannst den Checkout entweder direkt auf den Commit oder das Tag machen.", + "ja" : "コミットを直接チェックアウトできますが、簡単にタグでチェックアウトすることも可能!", + "es_AR": "Podés checkoutear directamente el commit, ¡o simplemente el tag!", + "pt_BR": "Você pode fazer checkout diretamente no commit ou na tag correspondente!", + "zh_TW": "你可以直接 checkout 到 commit 上，或是簡單的 checkout 到 tag 上", + "zh_CN": "你可以直接 checkout 到 commit 上，或是简单地 checkout 到 tag 上", + "ru_RU": "Можно сделать checkout напрямую на коммит или же на тег", + "ko" : "커밋을 직접 또는 태그를 이용해서 체크아웃할수 있습니다!", + "uk" : "ти можеш або зробити checkout коміта напряму чи просто зачекаутити таг!" + }, + "startDialog": { + "en_US": { + "childViews": [ + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "## Git Tags", + "", + "As you have learned from previous lessons, branches are easy to move around and often refer to different commits as work is completed on them. Branches are easily mutated, often temporary, and always changing.", + "", + "If that's the case, you may be wondering if there's a way to *permanently* mark historical points in your project's history. For things like major releases and big merges, is there any way to mark these commits with something more permanent than a branch?", + "" + ] + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "You bet there is! Git tags support this exact use case -- they (somewhat) permanently mark certain commits as \"milestones\" that you can then reference like a branch.", + "", + "More importantly though, they never move as more commits are created. You can't \"check out\" a tag and then complete work on that tag -- tags exist as anchors in the commit tree that designate certain spots.", + "", + "Let's see what tags look like in practice." + ] + } + }, + { + "type": "GitDemonstrationView", + "options": { + "beforeMarkdowns": [ + "Let's try making a tag at `C1` which is our version 1 prototype" + ], + "afterMarkdowns": [ + "There! Quite easy. We named the tag `v1` and referenced the commit `C1` explicitly. If you leave the commit off, git will just use whatever `HEAD` is at" + ], + "command": "git tag v1 C1", + "beforeCommand": "git commit" + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "For this level just create the tags in the goal visualization and then check `v1` out. Notice how you go into detached `HEAD` state -- this is because you can't commit directly onto the `v1` tag.", + "", + "In the next level we'll examine a more interesting use case for tags." + ] + } + } + ] + }, + "fr_FR": { + "childViews": [ + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "## Git Tags", + "", + "Comme apris dans les niveaux précédents, les branches sont faciles à manipuler et réfèrent aux commits qui ont été fait pour compléter le travail fait sur celles-ci. Les branches sont donc constamment en mouvement.", + "", + "Dans ce cas, vous vous demandez peut-être s'il y a un moyen d'ajouter une marque *permanente* dans l'historique de votre projet. Pour des commits comme des release majeures ou d'importants merge, existe-t-il une façon plus stable qu'une branche de garder l'état d'une branche à un instant précis ?", + "" + ] + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "Vous l'avez deviné ! Git tags offre cette fonctionnalité : les tags marquent à jamais certains commits comme \"milestone\" auxquels vous pouvez vous référez comme à des branches.", + "", + "Encore plus important, il sont définitifs. Vous ne pouvez donc pas rajouter de commit dans un tag : les tags sont un peu comme un pointeur définitif dans l'arbre des commits.", + "", + "Voyons les tags en pratique." + ] + } + }, + { + "type": "GitDemonstrationView", + "options": { + "beforeMarkdowns": [ + "Essayons de faire un tag sur C1 (qui représente la version 1 de notre prototype)" + ], + "afterMarkdowns": [ + "Voila, facile non ? Nous nommons le tag `v1` et il pointe vers le commit `C1`. Si vous ne spécifiez pas le commit, le tag pointera là où se trouve `HEAD`." + ], + "command": "git tag v1 C1", + "beforeCommand": "git commit" + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "Pour ce niveau, créez simplement les tags visibles dans les objectifs puis faites un checkout sur le tag `v1`. Remarquez comment vous vous retrouvez dans l'état `HEAD` détachée -- c'est parce que vous ne pouvez pas commiter sur le tag `v1`.", + "", + "Dans les niveaux suivants vous verrez un cas plus intéressant d'utilisation des tags." + ] + } + } + ] + }, + "zh_TW": { + "childViews": [ + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "## git tag", + "", + "就像你之前學到的一樣，branch 很容易被移動，而且當有新的 commit 時，又會再移動，branch 經常指向不同的 commit，branch 很容易改變。", + "", + "你可能會有疑問，有沒有什麼方法可以*永遠*有一個指向 commit 的記號，例如，表示重大的軟體釋出，或者是修正很大的 bug，有沒有其它比 branch 更好的方法，可以永遠地指向這些 commit？", + "" + ] + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "你說對了！git tag 可以解決這個問題，它們可以永遠地指向某個特定的 commit，就像是表示一個\"里程碑\"一樣。", + "", + "更重要的是，當有新的 commit 時，它們也不會移動，你不可以 \"checkout\" 到 tag 上面 commit，tag 的存在就像是一個在 commit tree 上的表示特定訊息的一個錨。", + "", + "讓我們來實際看一下 tag 長什麼樣子..." + ] + } + }, + { + "type": "GitDemonstrationView", + "options": { + "beforeMarkdowns": [ + "讓我們試著建立一個 tag，指向 commit `C1`，表示這是我們第一個版本。" + ], + "afterMarkdowns": [ + "看吧！非常容易，我們命名這個 tag 叫做 `v1`，並且讓它指向 commit `C1`，如果你離開了該 commit，git 會根據 `HEAD` 所指向的位置才分辨。" + ], + "command": "git tag v1 C1", + "beforeCommand": "git commit" + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "在這個關卡中，建立一個如視覺化目標裡面的 tag，然後 checkout 到 `v1` 上面，要注意你會進到分離 `HEAD` 的狀態，這是因為你不能夠直接在 `v1` 上面做 commit。", + "", + "在下個關卡中我們會介紹更多 tag 的應用..." + ] + } + } + ] + }, + "zh_CN": { + "childViews": [ + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "## git tag", + "", + "就像你之前学到的一样，branch 很容易被移动，而且当有新的 commit 时，又会再移动，branch 经常指向不同的 commit，branch 很容易改变。", + "", + "你可能会有疑问，有没有什么方法可以*永远*有一个指向 commit 的记号，例如，表示重大的软体释出，或者是修正很大的 bug，有没有其它比 branch 更好的方法，可以永远地指向这些 commit？", + "" + ] + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "你说对了！git tag 可以解决这个问题，它们可以永远地指向某个特定的 commit，就像是表示一个\"里程碑\"一样。", + "", + "更重要的是，当有新的 commit 时，它们也不会移动，你不可以 \"checkout\" 到 tag 上面 commit，tag 的存在就像是一个在 commit tree 上的表示特定讯息的一个锚。", + "", + "让我们来实际看一下 tag 长什么样子..." + ] + } + }, + { + "type": "GitDemonstrationView", + "options": { + "beforeMarkdowns": [ + "让我们试着建立一个 tag，指向 commit `C1`，表示这是我们第一个版本。" + ], + "afterMarkdowns": [ + "看吧！非常容易，我们命名这个 tag 叫做 `v1`，并且让它指向 commit `C1`，如果你离开了该 commit，Git 会根据 `HEAD` 所指向的位置才分辨。" + ], + "command": "git tag v1 C1", + "beforeCommand": "git commit" + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "在这个关卡中，建立一个如视觉化目标里面的 tag，然后 checkout 到 `v1` 上面，要注意你会进到分离 `HEAD` 的状态，这是因为你不能够直接在`v1` 上面做 commit。", + "", + "在下个关卡中我们会介绍更多 tag 的应用..." + ] + } + } + ] + }, + "es_AR": { + "childViews": [ + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "## Tags en git", + "", + "Como aprendiste en lecciones anteriores, las ramas pueden moverse fácilmente, y en general van referenciando distintos commits a medida que el trabajo se va completando en ellas. Las ramas cambian fácilmente, suelen ser temporales, y siempre cambiantes.", + "", + "Si ese es el caso, te podrías estar preguntando si hay una manera de marcar *permanentemente* puntos en la historia de tu proyecto. Para cosas como releases mayores o grandes merges, ¿hay algún modo de marcar esos commits con algo más permanente que un branch?", + "" + ] + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "¡Seguro que hay! Los tags de git soportan exactamente este caso de uso -- marcan (bastante) permanentemente determinados commits como \"hitos\" que podés referenciar como a un branch.", + "", + "Aún más importante, los tags no avanzan cuando se crean nuevos commits. No podés \"checkoutear\" un tag y completar el trabajo en ese tag - los tags son marcas fijas en el árbol de commits que designan ciertos puntos.", + "", + "Veamos cómo se ven los tags en práctica..." + ] + } + }, + { + "type": "GitDemonstrationView", + "options": { + "beforeMarkdowns": [ + "Creemos un tag en `C1`, que es nuestro prototipo de la versión 1" + ], + "afterMarkdowns": [ + "¡Ahí está! Bastante simple. Nombramos al tag `v1` y referenciamos explícitamente al commit `C1`. Si no especificás el commit, git va a usar al apuntado por `HEAD`" + ], + "command": "git tag v1 C1", + "beforeCommand": "git commit" + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "Para este nivel, simplemente creá los tags en la visualización final y después checkouteá `v1`. Notá cómo entrás en el estado detached -- esto es porque no podés commitear directamente sobre el tag `v1`.", + "", + "En el próximo nivel vamos a examinar un caso de uso más interesante para los tags." + ] + } + } + ] + }, + "pt_BR": { + "childViews": [ + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "## Tags no Git", + "", + "Como você aprendeu nas lições anteriores, ramos são fáceis de mover e geralmente vão se referindo a diferentes commits conforme você vai trabalhando no código. Ramos são facilmente mutáveis, frequentemente temporários, e estão sempre mudando.", + "", + "Se este é o caso, você pode estar se perguntando se não existe uma forma de marcar *permanentemente* pontos históricos do projeto. Para coisas como grandes releases ou grandes merges, existe alguma forma de marcar commits com algo mais permanente que um ramo?", + "" + ] + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "Você acertou a aposta, existe sim! As tags do Git foram criadas exatamente para esse caso de uso -- elas marcam de forma (relativamente) permanente certos commits como se fossem \"pedras de kilometragem\" (\"milestones\") em uma estrada, e você pode referenciá-las exatamente como faz com ramos.", + "", + "O mais importante, no entanto, é que elas nunca se movem sozinhas quando novos commits são criados. Você pode fazer \"checkout\" em uma tag e então completar trabalho nessa tag -- tags existem como âncoras na árvore de commits que estão atreladas a certos pontos.", + "", + "Vejamos como as tags se comportam na prática." + ] + } + }, + { + "type": "GitDemonstrationView", + "options": { + "beforeMarkdowns": [ + "Criemos uma tag em `C1`, que é nosso protótipo da versão 1" + ], + "afterMarkdowns": [ + "Aqui! Bem fácil. Nós chamamos a tag de `v1` e referenciamos o commit `C1` explicitamente. Se você chamar o comando sem especificar um commit, o git vai usar seja lá qual commit para o qual o `HEAD` estiver apontando" + ], + "command": "git tag v1 C1", + "beforeCommand": "git commit" + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "Para completar esta tarefa, simplesmente crie as tags mostradas na visualização do objetivo, e então faça checkout em `v1`. Veja que você vai para o estado \"Detached HEAD\" -- isso é devido ao fato de que você não pode commitar diretamente na tag `v1`.", + "", + "No próximo nível, examinaremos mais um caso de uso interessante para as tags." + ] + } + } + ] + }, + "de_DE": { + "childViews": [ + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "## Git Tags", + "", + "Wie du aus den vorhergehenden Levels weißt sind Branches einfach durch die Gegend zu schieben und zeigen of auf verschiedene Commits, während die Arbeit in ihnen fortschreitet. Ein Branch wird oft verändert, manchmal nur temporär, und ist ständig in Bewegung.", + "", + "Da das so ist fragst du dich vielleicht, ob es nicht eine Möglichkeit gibt, eine bestimmte Stelle in deiner Projekt-History *permanent* zu kennzeichnen. Kann man nicht zum Beispiel für große Releases und Meilensteine nicht einen Commit mit etwas festerem kennzeichnen, als mit einem Branch-Namen?", + "" + ] + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "Aber klar! In Git gibt es genau zu diesem Zweck Tags -- sie kennzeichnen einen Commit (ziemlich) permanent als Meilenstein oder ähnliches, und man kann sie ansprechen wie Branch-Namen.", + "", + "Noch viel wichtiger, Tags verändern nicht ihre Position wenn man Commits hinzufügt. Du kannst ein Tag nicht in diesem Sinne auschecken und dann Modifikationen darauf committen. Tags sind Anker im Commit-Baum, die bestimmte Stellen anzeigen.", + "", + "Lass uns anschauen wie Tags in der Praxis funktionieren." + ] + } + }, + { + "type": "GitDemonstrationView", + "options": { + "beforeMarkdowns": [ + "Lass uns ein Tag bei `C1` anlegen und damit die Version 1 unseres Prototyps markieren." + ], + "afterMarkdowns": [ + "Peng! Ziemlich einfach. Wir haben das Tag `v1` genannt und lassen es auf `C1` zeigen. Wenn du den Commit weglässt wir das Tag für den Commit erzeugt, auf den `HEAD` zeigt." + ], + "command": "git tag v1 C1", + "beforeCommand": "git commit" + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "Um diesen Level zu schaffen, erstelle einfach die Tags wie sie in der Zielbeschreibung stehen und mach dann einen Checkout auf `v1`. Beachte wie du dabei in den \"Detached HEAD\" Zustand gehst -- das liegt daran, dass du keine Commits direkt auf das `v1` Tag machen kannst.", + "", + "Im nächsten Level schauen wir uns dann interessantere Anwendungsfälle für Tags an." + ] + } + } + ] + }, + "ja": { + "childViews": [ + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "## Gitのタグ", + "", + "私たちは、前回、ブランチが簡単に移動でき、またしばしば異なる作業の完了しているコミットを参照できることを学びました。ブランチは、簡単に変化させることができ、しばしば一時的で、いつも移動しています。", + "", + "そのような場合に、もしプロジェクトの歴史的な点に*恒久的*にマークをつける方法があったならと思うかもしれません。例えば、メジャーリリースや大きなマージを行った時などに、そのコミットにブランチより恒久的な印をつける方法はないのでしょうか？", + "" + ] + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "それは存在します！Gitのタグは当にそのような場面で最適です。 -- ブランチのように参照でき、「マイルストーン（標識）」のような確かで（多少）永久的な印をコミットにつけます。", + "", + "重要なことは、コミットを新たに作ってもタグは動かないということです。あなたは、タグにチェックアウトしてそのタグで作業を完了させるということはできません -- タグは、コミットツリーの特定の地点を指定する錨のようなものとして機能します。", + "", + "では、実際にタグがどのように動作するかを見てみましょう。" + ] + } + }, + { + "type": "GitDemonstrationView", + "options": { + "beforeMarkdowns": [ + "私たちのバージョン1の原本となる`C1`にタグを付けてみましょう" + ], + "afterMarkdowns": [ + "見てください！とても簡単ですね。私たちは、`v1`という名前のタグを明示的に`C1`コミットに付与しました。もし、コミットを指定しなかった場合、`HEAD`にあるものにタグがつけられることになります。" + ], + "command": "git tag v1 C1", + "beforeCommand": "git commit" + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "このレベルは、ゴールとして提示されている図のようにタグを作り、`v1`にチェックアウトすることで完了します。そうすると、あなたは`HEAD`分離状態になることに気づくでしょう -- これは、あなたが直接`v1`タグにコミットができないことを意味しています。", + "", + "次のレベルでは、タグのより興味深い使い方について学びます。" + ] + } + } + ] + }, + "ru_RU": { + "childViews": [ + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "## Теги", + "", + "В прошлых уроках мы усвоили, что ветки просто двигать туда-сюда и они часто ссылаются на разные коммиты как на изменения данных в ветке. Ветки просто изменить, они часто временны и постоянно меняют своё состояние.", + "", + "В таком случае, где взять *постоянную* ссылку на момент в истории изменений? Для таких вещей, как релиз, большие слияния нужно нечто более постоянное, чем ветка.", + "" + ] + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "Такое средство имеется. Git предоставляет нам теги, чья основная задача – ссылаться постоянно на конкретный коммит.", + "", + "Важно, что после создания они никогда не сменят своего положения, так что можно с лёгкостью сделать checkout конкретного момента в истории изменений", + "", + "Посмотрим на это на практике." + ] + } + }, + { + "type": "GitDemonstrationView", + "options": { + "beforeMarkdowns": [ + "Создадим тег на `C1`, который будет нашей версией 1" + ], + "afterMarkdowns": [ + "Готово! Всё просто. Мы назвали тег `v1` и заставили его ссылаться на `C1` явным образом. Если конкретный коммит не указан, гит пометит тегом `HEAD`" + ], + "command": "git tag v1 C1", + "beforeCommand": "git commit" + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "Чтобы пройти этот уровень, просто создай теги так, как показано на визуализации, и потом перейди на тег `v1`. Обрати внимание, что ты перейдёшь в состояние `detached HEAD`, так как нельзя сделать коммит прямо в тег `v1`.", + "", + "В следующем уровне мы попробуем более интересные способы применения тегов." + ] + } + } + ] + }, + "ko": { + "childViews": [ + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "## Git 태그", + "", + "이전 강의에서 배웠듯이, 브랜치는 이동하기 쉽습니다. 작업의 완료, 진행에따라 이리저리 이동하면서 서로다른 커밋을 참조하게 됩니다. 브랜치는 쉽게 변하며 임시적인 것입니다 항상 바뀌고 있죠.", + "", + "이런 상황에서, 여러분은 여러분의 프로젝트의 역사(작업 이력)에서 중요한 지점들에 *영구적으로* 표시를 할 방법이 없을까 궁금할것입니다. 주요 릴리즈나 큰 브랜치 병합(merge)이 있을때가 그런 상황이겠군요. 이런 상황에 커밋들을 표시할 브랜치보다 영구적인 방법이 있을까요?", + "" + ] + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "당연히 있습니다! Git 태그는 딱 이런 상황을 위해 존재합니다 -- Git 태그는 특정 커밋들을 브랜치로 참조하듯이 영구적인 \"milestone(이정표)\"으로 표시합니다.", + "", + "중요한 점은, Git 태그는 커밋들이 추가적으로 생성되어도 절대 움직이지 않는다는 것입니다. 여러분은 태그를 \"체크아웃\"한 후에 그 태그에서 어떤 작업을 완료할 수 없습니다 -- 태그는 커밋 트리에서 특정 지점을 표시하기위한 닻같은 역할을 합니다.", + "", + "자 태그가 무엇을 하는지 예제를 통해 알아봅시다" + ] + } + }, + { + "type": "GitDemonstrationView", + "options": { + "beforeMarkdowns": [ + " 프로토타입의 첫 버전인 `C1`에 태그를 만들어 봅시다." + ], + "afterMarkdowns": [ + "자! 아주 쉽죠. 우리는 태그의 이름을 `v1`이라고 지었고 커밋 `C1`을 지정해서 참조했습니다. 만약 커밋을 지정해주지 않으면 git은 `HEAD`가 있는지점에 태그를 붙일 것입니다." + ], + "command": "git tag v1 C1", + "beforeCommand": "git commit" + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "이번 레벨에서는 goal에 나타난것과 같이 태그를 만들고 `v1`을 체크아웃하면 됩니다. 분리된 `HEAD` 상태로 변하는것을 확인 해 보십시오 -- 이것은 `v1` 태그에 직접 커밋을 할 수 없기 때문입니다.", + "", + "다음 레벨에서는 태그의 더 흥미로운 활용 방법을 확인해 볼 것입니다." + ] + } + } + ] + }, + "uk": { + "childViews": [ + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "## Таги в Git", + "", + "Як ти вже знаєш з попередніх уроків, гілки досить просто переносити в інші місця і вони постійно вказують на різні коміти в процесі того як ті в них додаються. Гілки легко модифікувати, часто тимчасово, й вони постійно змінюються.", + "", + "В такому разі, де взяти *постійне* посилання на момент в історії твого проекту? Для таких речей як релізи чи великі мерджі потрібно щось більш стале ніж гілка.", + "" + ] + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "Є один спосіб! Таги в гіт якраз для цього й були створені -- вони (більш-менш) постійно вказують на певні коміти, й відмічають певні \"віхи\" в житті проекту, на які ти можеш потім посилатись так само як на гілки.", + "", + "Але що важливіше, вони ніколи не переміщуються коли створюються нові коміти. Ти не зможеш \"зачекаутити\" таг а потім закомітити якісь зміни в цей таг -- таги просто відмічають корисні чи символічні місця в дереві комітів.", + "", + "Давайте подивимось на практиці" + ] + } + }, + { + "type": "GitDemonstrationView", + "options": { + "beforeMarkdowns": [ + "Давайте спробуємо зробити новий таг на `C1` що є прототипом нашої першої версії (вигаданого проекту)" + ], + "afterMarkdowns": [ + "Ось маєш! Все досить просто. Ми назвали наш таг `v1` й він явно посилається на `C1`. Якщо пропустити коміт, git просто відмітить те на чому знаходиться `HEAD` в данний момент" + ], + "command": "git tag v1 C1", + "beforeCommand": "git commit" + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "Для того щоб пройти цей рівень достатньо створити кілька тагів, як показано на візуалізації цілей й потім зачекаутити `v1`. Зауваж що ти потрапиш в стан detached `HEAD` -- це тому що ти не можеш напряму комітити в таг `v1`.", + "", + "В наступному рівні ми розглянемо більш цікавий приклад роботи з тагами." + ] + } + } + ] + } + } +}; diff --git a/src/levels/rampup/cherryPick.js b/src/levels/rampup/cherryPick.js index 5d93224d..0940b1a4 100644 --- a/src/levels/rampup/cherryPick.js +++ b/src/levels/rampup/cherryPick.js @@ -609,7 +609,7 @@ "markdowns": [ "## Переміщуємо зміни", "", - "Поки що ми розrлядали основи git -- як працювати з комітами та гілками й переміщення по дереву комітів. Цього вже достатньо щоб використовувати 90% фунцкій гіт та мати змогу ефективно працювати з гіт як розробник.", + "Поки що ми розглядали основи git -- як працювати з комітами та гілками й переміщення по дереву комітів. Цього вже достатньо щоб використовувати 90% фунцкій гіт та мати змогу ефективно працювати з гіт як розробник.", "", "Решта 10%, тим не менш, можуть бути надзвичайно корисними при роботі зі складними робочими процесами (workflow), чи коли ти чи ще хтось щось зробили не так і ти хочеш це виправити. Наступна концепція з якою ми познайомимось це \"перенесення змін\" -- іншими словами, це можливість розробника переміщувати коміти між гілками в простий та зручний спосіб.", "", @@ -641,7 +641,7 @@ "Ми бачимо репозиторій де є певні зміни в гілці `side` які ми хочемо скопіювати в `master`. Для цього можна використати rebase (який ми вже вивчили), але подивимось як з цим впорається cherry-pick." ], "afterMarkdowns": [ - "Оба-на! Ми хотіли коміти `C2` та `C4` й git вязв і додав їх до поточного розташування. Просто й доступно!" + "Оба-на! Ми хотіли коміти `C2` та `C4` і git додав їх до поточного розташування. Просто й доступно!" ], "command": "git cherry-pick C2 C4", "beforeCommand": "git checkout -b side; git commit; git commit; git commit; git checkout master; git commit;" diff --git a/src/levels/rampup/detachedHead.js b/src/levels/rampup/detachedHead.js index fd98e2fb..0e2d6fd4 100644 --- a/src/levels/rampup/detachedHead.js +++ b/src/levels/rampup/detachedHead.js @@ -809,9 +809,9 @@ exports.level = { "markdowns": [ "## Прогулянка по Git", "", - "Перед тим як ми перейдемо до більш продвинутих фіч гіта, важливо розуміти різни способи переміщення по дереву комітів твого проекту.", + "Перед тим як ми перейдемо до складніших можливостей гіта, важливо розуміти різні способи переміщення по дереву комітів твого проекту.", "", - "Дуже важливо щоб тобі було комфортно переміщатись по репозиторію, так як цей скіл тобі знадобиться для використання в більшості команд git!", + "Дуже важливо щоб тобі було комфортно переміщатись по репозиторію, так як цей навик тобі знадобиться для використання в більшості команд git!", "", "", "", @@ -859,7 +859,7 @@ exports.level = { "" ], "afterMarkdowns": [ - "Й в стані detached head", + "А в стані detached head:", "", "HEAD -> C1" ], @@ -873,7 +873,7 @@ exports.level = { "markdowns": [ "Щоб пройти цей рівень, давайте відокремимо голову від гілки `bugFix` й натомість спрямуємо її на якийсь коміт.", "", - "Вкажи цей коміт за його hash (хеш, ідентифікатором). Хеш кожного коміту відображений в кружочку що символізує коміт." + "Вкажи цей коміт за його hash (хеш, ідентифікатором). Хеш кожного коміту відображений в кружечку що символізує коміт." ] } } diff --git a/src/levels/rampup/interactiveRebase.js b/src/levels/rampup/interactiveRebase.js index bb70e488..810e307e 100644 --- a/src/levels/rampup/interactiveRebase.js +++ b/src/levels/rampup/interactiveRebase.js @@ -707,7 +707,7 @@ "", "Якщо додати цю опцію, git відкриє діалог в якому покаже які коміти будуть скопійовані до кінцевого призначення. Він також покаже хеші комітів та їхні повідомлення, що допоможе розібратися що й до чого.", "", - "В \"справжньому\" git, замість UI вікна відкриється файл в зконфігурованому текстовому редакторі, можливо `vim`. Для цього туторіалу я створив невеличке діалогове вікно що поводиться приблизно так само." + "В \"справжньому\" git, замість UI вікна відкриється файл в сконфігурованому текстовому редакторі, можливо `vim`. Для цього туторіалу я створив невеличке діалогове вікно що поводиться приблизно так само." ] } }, @@ -715,13 +715,13 @@ "type": "ModalAlert", "options": { "markdowns": [ - "Коли відкриється вікно інтерактивного rebase ти можеш зробити 3 речі:", + "Коли відкриється вікно інтерактивного rebase ти можеш зробити три речі:", "", "* Ти можеш переставити коміти між собою просто змінивши їх порядок в діалозі (в нашому вікні ти зможеш перетягнути їх мишкою).", "* Ти можеш повністю пропустити якісь коміти. В туторіалі потрібно вимкнути опцію `pick`, але в справжньому гіт потрібно просто видалити відповідний рядок.", - "* Також можна розчавити (squash) якісь коміти. На жаль наш туторіал не підтримує цю фічу (так як ми не підтримуєм роботу з файлами), але це дуже зручна опція в справжньому гіт. За допомогою неї можна декілька різніх комітів об’єднати в один", + "* Також можна розчавити (squash) якісь коміти. На жаль наш туторіал не підтримує цю фічу (так як ми не підтримуємо роботу з файлами), але це дуже зручна опція в справжньому гіт. За її допомогою можна декілька різніх комітів об’єднати в один", "", - "Чудово! Давайте розбиремо це на прикладі" + "Чудово! Давайте розберемо це на прикладі" ] } }, @@ -732,7 +732,7 @@ "Коли ти натиснеш кнопку відкриється вікно інтерактивного rebase. Перестав якісь коміти (можеш пропустити якісь якщо хочеш) і подивись що вийде!" ], "afterMarkdowns": [ - "Ка-бум! Git зкопіював коміти відповідно до того що було вказано в UI" + "Ка-бум! Git cкопіював коміти відповідно до того що було вказано в UI" ], "command": "git rebase -i HEAD~4 --aboveAll", "beforeCommand": "git commit; git commit; git commit; git commit" diff --git a/src/levels/rampup/relativeRefs.js b/src/levels/rampup/relativeRefs.js index a29f4c63..d00adb37 100644 --- a/src/levels/rampup/relativeRefs.js +++ b/src/levels/rampup/relativeRefs.js @@ -789,9 +789,9 @@ exports.level = { "", "Пересуватися по гіту використовуючи хеш комітів може бути трохи напряжно. В справжньому гіті в тебе не буде візуалізації дерева комітів в терміналі, тому доведеться використовувати `git log` щоб подивится хеші комітів.", "", - "Більше того, хеші як правило набагато довші в справньому гіті. Типовий хеш виглядає як `fed2da64c0efc5293610bdd892f82a58e8cbc5d8`. Без мнемонік не обійтися)...", + "Більше того, хеші як правило набагато довші в справжньому гіті. Типовий хеш виглядає як `fed2da64c0efc5293610bdd892f82a58e8cbc5d8`. Без мнемонік не обійтися)...", "", - "З іншого боку git дуже інтілігентсько працює з хешами. Він просить вказати рівно стільки літер, скільки потрібно щоб відрізнити один коміт від іншого. Отже, замість довгого хеша зверху можна просто набрати `fed2`." + "З іншого боку git дуже розумно працює з хешами. Він просить вказати рівно стільки літер, скільки потрібно щоб відрізнити один коміт від іншого. Отже, замість довгого хеша зверху можна просто набрати `fed2`." ] } }, diff --git a/src/levels/rampup/reversingChanges.js b/src/levels/rampup/reversingChanges.js index 4237d9bd..42bab58b 100644 --- a/src/levels/rampup/reversingChanges.js +++ b/src/levels/rampup/reversingChanges.js @@ -668,9 +668,9 @@ exports.level = { "markdowns": [ "## Відміна змін в Git", "", - "Є декілька шляхів відмини змін в Git. Й так само як і коміти, зміни в гіт можна відміняти використовуючи або низькорівневі методи (додавання в коміт окремих файлів) так і високорівневі. Ми зосередемось на останніх.", + "Є декілька шляхів відмини змін в Git. І так само як і коміти, зміни в гіт можна відміняти використовуючи або низькорівневі методи (додавання в коміт окремих файлів) так і високорівневі. Ми зосередемось на останніх.", "", - "Є два основні шляхи відмін змін в Git -- перший це використовувати `git reset` й інший це `git revert`. В наступному слайді ми подивимося на кожний з них", + "Є два основні шляхи відміни змін в Git -- перший це використовувати `git reset` й інший це `git revert`. В наступному слайді ми подивимося на кожний з них", "" ] } diff --git a/src/levels/rebase/manyRebases.js b/src/levels/rebase/manyRebases.js index 1bbc223f..ccbced70 100644 --- a/src/levels/rebase/manyRebases.js +++ b/src/levels/rebase/manyRebases.js @@ -224,9 +224,9 @@ exports.level = { "", "В нас тут до біса гілок! Давай перенесемо всі зміни з різних гілок в master.", "", - "Але вищостояще начальство нам не полегшує життя -- вони хочуть щоб всі коміти були по порядку. Це означає що в реузультаті коміт `C7'` має бути з самого низу, `C6'` трохи вище, і так далі, все по порядку.", + "Але вище керівництво нам не полегшує життя -- вони хочуть щоб всі коміти були по порядку. Це означає що в реузультаті коміт `C7'` має бути з самого низу, `C6'` трохи вище, і так далі, все по порядку.", "", - "Якщо ти щось зробиш не так, сміливо використовуй `reset` щоб почати спочатку. Подивись на наш розв’язок й подумай чи ти можеш обійтись меншою кількістю команд!" + "Якщо ти щось зробиш не так, сміливо використовуй `reset` щоб почати спочатку. Подивись на наш розв’язок і подумай чи ти можеш обійтись меншою кількістю команд!" ] } } diff --git a/src/levels/rebase/selectiveRebase.js b/src/levels/rebase/selectiveRebase.js index 3cb6d56b..1a494992 100644 --- a/src/levels/rebase/selectiveRebase.js +++ b/src/levels/rebase/selectiveRebase.js @@ -243,11 +243,11 @@ exports.level = { "", "Ооо Неля! Ну й завданнячко.", "", - "Ми маємо гілку `master` яка на кілька комітів попереду гілок `one` `two` та `three`. З незрозумілих причин, нам потрібно оновити ці гілки більш пізніми змінами з мастеру.", + "Ми маємо гілку `master`, яка на кілька комітів попереду гілок `one`, `two` та `three`. З незрозумілих причин, нам потрібно оновити ці гілки більш пізніми змінами з мастеру.", "", - "Гілку `one` портрібно відсортувати по порядоку й видалити `C5`. Гілку `two` потрібно відсортувати, а в гілку `three` потрібно додати ще один коміт!", + "Гілку `one` портрібно відсортувати по порядку і видалити `C5`. Гілку `two` потрібно відсортувати, а в гілку `three` потрібно додати ще один коміт!", "", - "Ми повністю покладаємось на тебе -- порівняй свій розв’зкок з нашим, який можна подивитись командою `show solution`. " + "Ми повністю покладаємось на тебе -- порівняй свій розв’зок з нашим, який можна подивитись командою `show solution`. " ] } } diff --git a/src/levels/remote/clone.js b/src/levels/remote/clone.js index 03672e0f..111c84f0 100644 --- a/src/levels/remote/clone.js +++ b/src/levels/remote/clone.js @@ -607,13 +607,13 @@ exports.level = { "", "Віддалені репозиторії не є дуже складними. В сучасному світі де на кожному кроці можна зустріти \"хмарні обчислення\" може видатися що концепція віддалених репозиторіїв є дуже складною, але насправді вони просто звичайні копії твого репозиторію на віддаленому комп’ютері. Зазвичай з цим віддаленим комп’ютером можна зв’язатися через інтернет, що дозволяє обмінюватись комітами.", "", - "Приймаючи до уваги все вищесказане, віддалені репозиторії мають купу гарних властивостей:", + "Приймаючи до уваги все сказане вище, віддалені репозиторії мають купу гарних властивостей:", "", - "- В першу чергу віддалені сервери це завжди чудова резевна копія (бекап)! Локальний репозиторій дає чудову можливість відкотитися до попереднього стану, але вся інформація зберігається локально. Маючи копії твого репозиторію на віддалених машинах, ти можеш пережити втрату жорсткого диску чи пошкодження данних і продовжити працювати з того місця на якому закінчив", + "- В першу чергу, віддалені сервери це завжди чудова резевна копія (бекап)! Локальний репозиторій дає можливість відкотитися до попереднього стану, але вся інформація зберігається локально. Маючи копії свого репозиторію на віддалених машинах, ти можеш пережити втрату жорсткого диску чи пошкодження данних і продовжити працювати з того місця на якому закінчив.", "", - "- Що не менш важливо, віддалені репозиториї роблять кодинг соціальним! Коли копія твого проекту розміщена в мережі, твої друзі мають змогу допомогти твому проекту (чи зпулити останні зміни) без зайвих зусиль.", + "- Що не менш важливо, віддалені репозиторії роблять програмування соціальним! Коли копія твого проекту розміщена в мережі, твої друзі мають змогу допомогти твоєму проекту (чи стягнути останні зміни) без зайвих зусиль.", "", - "Стало дуже популярним користуватися веб сайтами що візуалізують активність на віддалених репозиторіях. (наприклад [Github](https://github.com/) чи [Phabricator](http://phabricator.org/)), але віддалені репозиториї _завжди_ слугують як основа цих сервісів. Тому важливо розуміти їх!" + "Стало дуже популярним користуватися веб сайтами, що візуалізують активність на віддалених репозиторіях (наприклад [Github](https://github.com/) чи [Phabricator](http://phabricator.org/)), але віддалені репозиторії _завжди_ слугують як основа цих сервісів. Тому важливо розуміти їх!" ] } }, @@ -621,11 +621,11 @@ exports.level = { "type": "ModalAlert", "options": { "markdowns": [ - "## Команда що створює віддалені репозиториї", + "## Команда що створює віддалені репозиторії", "", "До цього моменту, Вчимо Git Гілкування концентрувало увагу на основах роботи з _локальним_ репозиторієм (гілкування, злиття гілок, ребейс, тощо). Однак тепер коли ми вчимо віддалені репозиторії, нам потрібно налаштувати середовище для подальших уроків. `git clone` впорається з цим завданням", "", - "В принципі, `git clone` в справжньому гіт це команда для створення _локальної_ копії віддаленого репозиторію (наприклад з github). Але в Вчимо Git Гілкування ми використовуватимо цю команду по іншому -- `git clone` буде створювати віддалений репозиторій з локального. Я згодний шо це трохи навпаки, але це допоможе створити зв’язок в голові між клонуванням та роботою з віддаленми репо, тому поки що будемо використовувати її таким чином.", + "В принципі, `git clone` в справжньому гіт це команда для створення _локальної_ копії віддаленого репозиторію (наприклад з github). Але у Вчимо Git Гілкування ми використовуватимо цю команду по іншому -- `git clone` буде створювати віддалений репозиторій з локального. Я згодний шо це трохи навпаки, але це допоможе створити зв’язок в голові між клонуванням та роботою з віддаленми репо, тому поки що будемо використовувати її таким чином.", "" ] } @@ -638,7 +638,7 @@ exports.level = { "" ], "afterMarkdowns": [ - "Ось і все! Тепер ми маємо віддалений репозиторій нашого проекту. Він виглядає досить схоже, хіба що деякі візуальні елементи інші щоб краще показати різницю -- в наступних рівнях ти навчишся як ділитися роботою між цими репозиторіями." + "Ось і все! Тепер ми маємо віддалений репозиторій нашого проекту. Він виглядає досить схоже, хіба що деякі візуальні елементи інші, щоб краще показати різницю -- в наступних рівнях ти навчишся ділитися роботою між цими репозиторіями." ], "command": "git clone", "beforeCommand": "" diff --git a/src/levels/remote/fakeTeamwork.js b/src/levels/remote/fakeTeamwork.js index 6d96c324..df3a816f 100644 --- a/src/levels/remote/fakeTeamwork.js +++ b/src/levels/remote/fakeTeamwork.js @@ -525,11 +525,11 @@ exports.level = { "markdowns": [ "## Симулюємо коллаборацію", "", - "Зараз ми знаходимось в незручному становищі -- в деяких з наступних уроків, нам потрібно пояснити як витягнути зміни з віддаленого репозиторія що були туди додані іншим учасником.", + "Зараз ми знаходимось в незручному становищі -- в деяких з наступних уроків, нам потрібно пояснити як витягнути зміни з віддаленого репозиторію, що були туди додані іншим учасником.", "", - "Це означає, що нам треба \"вдавати\" що віддалений репозиторій був модифікований твоїм колегою / друзями / небайдужими, іноді на специфічній гілці чи коміті.", + "Це означає, що нам треба \"вдавати\", що віддалений репозиторій був модифікований твоїм колегою / друзями / небайдужими, іноді на специфічній гілці чи коміті.", "", - "Щоб зробити це, ми додали влучно названу команду `git fakeTeamwork` (симуляціяКолективноїРоботи)! Насправді з симуляцією колективної роботи стикався майбуть кожен хто працював в колективі, тому перейдемо до прикладів..." + "Щоб зробити це, ми додали влучно названу команду `git fakeTeamwork` (симуляціяКолективноїРоботи)! Насправді, з симуляцією колективної роботи стикався мабуть кожен, хто працював в колективі, тому перейдемо до прикладів..." ] } }, @@ -537,10 +537,10 @@ exports.level = { "type": "GitDemonstrationView", "options": { "beforeMarkdowns": [ - "По замовчуванню `fakeTeamwork` просто додасть коміт в мастер" + "За замовчуванням `fakeTeamwork` просто додасть коміт в гілку `master`" ], "afterMarkdowns": [ - "Зробили -- до віддаленого репозиторію додався ще один коміт, проте ми ще його не завантажили, так як не виконали `git fetch`." + "Зробили -- до віддаленого репозиторію додався ще один коміт, проте ми ще його не завантажили, оскільки ще не виконали `git fetch`." ], "command": "git fakeTeamwork", "beforeCommand": "git clone" @@ -563,7 +563,7 @@ exports.level = { "type": "ModalAlert", "options": { "markdowns": [ - "Наступні рівні мають бути досить складними, тому щоб підготуватись, на цьому рівні теж доведеться не солодко.", + "Наступні рівні будуть доволі складними, тому, щоб підготуватись, на цьому рівні теж доведеться не солодко.", "", "Зроби віддалений репозиторій (за допомогою `git clone`), зроби кілька фіктивних змін, зроби кілька комітів локально, й підвантаж віддалені зміни. Це як кілька уроків в одному!" ] diff --git a/src/levels/remote/fetch.js b/src/levels/remote/fetch.js index c412f310..1ef42e26 100644 --- a/src/levels/remote/fetch.js +++ b/src/levels/remote/fetch.js @@ -692,11 +692,11 @@ exports.level = { "markdowns": [ "## Git Fetch", "", - "Робота з віддаленими гіт репозиторіями зводиться до передачі данних _до_ й _з_ інших репозиторіїв. Змога передавати коміти автоматично дає нам можливість передавати будь-яку інформацію що відслідковується гіт. (а отже виконану роботу, нові файли, ідеї, листи, тощо).", + "Робота з віддаленими гіт репозиторіями зводиться до передачі данних _до_ й _з_ інших репозиторіїв. Можливість передавати коміти дозволяє нам ділитися будь-якою інформацією, що відслідковується гіт (а отже виконаною роботою, новими файлами, ідеями, листами, тощо).", "", - "На цьому уроці ми навчимося витягати данні _з_ віддаленого репозиторію -- команда що відповідає за це зручно називається `git fetch` (fetch англ. витягнути чи дістати - примітка перекл.).", + "На цьому уроці ми навчимося витягати данні _з_ віддаленого репозиторію -- команда, що відповідає за це, зручно називається `git fetch` (fetch - англ. витягнути чи дістати).", "", - "Зауваж, що коли ми оновлюємо наш віддалений репозиторій, наші _віддалені_ гілки теж оновляться. Про це ми говорили в попередньому уроці." + "Зауваж, що коли ми оновлюємо наш віддалений репозиторій, наші _віддалені_ гілки теж оновляться. Про це ми говорили на попередньому уроці." ] } }, @@ -704,10 +704,10 @@ exports.level = { "type": "GitDemonstrationView", "options": { "beforeMarkdowns": [ - "Перед тим як почати розбиратися з `git fetch`, давай спробуємо його в дії! Тут ми маємо віддалений репозиторій який містить два коміти яких не має в нашому локальному сховищі." + "Перед тим, як почати розбиратися з `git fetch`, давай спробуємо його в дії! Тут ми маємо віддалений репозиторій який містить два коміти яких немає в нашому локальному сховищі." ], "afterMarkdowns": [ - "Ось, маєш! Коміти `C2` та `C3` було завантажено до нашого локального сховища, й наша віддалена гілка `o/master` була відповідно оновлена." + "Ось, маєш! Коміти `C2` та `C3` було завантажено до нашого локального сховища й наша віддалена гілка `o/master` була відповідно оновлена." ], "command": "git fetch", "beforeCommand": "git clone; git fakeTeamwork 2" @@ -719,16 +719,16 @@ exports.level = { "markdowns": [ "### Що робить fetch", "", - "`git fetch` виконує дві основні дії, й тільки дві дії.Він:", + "`git fetch` виконує дві основні дії, й тільки дві дії. Він:", "", - "* завантажує коміти які містить віддалене сховище але яких немає в локальному сховищі, та...", + "* завантажує коміти які містить віддалене сховище, але яких немає в локальному сховищі, та...", "* оновлює посилання віддаленого бранчу (наприклад, `o/master`)", "", "Якщо коротко `git fetch` приводить репрезентацію віддаленого репозиторію в локальному сховищі до _актуального_ стану справжнього віддаленого репозиторію.", "", - "Якщо ти пам’ятаєш з попереднього уроку, ми тоді зауважили що віддалені гілки відображають стан віддаленого репозиторію _від_ останнього разу коли ми синхронізувались з віддаленим репозиторієм. `git fetch` якраз і відповідає за синхронізацію з віддаленим сховищем! Сподіваюсь, що зв’язок між віддаленими гілками `git fetch` зараз є очевидним.", + "Якщо ти пам’ятаєш з попереднього уроку, ми тоді зауважили, що віддалені гілки відображають стан віддаленого репозиторію _від_ останнього разу коли ми синхронізувались з віддаленим репозиторієм. `git fetch` якраз і відповідає за синхронізацію з віддаленим сховищем! Сподіваюсь, що зв’язок між віддаленими гілками `git fetch` зараз є очевидним.", "", - "Як правило `git fetch` працює з віддаленими сховищами через інтернет. (через протоколи `http://` чи `git://`).", + "Як правило, `git fetch` працює з віддаленими сховищами через інтернет (через протоколи `http://` чи `git://`).", "" ] } @@ -737,13 +737,13 @@ exports.level = { "type": "ModalAlert", "options": { "markdowns": [ - "### Що не робить fetch", + "### Чого не робить fetch", "", - "Тим не менш `git fetch` нічого не змінює в _твоєму_ локальному стані. Він не оновить твою гілку`master` й не змінить те як наразі виглядає локальна файлова система.", + "Тим не менш, `git fetch` нічого не змінює в _твоєму_ локальному стані. Він не оновить твою гілку`master` і не змінить того, як наразі виглядає локальна файлова система.", "", - "Це важливо зрозуміти, тому що багато розробників думають що `git fetch` оновить їхні локальні данні до стану віддаленого репозиторію. Він дійсно завантажить всі потрібні данні, щоб це зробити, але він автоматично _не_ змінить ніяких локальних файлів. Ми вивчимо команди що це роблять в наступних уроках :D", + "Це важливо зрозуміти, тому, що багато розробників думають, що `git fetch` оновить їхні локальні данні до стану віддаленого репозиторію. Він дійсно завантажить всі потрібні данні, щоб це зробити, але він автоматично _не_ змінить ніяких локальних файлів. Ми вивчимо команди, які це роблять в наступних уроках :D", "", - "Отже в кінці кінців, ти можеш вважати що `git fetch` просто завантажує нову інформацію з віддаленого сховища." + "Отже, зрештою, ти можеш вважати що `git fetch` просто завантажує нову інформацію з віддаленого сховища." ] } }, @@ -751,7 +751,7 @@ exports.level = { "type": "ModalAlert", "options": { "markdowns": [ - "Щоб пройти цей рівень просто виконай `git fetch` й завантаж всі коміти!" + "Щоб пройти цей рівень просто виконай `git fetch` і завантаж всі коміти!" ] } } diff --git a/src/levels/remote/fetchRebase.js b/src/levels/remote/fetchRebase.js index 2969a542..60a3c63e 100644 --- a/src/levels/remote/fetchRebase.js +++ b/src/levels/remote/fetchRebase.js @@ -1324,9 +1324,9 @@ exports.level = { "markdowns": [ "## Diverged Work", "", - "Ми розглянули як `витягувати` коміти інших та як `завантажувати` свої власні коміти. Це виявилось не надто складно, як же так що в людей дуже часто виникають з цим труднощі?", + "Ми розглянули як витягувати (`pull`) коміти інших та як завантажувати (`push`) свої власні коміти. Це виявилось не надто складно, то як же так, що в людей дуже часто виникають з цим труднощі?", "", - "Основна складність полягає в тому що історія різних репозиториїв *розбігається* (diverges). Перед тим як вдатися в деталі, давайте подивимось як це виглядає на прикладі...", + "Основна складність полягає в тому що історія різних репозиторіїв *розбігається*. Перед тим як вдатися в деталі, давайте подивимось як це виглядає на прикладі...", "" ] } @@ -1335,9 +1335,9 @@ exports.level = { "type": "ModalAlert", "options": { "markdowns": [ - "Уяви що ти склонував репозиторій в Понеділок й почав напрацьовувати на якусь фічу. В пятницю фіча готова й ти хочеш повернути її назад (в апстрім) -- але що це? Твої колеги, грець їм, вже встигли вкомітити купу коду що робить твою фічу застарілою (і не дуже доречною). Вони вже запушили ці коміти в публічний репозиторій, й тепер *твоя* робота базується на *старій* версії продукту що вже не актуальна.", + "Уяви, що ти склонував репозиторій в понеділок і почав працювати над якоюсь фічею. В пятницю фіча готова і ти хочеш повернути її назад (в апстрім) -- але що це? Твої колеги, грець їм, вже встигли вкомітити купу коду що робить твою фічу застарілою (і не дуже доречною). Вони вже запушили ці коміти в публічний репозиторій, й тепер *твоя* робота базується на *старій* версії продукту, що вже не актуальна.", "", - "В цьому випадку команда `git push` неоднозначна. Коли ти виконаєш `git push`, гіт повинен змінити віддалений репозиторій до того стану, на якому він знаходився в Понеділок? Чи він має додати твій код й залишити код твоїх колег? Чи він має повністю проігнорувати твої зміни, так як вони застаріли?", + "В цьому випадку команда `git push` неоднозначна. Коли ти виконаєш `git push`, гіт повинен змінити віддалений репозиторій до того стану, на якому він знаходився в понеділок? Чи він має додати твій код і залишити код твоїх колег? Чи він має повністю проігнорувати твої зміни, оскільки вони застаріли?", "", "Через такі неоднозначності в цій ситуації (коли історія розійшлася), git не дозволить тобі запушити твої зміни. Він фактично змушує тебе інтегрувати останні зміни з віддаленого репозиторію перед тим як ти зможеш завантажити на нього свої напрацювання." ] @@ -1360,7 +1360,7 @@ exports.level = { "type": "ModalAlert", "options": { "markdowns": [ - "Як вийти з цієї ситуації? Це просто, все що треба, це оновити свої напрацювання так щоб вони базувалися на останніх змінах з віддаленої гілки.", + "Як вийти з цієї ситуації? Це просто, все що треба, -- це оновити свої напрацювання так, щоб вони базувалися на останніх змінах з віддаленої гілки.", "", "Є кілька шляхів як цього досягнути, але найпростіший це перемістити твою роботу 'вперед' за допомогою rebase. Давай спробуємо, й подивимось як це виглядає" ] @@ -1385,9 +1385,9 @@ exports.level = { "markdowns": [ "Чи є якийсь інший спосіб оновити свої напрацювання коли віддалений репозиторії пішов вперед? Звісно! Спробуємо зробити те ж саме, але натомість за допомогою `merge` (злиття).", "", - "Хоча `git merge` й не переміщує твою роботу (а просто створює натомість коміт злиття чи merge commit), це ще один спосіб сказати гіт що ти інтегрував останній стан віддаленого репозиторію в свої зміни. Це працює тому що тепер віддалена гілка є *предком* твоєї гілки, а отже твої останні коміти інтегрують в собі всі коміти з віддаленої гілки.", + "Хоча `git merge` і не переміщує твою роботу (а просто створює натомість коміт злиття чи merge commit), це ще[M#6 один спосіб сказати гіт що ти інтегрував останній стан віддаленого репозиторію в свої зміни. Це працює тому, що тепер віддалена гілка є *предком* твоєї гілки, а отже твої останні коміти інтегрують в собі всі коміти з віддаленої гілки.", "", - "Невелика демонстрація (шини не потрібні)..." + "Невелика демонстрація..." ] } }, @@ -1395,10 +1395,10 @@ exports.level = { "type": "GitDemonstrationView", "options": { "beforeMarkdowns": [ - "Тепер ми зробимо merge заміть rebase..." + "Тепер ми зробимо merge замість rebase..." ], "afterMarkdowns": [ - "Ка-бум! Ми оновили наш локальний образ віддаленої гілки за допомогою `git fetch`, *змерджили* нові напрацювання з власними напрацюваннями (щоб відобразити останні змінни в віддаленій гілці), й відіслали їх за допомогою `git push`" + "Ка-бум! Ми оновили наш локальний образ віддаленої гілки за допомогою `git fetch`, *змерджили* нові напрацювання з власними (щоб відобразити останні змінни в віддаленій гілці), й відіслали їх за допомогою `git push`" ], "command": "git fetch; git merge o/master; git push", "beforeCommand": "git clone; git fakeTeamwork; git commit" @@ -1408,9 +1408,9 @@ exports.level = { "type": "ModalAlert", "options": { "markdowns": [ - "Чудово! Чи я можу це зробити використовуючи меншу кількість команд?", + "Чудово! Чи можу я це зробити, використовуючи меншу кількість команд?", "", - "Звісно -- ти ж знаєш що `git pull` це просто коротша форма для git fetch а потім git merge. Достатньо зручно, `git pull --rebase` це коротка форма для git fetch а потім git rebase!", + "Звісно -- ти ж знаєш що `git pull` це просто коротша форма для git fetch а потім git merge. Доволі зручно, `git pull --rebase` це коротка форма для git fetch а потім git rebase!", "", "Давайте спробуємо використати ці коротші команди." ] @@ -1423,7 +1423,7 @@ exports.level = { "Спочатку з `--rebase`..." ], "afterMarkdowns": [ - "Теж саме що й раніше! Просто трохи коротше." + "Те саме, що й раніше! Просто трохи коротше." ], "command": "git pull --rebase; git push", "beforeCommand": "git clone; git fakeTeamwork; git commit" @@ -1433,7 +1433,7 @@ exports.level = { "type": "GitDemonstrationView", "options": { "beforeMarkdowns": [ - "Й тепер просто з `pull`" + "А тепер просто з `pull`" ], "afterMarkdowns": [ "Знову, так як і було!" @@ -1446,11 +1446,11 @@ exports.level = { "type": "ModalAlert", "options": { "markdowns": [ - "Робочий процес що складається з fetch, rebase/merge, й push є дуже широковживаним. В наступних уроках ми розглянемо складніші версії цього процесу, а наразі спробуємо його виконати.", + "Робочий процес, що складається з fetch, rebase/merge і push є дуже широковживаним. В наступних уроках ми розглянемо складніші версії цього процесу, а наразі спробуємо його виконати.", "", "Щоб пройти цей рівень виконай наступні кроки:", "", - "* Зклонуй свій репозиторій", + "* Склонуй свій репозиторій", "* Зроби симуляцію командної роботи (1 коміт)", "* Зроби власний коміт (1 коміт)", "* Опублікуй свої напрацювання за допомогою *rebasе*" diff --git a/src/levels/remote/pull.js b/src/levels/remote/pull.js index 236f52e1..1cac0859 100644 --- a/src/levels/remote/pull.js +++ b/src/levels/remote/pull.js @@ -570,14 +570,14 @@ exports.level = { "", "Тепер, коли ми знаємо як витягувати данні з віддаленого репозиторію за допомогою `git fetch`, давай спробуємо оновити нашу робочу копію відповідно до цих данних!", "", - "Насправді є кілька шляхів як це досягнути -- як тільки нові коміти з’явилися локально, ти можеш додавати їх в бранчі так само як звичайні коміти. Це означає що ти можеш виконувати команди:", + "Насправді, є кілька шляхів як цого досягнути -- як тільки нові коміти з’явилися локально, ти можеш додавати їх в бранчі так само, як звичайні коміти. Це означає що ти можеш виконувати команди:", "", "* `git cherry-pick o/master`", "* `git rebase o/master`", "* `git merge o/master`", - "* і так далі, й тому подібне.", + "* і так далі, і тому подібне.", "", - "Насправді, процес *витягування* віддалених змін й подальший *мерджинг* їх є настільки популярним, що гіт пропонує спеціяльну команду що виконує ці дві дії за один раз! Ця команда називається `git pull`." + "Насправді, процес *витягування* віддалених змін й подальший *мерджинг* їх є настільки популярним, що гіт пропонує спеціальну команду, що виконує ці дві дії за один раз! Ця команда називається `git pull`." ] } }, @@ -588,7 +588,7 @@ exports.level = { "Давай спочатку виконаємо по черзі `fetch` а потім `merge`" ], "afterMarkdowns": [ - "Ка-бум -- ми завантажили `C3` за допомогою `fetch` й потім змерджили їх з `git merge o/master`. Тепер наша гілка `master` відповідає гілці з віддаленого сховища (в цьому випадку, з назвою `origin`)" + "Ка-бум -- ми завантажили `C3` за допомогою `fetch` й потім змерджили їх використавши `git merge o/master`. Тепер наша гілка `master` відповідає гілці з віддаленого сховища (в цьому випадку, з назвою `origin`)" ], "command": "git fetch; git merge o/master", "beforeCommand": "git clone; git commit; git fakeTeamwork" @@ -598,10 +598,10 @@ exports.level = { "type": "GitDemonstrationView", "options": { "beforeMarkdowns": [ - "Що трапится якщо натомість використати `git pull` ?" + "Що трапится якщо натомість використати `git pull`?" ], "afterMarkdowns": [ - "Те ж саме! Тепер очевидно що `git pull` це просто швидкий спосіб зробити `git fetch` а потім змерджити завантажену гілку." + "Те саме! Тепер очевидно що `git pull` -- це просто швидкий спосіб зробити `git fetch` а потім змерджити завантажену гілку." ], "command": "git pull", "beforeCommand": "git clone; git commit; git fakeTeamwork" @@ -613,7 +613,7 @@ exports.level = { "markdowns": [ "Ми розглянемо `git pull` більш детально пізніше (включаючи різні опції та аргументи), наразі просто спробуємо цю команду.", "", - "Не забувай -- щоб пройти цей рівень достатньо використати `fetch` а потім `merge`, але це буде тобі коштувати одну зайву команду :P" + "Не забувай -- щоб пройти цей рівень, достатньо використати `fetch` а потім `merge`, але це буде тобі коштувати одну зайву команду :P" ] } } diff --git a/src/levels/remote/push.js b/src/levels/remote/push.js index de55be27..a7cd9334 100644 --- a/src/levels/remote/push.js +++ b/src/levels/remote/push.js @@ -416,13 +416,13 @@ exports.level = { "markdowns": [ "## Git Push", "", - "OK, я витягнув останні зміни й інтегрував їх в свої локальні напрацювання. Все добре... але як мені поділится _своїми_ змінами з рештою учасників?", + "OK, я витягнув останні зміни та інтегрував їх в свої локальні напрацювання. Все добре... але як мені поділится _своїми_ змінами з рештою учасників?", "", - "Отже, надсилання данних є по суті протилежне завантажуванню данних. Й який є антонім до `git pull` (притягнути)? `git push` (відштовхнути)!", + "Отже, надсилання данних є по суті протилежне завантажуванню данних. І який є антонім до `git pull` (притягнути)? `git push` (відштовхнути)!", "", - "`git push` використовується для надсилання _локальних_ змін на вказаний віддалений репозиторій й оновлює цей репозиторій, інтегруючи нові коміти. Після виконання `git push` всі твої друзі зможуть завантажити твої напрацювання з віддаленого сховища.", + "`git push` використовується для надсилання _локальних_ змін на вказаний віддалений репозиторій і оновлює цей репозиторій, інтегруючи нові коміти. Після виконання `git push` всі твої друзі зможуть завантажити твої напрацювання з віддаленого сховища.", "", - "Ти можеш вважати що `git push` \"публікує\" твої напрацювання. В цій команді є кілька тонких моментів, які ми скоро розглянемо, але давайте почнемо з початку...", + "Ти можеш вважати що `git push` \"публікує\" твої напрацювання. В цій команді є кілька особливостей, які ми скоро розглянемо, але давайте почнемо з початку...", "", "*зауваження -- поведінка `git push` без параметрів різниться в залежності від налаштування git з назвою `push.default`. Значення по замовчуванню цього налаштування залежить від версії твого git, але в наших уроках ми будемо вважати що воно рівне `upstream`. Це не вкрай важливо, але буде корисно перевірити це налаштування перед тим як пушити свій проект.*" ] @@ -435,7 +435,7 @@ exports.level = { "Ось ми маємо деякі зміни яких нема в віддаленому сховищі. Давайте надішлемо їх!" ], "afterMarkdowns": [ - "Ось, маєш -- віддалене сховище отримало `C2`, гілка`master` на ньому була оновлена й посилається на `C2`, й наше *власне* відображення віддаленого репо (`o/master`) було також оновлена. Все синхронізовано!" + "Ось, маєш -- віддалене сховище отримало `C2`, гілка`master` на ньому була оновлена й посилається на `C2`, й наше *власне* відображення віддаленого репо (`o/master`) було також оновлено. Все синхронізовано!" ], "command": "git push", "beforeCommand": "git clone; git commit" @@ -445,7 +445,7 @@ exports.level = { "type": "ModalAlert", "options": { "markdowns": [ - "Щоб пройти цей рівень, просто надішли два коміти у віддалений репозиторій. Але пристібнись, скоро наші уроки стануть набагато важчі!" + "Щоб пройти цей рівень, просто надішли два коміти у віддалений репозиторій. Але пристібнись, скоро наші уроки стануть набагато важчими!" ] } } diff --git a/src/levels/remote/remoteBranches.js b/src/levels/remote/remoteBranches.js index 5b653485..902ec642 100644 --- a/src/levels/remote/remoteBranches.js +++ b/src/levels/remote/remoteBranches.js @@ -647,13 +647,13 @@ exports.level = { "markdowns": [ "## Віддалені гілки", "", - "Тепер, коли ти познайомився з `git clone` в дії, давайте розглянемо деталі, й подивимось, що дійсно змінилось.", + "Тепер, коли ти познайомився з `git clone` в дії, давай розглянемо деталі й подивимось, що дійсно змінилося.", "", - "Перше що ти міг помітити, це те що з’явився новий бранч з назвою `o/master`. Такі гілки називаються _віддаленими_ (remote); віддалені гілки в гіт відіграють в певному сенсі унікальну роль, тому в них є деякі спеціяльні властивості, непритаманні іншим гілкам.", + "Перше, що ти міг помітити, це те, що з’явився новий бранч з назвою `o/master`. Такі гілки називаються _віддаленими_ (remote); віддалені гілки в гіт відіграють в певному сенсі унікальну роль, тому в них є деякі спеціальні властивості, непритаманні іншим гілкам.", "", "Віддалені гілки відображають _стан_ віддалених репозиториїв (точніше стан віддаленого репо на момент останньої синхронізації). Вони дозволяють відрізняти та відслідковувати локальні зміни та зміни інших учасників -- що є дуже важливим для успішної синхронізації роботи між різними репозиторіями.", "", - "Важливою властивістю віддалених гілок є те що коли перейти на них ти перейдеш в стан detached `HEAD`. Git робить це спеціяльно, так як неможливо працювати з ними напряму; ти маєш працювати в локальній гілці й по необхідності синхронізуватися з віддаленим репозиторієм (після чого віддалену гілку буде оновлено)." + "Важливою властивістю віддалених гілок є те, що коли перейти на них ти опинишся в стані detached `HEAD`. Git робить це спеціально, так як неможливо працювати з ними напряму; ти маєш працювати в локальній гілці й по необхідності синхронізуватися з віддаленим репозиторієм (після чого віддалену гілку буде оновлено)." ] } }, @@ -663,15 +663,15 @@ exports.level = { "markdowns": [ "### Що за `o/`? Або Римський салют", "", - "Ти можливо здогадуєшся для чого потрібен префікс `o/` на віддалених гілках. Так, є (примусове) правило іменування віддалених гілок -- вони відображаються в форматі:", + "Ти, можливо, здогадуєшся для чого потрібен префікс `o/` на віддалених гілках. Так, є (примусове) правило іменування віддалених гілок -- вони відображаються в форматі:", "", "* `<ім’я віддаленого репо>/<ім’я гілки>`", "", "Отже, якщо розглянути гілку з назвою `o/master`, то ім’я гілки це `master` а ім’я віддаленого репозиторію це `o`.", "", - "Більшість розробників насправді називають ім’я головного віддаленого репозиторію `origin` (початок), not `o`. Це настільки поширена практика, що гіт автоматично називає віддалений репозиторій `origin` коли ти його клонуєш.", + "Більшість розробників насправді називають ім’я головного віддаленого репозиторію `origin` (початок), а не `o`. Це настільки поширена практика, що гіт автоматично називає віддалений репозиторій `origin` коли ти його клонуєш.", "", - "На жаль повністю ім’я `origin` не влізає в наш UI, натомість ми будемо використовувати коротше `o` :( Просто не забудь, коли будеш використовувати звичайний гіт, що твій віддалений репо скоріш за все називається `origin`!", + "На жаль повністю ім’я `origin` не влазить в наш UI, натомість ми будемо використовувати коротше `o` :( Просто не забудь, коли будеш використовувати звичайний гіт, що твій віддалений репо скоріш за все називається `origin`!", "", "Це багато інформації, подивимось як це працює на прикладі." ] @@ -684,7 +684,7 @@ exports.level = { "Давайте зробимо checkout віддаленої гілки й подивимось що буде" ], "afterMarkdowns": [ - "Як бачиш, git перейшов в стан detached `HEAD` й не оновив `o/master` коли ми зробили новий коміт. Це тому, що `o/master` буде оновлено лише тоді коли буде оновлено віддалений репозиторій." + "Як бачиш, git перейшов в стан detached `HEAD` і не оновив `o/master` коли ми зробили новий коміт. Це тому, що `o/master` буде оновлено лише тоді коли буде оновлено віддалений репозиторій." ], "command": "git checkout o/master; git commit", "beforeCommand": "git clone" @@ -694,7 +694,7 @@ exports.level = { "type": "ModalAlert", "options": { "markdowns": [ - "Щоб пройти цей рівень, зроби один коміт в `master` а потім переключись в `o/master` й закомітся ще раз. Це наглядно продемонструє поведінку віддалених гілок, а також покаже як зміни впливають на стан віддаленого репозиторію." + "Щоб пройти цей рівень, зроби один коміт в `master`, а потім переключись в `o/master` і закомітся ще раз. Це наглядно продемонструє поведінку віддалених гілок, а також покаже як зміни впливають на стан віддаленого репозиторію." ] } }