From 09e228b45d5fbe25e9f202002ec2ede37a32a1fa Mon Sep 17 00:00:00 2001 From: Andriy Moroz Date: Tue, 5 Jul 2016 16:01:47 +0300 Subject: [PATCH] Convert DOS to UNIX line endings --- src/levels/mixed/jugglingCommits2.js | 1024 +++++++++++----------- src/levels/mixed/tags.js | 1210 +++++++++++++------------- 2 files changed, 1117 insertions(+), 1117 deletions(-) diff --git a/src/levels/mixed/jugglingCommits2.js b/src/levels/mixed/jugglingCommits2.js index 24a1f630..ce51ad11 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..2bb1c76a 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`.", + "", + "В наступному рівні ми розглянемо більш цікавий приклад роботи з тагами." + ] + } + } + ] + } + } +};