fixed some typos

src/levels/intro/commits.js

@@ -5,7 +5,7 @@ exports.level = {
     "es_AR": "Introducción a los commits de Git",
     "pt_BR": "Introdução aos commits no Git",
     "fr_FR": "Introduction aux commits avec Git",
-    "ja": "Gitのコミット",
+    "ja"   : "Gitのコミット",
     'ko': 'Git 커밋 소개',
     'zh_CN': 'Git Commits简介',
     'zh_TW': '介紹 git commit ',
@@ -22,7 +22,7 @@ exports.level = {
     "fr_FR": "Il suffit de saisir 'git commit' deux fois pour réussir !",
     "zh_CN": "敲两次 'git commit' 就好啦！",
     "zh_TW": "輸入兩次 'git commit' 就可以完成！",
-    "ja": "'git commit'コマンドを2回打てば完成!",
+    "ja"   : "'git commit'コマンドを2回打てば完成!",
     "ko": "'git commit'이라고 두 번 치세요!",
     "ru_RU": "Попробуй дважды выполнить команду 'git commit' ;)"
   },
@@ -121,7 +121,7 @@ exports.level = {
           "options": {
             "markdowns": [
               "## Gitのコミット",
-              "コミットによって、ディレクトリ中の全てのファイルのスナップショットを記録します。巨大なコピー＆ペーストのようなものですが、実はそれよりずっと良いものです。",
+              "コミットによって、ディレクトリ中の全てのファイルのスナップショットを記録します。巨大なコピー＆ペーストのようなものですが、実際にはそれよりずっと良いものです。",
               "",
               "Gitではコミットを可能な限り軽量に保つために、コミット毎にフォルダ全体をコピーしません。実際にはGitは、コミットを直前のバージョンから一つ先のバージョンへの「変更の固まり」あるいは「差分」として記録します。後で出てきますが、ほとんどのコミットが親を持っているのはそういう理由からです。",
               "",

src/levels/mixed/describe.js

@@ -476,7 +476,7 @@ exports.level = {
               "",
               "タグは、ソースリストの優秀な「アンカー（標識）」として作用するので、Gitには最も近く関係のある「アンカー」（タグの別名）を*記述するため*のコマンドがあります。そして、そのコマンドは`git describe`と呼ばれています！",
               "",
-              "Gitの`describe`は、あなたが大量のコミットの中を移動するとき、今どこにいるかを知るのを助けてくれます（これは、例えばあなたがデバッグ検索コマンドの一つ`git bisect`を終わった後や、同僚が休暇から帰ってきて自分の席に座るときに起こります）。"
+              "Gitの`describe`は、あなたが大量のコミットの中を移動するとき、今どこにいるかを知るのを助けてくれます（このような状況は、例えばあなたがデバッグ検索コマンドの一つ`git bisect`を走らせ終わった後や、同僚が休暇から帰ってきて自分の席に座るときに起こります）。"
             ]
           }
         },

src/levels/mixed/jugglingCommits2.js

@@ -264,7 +264,7 @@ exports.level = {
             "markdowns": [
               "## コミットをやりくりする その2",
               "",
-              "*注意 この一つ前のレベル「コミットをやりくりする」をクリアしていない人は、まずそちらの問題をクリアしてきてください*",
+              "*注：この一つ前のレベル「コミットをやりくりする」をクリアしていない人は、まずそちらの問題をクリアしてきてください！*",
               "",
               "前回見てきたように、コミット順序の変更のために、私たちは`rebase -i`コマンドを利用しました。ツリーの先頭に変更対象のコミットがあれば、--amendオプションを使うことで容易に変更を書きかえて、元の順序に戻すことができます。",
               "",

src/levels/rampup/cherryPick.js

@@ -434,9 +434,9 @@ exports.level = {
             "markdowns": [
               "## コードの移動",
               "",
-              "今まででは、gitの基本をひたすら見てきました -- コミット、ブランチ、そしてソースツリーの中でいろいろなポジションへのアクセスなどです。これらの概念だけで、gitリポジトリの力を90%使いこなすことができ、開発者の主なニーズを満たしています。",
+              "今まででは、gitの基本をひたすら見てきました -- コミットしたりブランチを派生したり、そしてソースツリーの中の色々な場所に移動することなどです。これらの概念だけで、gitリポジトリの力を90%使いこなすことができ、開発者の主な需要を満たしています。",
               "",
-              "しかし最後の10%はより複雑なワークフローやちょっとトラブった時にとても役に立つこともあります。これから取り上げる次の課題は「コードの移動」 –- つまり開発者が、「このコードをここに置き、そのコードをそこに置きたい」と言うときに、安易かつ具体的に利用できる方法を勉強します。",
+              "しかし最後の10%はより複雑なワークフローやちょっとトラブった時にとても役にたちます。これから取り上げる次の課題は「作業内容の移動」 –- 詳しく言えば、「この作業はここに置き、その作業はそこに置きたい」と言う開発者のために、優しく具体的で正確にその方法をお教えしましょう。",
               "",
               "ちょっと複雑に聞こえるかもしれませんが、概念は簡単です。"
             ]
@@ -448,11 +448,11 @@ exports.level = {
             "markdowns": [
               "## Git Cherry-pick",
               "",
-              "このシリーズの一つ目のコマンドは、`git cherry-pick`。次の形になります:",
+              "このシリーズの一つ目のコマンドは、`git cherry-pick`。このコマンドの使い方は、次の形になります:",
               "",
               "* `git cherry-pick <Commit1> <Commit2> <...>`",
               "",
-              "現在の位置(`HEAD`)より下の一連のコミットをコピーしたいという意を単純に表す方法です。分かりにくいところが少ないので、個人的に私がとても好きなコマンドです。",
+              "現在の位置(`HEAD`)の下に一連のコミットをコピーしたいという意を単純に表す方法です。分かりにくいところが少ないので、個人的に私がとても好きなコマンドです。",
               "",
               "デモを見ていきましょう!",
               ""

src/levels/rampup/detachedHead.js

@@ -615,7 +615,7 @@ exports.level = {
             "beforeMarkdowns": [
               "### HEADの分離",
               "",
-              "HEADの分離とは単に、ブランチではなく特定のコミットにHEADを紐づけることです。実行前の状態は次のようです:",
+              "HEADの分離(detached HEAD)とは単に、ブランチではなく特定のコミットにHEADを紐づけることです。実行前の状態は次のようです:",
               "",
               "HEAD -> master -> C1",
               ""

src/levels/rampup/interactiveRebase.js

@@ -492,9 +492,9 @@ exports.level = {
             "markdowns": [
               "## Git インタラクティブrebase",
               "",
-              "どのコミットを操りたいか（そしてそれを指定するハッシュ）がわかる時にGit cherry-pickはとても便利で、その簡単さはとてもありがたいです。 ",
+              "どのコミットを操りたいか（そしてそれを指定するハッシュ）がわかる時に`git cherry-pick`はとても便利で、その簡単さはとてもありがたいです。 ",
               "",
-              "しかし、どのコミットを操りたいかがわからない時はどうでしょう？ありがたいことに、そんな時にぴったりのコマンドがgitにその備わっています。このためにgitのインタラクティブrebaseを使えます。rebaseしたい一連のコミットを一括で見るベストな方法です。",
+              "しかし、どのコミットを操りたいかがわからない時はどうでしょう？ありがたいことに、そんな時にぴったりのコマンドがgitに備わっています。このためにgitのインタラクティブrebaseを使えます。rebaseしたい一連のコミットを一括で見るベストな方法です。",
               "",
               "具体的に見てみましょう..."
             ]

src/levels/rampup/relativeRefs.js

@@ -619,7 +619,7 @@ exports.level = {
             "markdowns": [
               "このレベルをクリアするには、`bugFix`の親コミットをチェックアウトしてください。その操作により`HEAD`が分離されます。",
               "",
-              "ハッシュを使用してもいいですが、その代わりに相対リファレンスをトライしてみましょう！"
+              "ハッシュを使用してもいいですが、その代わりに相対リファレンスを試してみましょう！"
             ]
           }
         }

src/levels/rampup/reversingChanges.js

@@ -290,7 +290,7 @@ exports.level = {
               "",
               "Gitでは変更を元に戻す方法がたくさんあります。コミットと同じように、低レベルな動作（ファイル別だったりファイルの中の一部だったり）も高レベルな動作（変更のまとまりのキャンセル）もできます。このアプリケーションでは後者の方法について紹介します。",
               "",
-              "基本的なアンドゥの方法が2つあります -- 一つは`git reset`を使う方法で、もう1つは`git revert`を使う方法です。次のダイアログで一つ一つを見ていきます。",
+              "基本的な巻き戻しの方法は2つあります -- 一つは`git reset`を使う方法で、もう1つは`git revert`を使う方法です。次のダイアログで一つ一つを見ていきます。",
               ""
             ]
           }

src/levels/rebase/manyRebases.js

@@ -134,7 +134,7 @@ exports.level = {
               "",
               "おエライさん方が今回の仕事を少しトリッキーにしてくれました -- コミットはすべて一列の連続した状態にしてほしいそうです。つまり私たちが作るリポジトリの最終的なツリーの状態は、`C7'`が最後に来て、`C6'`がその一つ上に来て、、と順に積み重なるイメージです。",
               "",
-              "試行錯誤してツリーが汚くなってきたら、`reset`コマンドを使ってツリーの状態を初期化してください。模範解答をチェックして、それよりも簡単なコマンドで済ませられるかどうか、を考えるのも忘れずに！"
+              "試行錯誤してツリーが汚くなってきたら、`reset`コマンドを使ってツリーの状態を初期化してください。模範解答をチェックして、それよりも簡単なコマンドで済ませられるかどうかを考えるのも忘れずに！"
             ]
           }
         }

src/levels/remote/fakeTeamwork.js

@@ -471,7 +471,7 @@ exports.level = {
               "",
               "これを行うために、私たちは適切に選んだ名前のコマンド`git fakeTeamwork`を導入しました！とても明白でしょう？では、デモを見てみましょう。",
               "",
-              "*Note: もちろん、本当のgit上にこのようなコマンドは存在しません！変更は、「実在する」同僚や友人が行ってくれるでしょうから！ここではレッスンのために「擬似的に」導入しているにすぎません！*"
+              "*注：もちろん、本当のgit上にこのようなコマンドは存在しません！変更は、「実在する」同僚や友人が行ってくれるでしょうから！ここではレッスンのために「擬似的に」導入しているにすぎません！*"
             ]
           }
         },

src/levels/remote/fetch.js

@@ -576,7 +576,7 @@ exports.level = {
               "",
               "`git fetch`は本質的には、_実際_のリモートリポジトリと同じように見えるような形でリモートリポジトリの_ローカル_の情報に同期します（ちょうど今のように）。",
               "",
-              "あなたは前のレッスンでのことを覚えていると思いますが、リモートブランチはリモートリポジトリと最後に同期した時での状態を保持しているという話をしました。`git fetch`はそのリモートと同期する方法なのです！これでリモートブランチと`git fetch`の関係性は明らかになったでしょう？",
+              "前のレッスンでのことを覚えていると思いますが、リモートブランチはリモートと最後に同期した時点での状態を保持しているという話をしました。`git fetch`はそのリモートと同期する方法なのです！これでリモートブランチと`git fetch`の関係性は明らかになったでしょう？",
               "",
               "`git fetch`は、通常インターネットを通してリモートリポジトリと対話します（`http://`または`git://`プロトコル経由で）。",
               ""
@@ -591,7 +591,7 @@ exports.level = {
               "",
               "`git fetch`は、しかしながら、_あなたの_ローカルの状態は変更しません。あなたの`master`ブランチや他のもの、今現在のあなたのファイルシステムが見せているものを更新しないのです。",
               "",
-              "これは理解する上で重要なことです。なぜなら、多くの技術者は`git fetch`がリモートの状態をローカルの作業場に反映してくれると思っているからです。必要なデータはダウンロードされるかもしれませんが、ローカルのファイルを実際に変更するというようなことは_してくれない_のです。私たちは、この後のレッスンでもこのようなコマンドを学びます:D",
+              "これは理解する上で重要なことです。なぜなら、多くの技術者は`git fetch`がリモートの状態をローカルの作業場に反映してくれると思っているからです。必要なデータはダウンロードされるかもしれませんが、ローカルのファイルを実際に変更するというようなことは_してくれない_のです。私たちは、この後のレッスンでもこのようなコマンドを学びます :D",
               "",
               "なので、この1日が終わる頃には、あなたは`git fetch`のダウンロードステップの動作が分かるようになるでしょう。"
             ]

src/levels/remote/mergeManyFeatures.js

@@ -358,7 +358,7 @@ exports.level = {
           "type": "ModalAlert",
           "options": {
             "markdowns": [
-              "開発コミュニティで、マージとリベースの間でのトレードオフについては多くの議論がなされています。ここでは一般的なレベースのメリット/デメリットを紹介しましょう:",
+              "開発コミュニティで、マージとリベースの間でのトレードオフについては多くの議論がなされています。ここでは一般的なリベースのメリット/デメリットを紹介しましょう:",
               "",
               "メリット:",
               "",
@@ -368,7 +368,7 @@ exports.level = {
               "",
               "* リベースは、コミットツリーの（見ため上の）履歴を改変してしまいます。",
               "",
-              "例えば、`C1`コミットは*過去*の`C3`コミットをリベースすることができます。それは、実際には前に完了しているのにもかかわらず、`C1'`の作業がまるで`C3`の後に行われたものであるかのように見えるようになります。",
+              "例えば、`C1`コミットは*過去*の`C3`コミットにリベースすることができます。それは、実際には前に完了しているのにもかかわらず、`C1'`の作業がまるで`C3`の後に行われたものであるかのように見えるようになります。",
               "",
               "幾人かの開発者は、履歴をそのまま保持するのが好みで、マージを選択します。その他（例えば私は）きれいなコミットツリーを好むのでリベースを選択します。つまるところ、好みの問題というわけですね :D"
             ]

src/levels/remote/push.js

@@ -377,7 +377,7 @@ exports.level = {
               "",
               "`git push`は、あなたの作業を「公開する」コマンドと考えることができます。このコマンドは微妙な点をいくつか持っていますが、とりあえずは初歩から始めてみましょう。。。",
               "",
-              "*Note : 引数なしの`git push`の挙動は、`push.default`と呼ばれるgitの設定値によって異なります。この設定のデフォルト値は、使用しているgitのバージョンに依存しますが、私たちのレッスンでは`upstream`という値を使用します。これはあまり大きな問題ではありませんが、あなたのプロジェクトにプッシュする前にあなたのgitの設定を確認する価値はあるでしょう。*"
+              "*注：引数なしの`git push`の挙動は、`push.default`と呼ばれるgitの設定値によって異なります。この設定のデフォルト値は、使用しているgitのバージョンに依存しますが、私たちのレッスンでは`upstream`という値を使用します。これはあまり大きな問題ではありませんが、あなたのプロジェクトにプッシュする前にあなたのgitの設定を確認する価値はあるでしょう。*"
             ]
           }
         },