diff --git a/src/levels/remote/mergeManyFeatures.js b/src/levels/remote/mergeManyFeatures.js index 96dce5d5..210a19bd 100644 --- a/src/levels/remote/mergeManyFeatures.js +++ b/src/levels/remote/mergeManyFeatures.js @@ -11,7 +11,8 @@ exports.level = { "de_DE": "Änderungen vom Remote zusammenführen", "ja" : "リモートとのmerge", "fr_FR": "Fusionner avec les branches distantes", - "ru_RU": "Слияние с удалённым репозиторием" + "ru_RU": "Слияние с удалённым репозиторием", + "ko" : "원격 작업과 merge하기" }, "hint": { "en_US": "Pay attention to the goal tree!", @@ -22,7 +23,8 @@ exports.level = { "de_DE": "Beachte den Ziel-Baum!", "ja" : "ゴールツリーをよく見てください!", "fr_FR": "Respectez l'arbre représentant l'objectif !", - "ru_RU": "Внимательно посмотрите на цель уровня!" + "ru_RU": "Внимательно посмотрите на цель уровня!", + "ko" : "goal을 잘 살펴보세요!" }, "compareOnlyMaster": true, "startDialog": { @@ -430,6 +432,51 @@ exports.level = { } } ] + }, + "ko": { + "childViews": [ + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "## 왜 merge하지 않는거죠?", + "", + "새로운 작업들을 원격 저장소로 push하기위해서 여러분은 원격 저장소의 최근 변경들을 *합치기*만 하면 됩니다. 이 말은 즉 원격 브랜치로(예:`o/master`) rebase를 할 수도 merge를 할 수도 있다는 것입니다.", + "", + "두가지를 다 할 수 있다면, 왜 지금까지 배운 레슨들은 rebase를 하는것에 집중한거죠? 원격 저장소와 작업을 할때는 왜 `merge`에게 관심을 가져주지 않는건가요?", + "" + ] + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "개발 커뮤니티에서 merge를 하는것과 rebase 사이의 트레이드 오프에 대해 많은 논의가 이루어지고 있습니다. 여기 rebase의 일반적인 장 / 단점을 소개하겠습니다:", + "", + "장점:", + "", + "* rebase는 여러분의 커밋 트리를 깔끔하게 정리해서 보기가 좋습니다 모든게 한 줄에 있기때문이죠.", + "", + "단점:", + "", + "* rebase를 하게 되면 커밋 트리의 (보이는)히스토리를 수정합니다.", + "", + "예를 들어, 커밋 `C1`는 *과거*의`C3`로 rebase 될 수 있습니다. `C1'`의 작업이 `C3`의 다음에 있는것으로 보이게 되는겁니다. 실제로는 `C1`이 먼저 완료된거인데 말이죠.", + "", + "어떤 개발자들은 이력이 보존되는것을 좋아하기 때문에 merge를 선호합니다. 그 이외는(저 처럼) 커밋 트리가 깔끔한것을 선호해서 rebase를 선호합니다. 자기 입맛에 맞추면 되겠습니다 :D" + ] + } + }, + { + "type": "ModalAlert", + "options": { + "markdowns": [ + "이번 레벨에서는 이전의 레벨을 해결 해봅시다. 대신 이번에는 *merge*를 사용하겠습니다. 조금 복잡할 수 있지만 지금 배운 내용의 포인트를 파악하기 좋을것 입니다." + ] + } + } + ] } } };