Added ru_RU (Russian) translation for the "mergeManyFeatures.js". Fixed typos.

src/levels/remote/mergeManyFeatures.js

@@ -338,6 +338,51 @@ exports.level = {
           }
         }
       ]
+    },
+    "ru_RU": {
+      "childViews": [
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "## Merge? Нет, нет, спасибо.",
+              "",
+              "Чтобы закачать (push) новые изменения в удалённый репозиторий, всё что Вам нужно сделать - это *смешать* последние изменения из удалённого репозитория. Это значит что Вы можете выполнить rebase *или* merge на удалённом репозитории (например, `o/master`).",
+              "",
+              "Если мы можем воспользоваться одним из двух методов, то почему же эти упражнения сфокусированы в основном на rebase? К чему такая нелюбовь к `merge`, когда речь идёт о работе с удалённым репозиториями?",
+              ""
+            ]
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "В среде разработчиков существует огромное количество дебатов около merging и rebasing. Ниже приведены основные за / против метода rebasing:",
+              "",
+              "За:",
+              "",
+              "* Rebasing делает дерево коммитов более чистым, читабельным потому что всё представляется единой прямой линией.",
+              "",
+              "Против:",
+              "",
+              "* Метод rebasing явно изменяет историю коммитов в дереве.",
+              "",
+              "Например, коммит `C1` может быть перебазирован *после* `C3`. Соответственно, в дереве работа над `C1'` будет отображатся как идущая после `C3`, хотя на самом деле она была выполнена раньше.",
+              "",
+              "Некоторые разработчики любят сохранять историю и, таким образом, предпочитают слияние (merging). Другие (такие как я) предпочитают иметь чистое дерево коммитов, и пользуются перебазировкой (rebasing). Всё зависит от Ваших предпочтений и вкусов :D"
+            ]
+          }
+        },
+        {
+          "type": "ModalAlert",
+          "options": {
+            "markdowns": [
+              "Для этого уровня, давайте решим предыдущие задачи но с помощью *слияния (merging)*. Может быть поулчится слегка неказисто, однако такое упражнение хорошо отразит суть различий."
+            ]
+          }
+        }
+      ]
     }
   }
 };

src/levels/remote/pushManyFeatures.js

@@ -407,7 +407,7 @@ exports.level = {
               "",
               "Теперь, когда Вы умело владеете коммандами fetch, pull и push давайте применим эти навыки в сочетании с новым рабочим процессом (он же workflow).",
               "",
-              "Для разработчиков, вовлечённых в большой проект, является довольно распространённым выполнять всё свою работу на так называемых фича-бранчах (вне `master`). А затем, как только работа выполнена, разработчик интегрирует всё что было им сделано. Всё это, за исключением одного шага, довольно похоже на предыдущий урок (там, где мы закачивали ветки на удалённый репозиторий)",
+              "Для разработчиков, вовлечённых в большой проект, является довольно распространённым выполнять всю свою работу в так называемых фича-бранчах (вне `master`). А затем, как только работа выполнена, разработчик интегрирует всё что было им сделано. Всё это, за исключением одного шага, довольно похоже на предыдущий урок (там, где мы закачивали ветки на удалённый репозиторий)",
               "",
               "Ряд разработчиков делают push и pull лишь на локальную ветку `master` -- таким образом ветка `master` всегда обновлена с тем, что находится на удалённом репозитории (`o/master`).",
               "",