mirror/pcottle.learnGitBranching
1
0
Fork 0
mirror of https://github.com/pcottle/learnGitBranching.git synced 2025-08-02 00:54:40 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

Merge pull request #298 from mizunashi-mana/mzJPTranslate4

Browse source 
fix japanese typos and add ja contents
This commit is contained in:
Peter Cottle 2015-06-22 10:29:34 -07:00
commit e71a89e450
19 changed files with 138 additions and 37 deletions
Download patch file Download diff file Expand all files Collapse all files

2
src/js/dialogs/sandbox.js
View file

@ -237,6 +237,8 @@ exports.dialog = {
'',
'何か詰まったことがあったら、右下メニューの?ボタンを押してみてください',
'',
'それから、不自然な記号が出てきたときは顔を左方向に傾けてみるといいかもしれません :P（ペロッ）',
'',
'それでは教材の選択画面に進んでみることにします。',
'',
'（なお、日本語版製作者のフォークサイトは[こちら](http://remore.github.io/learnGitBranching-ja/)になります。）'

6
src/levels/intro/commits.js
View file

@ -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は、コミットを直前のバージョンから一つ先のバージョンへの「変更の固まり」あるいは「差分」として記録します。後で出てきますが、ほとんどのコミットが親を持っているのはそういう理由からです。",
"",

2
src/levels/intro/rebasing.js
View file

@ -190,7 +190,7 @@ exports.level = {
"`git rebase`コマンドでそれをやってみましょう。"
],
"afterMarkdowns": [
"できた！これでbugFixブランチの作業内容はmasterブランチのすぐ先に移動したので、見た目が一本になってスッキリしました。",
"できました！これでbugFixブランチの作業内容はmasterブランチのすぐ先に移動したので、見た目が一本になってスッキリしました。",
"",
"気を付けてほしいのは、C3コミットはどこかに残ってるということ（ツリーの中で半透明にしてあります）、そしてC3'は（C1との接続が切れているC3の）コピーがmasterブランチ上に作られているということです。",
"",

2
src/levels/mixed/describe.js
View file

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

2
src/levels/mixed/jugglingCommits2.js
View file

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

14
src/levels/rampup/cherryPick.js
View file

@ -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`)の下に一連のコミットをコピーしたいという意を単純に表す方法です。分かりにくいところが少ないので、個人的に私がとても好きなコマンドです。",
"",
"デモを見ていきましょう!",
""
@ -463,10 +463,10 @@ exports.level = {
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"このリポジトリには、現在`side`ブランチから`master`にコピーしたいコードがあります。この前学んできたrebaseコマンドでは実現可能ですが、cherry-pickの動作を見ていきましょう。"
"このリポジトリには、現在`side`ブランチから`master`にコピーしたいコードがあります。この前に学んだrebaseコマンドでも実現可能ですが、ここではcherry-pickの動作を見ていきましょう。"
],
"afterMarkdowns": [
"それだけで終わりです! コミット`C2` と `C4`を取得したかったーそしてgitが現在の位置の直下に落としました。単純ですね!"
"これだけで終わりです！コミット`C2` と `C4`を取得したかったわけですが、gitが現在の位置の直下に落としてくれました。単純ですね！"
],
"command": "git cherry-pick C2 C4",
"beforeCommand": "git checkout -b side; git commit; git commit; git commit; git checkout master; git commit;"
@ -476,7 +476,7 @@ exports.level = {
"type": "ModalAlert",
"options": {
"markdowns": [
"このレベルをクリアするには、３つのブランチからmasterにコードをコピーしてください。どのコミットを取得するかについてはゴールのビジュアライズをみてください。",
"このレベルをクリアするには、３つのブランチからmasterにコードをコピーしてください。どのコミットを取得するかについてはゴールのツリーをみてください。",
""
]
}

2
src/levels/rampup/detachedHead.js
View file

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

9
src/levels/rampup/interactiveRebase.js
View file

@ -14,7 +14,8 @@ exports.level = {
"fr_FR": "Vous pouvez utiliser soit les branches, soit les références relatives (HEAD~) pour spéficier la cible à rebaser",
"zh_CN": "你可以使用 branch 或者是相对位置（HEAD~）來指定 rebase 的目标",
"zh_TW": "你可以指定 branch 或者是相對位置（HEAD~）來表示 rebase 的目標",
"ru_RU": "Можно использовать либо ветки, либо относительные ссылки (HEAD~), чтобы указать цель для Rebase"
"ru_RU": "Можно использовать либо ветки, либо относительные ссылки (HEAD~), чтобы указать цель для Rebase",
"ja" : "リベースする対象の指定には、ブランチ名や相対リファレンス(HEAD~)が使えます"
},
"name": {
"en_US": "Interactive Rebase Intro",
@ -491,9 +492,9 @@ exports.level = {
"markdowns": [
"## Git インタラクティブrebase",
"",
"どのコミットを操りたいか（そしてそれを指定するハッシュ）がわかる時にGit cherry-pickはとても便利で、その簡単さはとてもありがたいです。 ",
"どのコミットを操りたいか（そしてそれを指定するハッシュ）がわかる時に`git cherry-pick`はとても便利で、その簡単さはとてもありがたいです。 ",
"",
"しかし、どのコミットを操りたいかがわからない時はどうでしょう？ありがたいことに、そんな時にぴったりのコマンドがgitにその備わっています。このためにgitのインタラクティブrebaseを使えます。rebaseしたい一連のコミットを一括で見るベストな方法です。",
"しかし、どのコミットを操りたいかがわからない時はどうでしょう？ありがたいことに、そんな時にぴったりのコマンドがgitに備わっています。このためにgitのインタラクティブrebaseを使えます。rebaseしたい一連のコミットを一括で見るベストな方法です。",
"",
"具体的に見てみましょう..."
]
@ -519,7 +520,7 @@ exports.level = {
"",
"* UIウィンドウのなかで順番を調整するだけでコミットの順番を変えられます（こちらのダイアログでは、マウスでドラッグアンドドロップで操作します）。",
"* 特定のコミットを丸ごと除くこともできます。除きたいコミットを指定するには`pick`をオフにします。",
"* 最後に、コミットを組み合わせられます。技術的に制限があるため、あいにくこちらのレベルには出てきませんがのでその詳細の説明を省きますが、短く言いますと、複数のコミットを一つにまとめることができる機能です。",
"* 最後に、コミットを組み合わせられます。技術的に制限があり再現できないのでその詳細な説明を省きますが、短く言いますと、複数のコミットを一つにまとめることができる機能です。",
"",
"さて、例を見てみましょう。"
]

2
src/levels/rampup/relativeRefs.js
View file

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

2
src/levels/rampup/reversingChanges.js
View file

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

8
src/levels/rebase/manyRebases.js
View file

@ -14,7 +14,7 @@ exports.level = {
"pt_BR": "Fazendo mais de 9000 rebases",
"fr_FR": "Rebaser plus de 1000 fois",
"ko": "9천번이 넘는 리베이스",
"ja": "9000回以上のrebase",
"ja" : "9000回以上のrebase",
"zh_CN": "N次Rebase",
"zh_TW": "N次Rebase",
"ru_RU": "Rebase over 9000 раз"
@ -25,7 +25,7 @@ exports.level = {
"es_AR": "Acordate, la manera más eficiente podría ser actualizar master sólo al final...",
"pt_BR": "Lembre-se, a forma mais eficiente pode ser atualizar o master por último...",
"fr_FR": "Rappelez-vous, la façon la plus efficace peut être de mettre à jour master seulement à la fin ...",
"ja": "最も効率的なやり方はmasterを最後に更新するだけかもしれない・・・",
"ja" : "最も効率的なやり方はmasterを最後に更新するだけかもしれない・・・",
"ko": "아마도 master를 마지막에 업데이트하는 것이 가장 효율적인 방법일 것입니다...",
"zh_CN": "记住，最后更新master分支可能是最高效的方法。",
"zh_TW": "要記住喔! 把 master branch 留到最後更新可能是最有效率的方法。",
@ -132,9 +132,9 @@ exports.level = {
"",
"さあ、いくつものブランチが出てきます。このブランチたち全てをmasterブランチにリベースしましょう。",
"",
"おエライさん方が今回の仕事を少しトリッキーにしてくれました -― コミットはすべて一列のシーケンシャルな状態にしてほしいそうです。つまり私たちが作るリポジトリの最終的なツリーの状態は、`C7'`が最後に来て、`C6'`がその一つ上に来て、、と順に積み重なるイメージです。",
"おエライさん方が今回の仕事を少しトリッキーにしてくれました -- コミットはすべて一列の連続した状態にしてほしいそうです。つまり私たちが作るリポジトリの最終的なツリーの状態は、`C7'`が最後に来て、`C6'`がその一つ上に来て、、と順に積み重なるイメージです。",
"",
"試行錯誤してツリーが汚くなってきたら、`reset`コマンドを使ってツリーの状態を初期化してください。模範解答をチェックして、それよりも簡単なコマンドで済ませられるかどうか、を考えるのも忘れずに！"
"試行錯誤してツリーが汚くなってきたら、`reset`コマンドを使ってツリーの状態を初期化してください。模範解答をチェックして、それよりも簡単なコマンドで済ませられるかどうかを考えるのも忘れずに！"
]
}
}

8
src/levels/remote/clone.js
View file

@ -430,13 +430,13 @@ exports.level = {
"markdowns": [
"## Gitリモート",
"",
"リモートのリポジトリというのはそんなに複雑なものでもありません。クラウドコンピューティングが普及している現在の世界では、gitリモートの裏には何か不思議な仕組みが動いていると思いやすいのですが、実は別のコンピューター上に保存されているあなたのリポジトリのコピーにすぎません。普通の場合では、インターネットを媒体に使いこの別のコンピューターと対話し、コミットを交互にやり取りすることができます。",
"リモートのリポジトリというのはそんなに複雑なものでもありません。クラウドコンピューティングが普及している現在の世界では、gitリモートの裏には何か不思議な仕組みが動いていると思いやすいのですが、実は別のコンピュータ上に保存されているあなたのリポジトリのコピーにすぎません。通常、インターネットを媒体に使って別のコンピュータと対話し、コミットを交互にやり取りすることができます。",
"",
"とはいえ、リモートリポジトリにはいくつかの素晴らしい特徴があります:",
"",
"- まず、リモートはバックアップの役割を果たします。ご存知の通り、ローカルのgitリポジトリは以前の状態にファイルを復帰する機能を持っているのですが、その情報はすべてローカルに保存されています。gitリポジトリを別のコンピューターにも保存することで、ローカルのデーターがすべて失われたとしても、保存状態からコーディングを続けられます。",
"- まず、リモートはバックアップの役割を果たします。ご存知の通り、ローカルのgitリポジトリは以前の状態にファイルを復帰する機能を持っているのですが、その情報はすべてローカルに保存されています。gitリポジトリを別のコンピュータにも保存することで、ローカルのデータがすべて失われたとしても、保存状態からコーディングを続けられます。",
"",
"- それよりも大切なこととして、リモートではコードをより一般的に公開できます!プロジェクトのコピーが別の場所に保存されているため、友達などが簡単にそのプロジェクトに参加したり最近の変更をpullしたりできます。",
"- それよりも大切なこととして、リモートではコードをより一般的に公開できます！プロジェクトのコピーが別の場所に保存されているため、友達などが簡単にそのプロジェクトに参加したり最近の変更をpullしたりできます。",
"",
"最近ではリモートリポジトリに関するデータをビジュアル的に表示するウェブサイト([Github](https://github.com/)や[Phabricator](http://phabricator.org/)など)の使用が人気を集めていますが、リモートリポジトリは_そのいずれの_ウェブサイトの裏にも使われています。なので理解する必要があります。"
]
@ -450,7 +450,7 @@ exports.level = {
"",
"今までLearn Git Branchingでは_ローカル_リポジトリの様々な作業（branch, merge, rebaseなど）に焦点を当ててきました。しかし、これからはリモートリポジトリの作業を学びますので、レッスンのために環境をセットアップする必要があります。そのコマンドは`git clone`になります。",
"",
"普通の場合では`git clone`はリモートリポジトリ（githubなどから）を_ローカル_にコピーする時に使います。しかしLearn Git Branchingでは少し違ったように使います -- ここでは`git clone`が_ローカルリポジトリ_をリモートにコピーします。本当のコマンドの逆の動作になっているのですが、このようにcloneとリモートリポジトリのつながりが見えてきますので今のところは例として使いましょう。",
"通常、`git clone`はリモートリポジトリ（githubなどから）を_ローカル_にコピーする時に使います。しかしLearn Git Branchingでは少し違ったように使います -- ここでは`git clone`が_ローカルリポジトリ_をリモートにコピーします。本当のコマンドの逆の動作になっているのですが、学んでいくうちにcloneとリモートリポジトリのつながりが見えてくるはずです。なので、今はとりあえず例として使ってみましょう。",
""
]
}

2
src/levels/remote/fakeTeamwork.js
View file

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

6
src/levels/remote/fetch.js
View file

@ -544,7 +544,7 @@ exports.level = {
"",
"リモートGitを用いた作業は、本当にただ単なる他のリポジトリ_への_、または他のリポジトリ_からの_データの転送に集約されます。コミットを転送できる限り、Gitで管理されている全ての種類の更新が共有できます（例えば作業や、新しいファイル、新しいアイデア、ラブレターなどです）。",
"",
"このレベルでは、リモートリポジトリ_から_どうやってデータを取ってくる方法を学びます -- このコマンドは`git fetch`と名付けられています。",
"このレベルでは、リモートリポジトリ_から_データを取ってくる方法を学びます -- このコマンドは`git fetch`と名付けられています。",
"",
"リモートリポジトリの情報を私たちが更新するように、_リモート_ブランチも情報を更新することができることが分かるでしょう。これは前のレッスンでのリモートブランチの働きに結びつきます。"
]
@ -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`のダウンロードステップの動作が分かるようになるでしょう。"
]

47
src/levels/remote/mergeManyFeatures.js
View file

@ -19,7 +19,7 @@ exports.level = {
"es_AR": "¡Prestá atención al árbol final!",
"pt_BR": "Preste atenção na árvore do objetivo!",
"de_DE": "Beachte den Ziel-Baum!",
"ja" : "ゴールツリーに注意！",
"ja" : "ゴールツリーをよく見てください！",
"fr_FR": "Respectez l'arbre représentant l'objectif !"
},
"compareOnlyMaster": true,
@ -338,6 +338,51 @@ exports.level = {
}
}
]
},
"ja": {
"childViews": [
{
"type": "ModalAlert",
"options": {
"markdowns": [
"## なぜマージではいけないのか？",
"",
"新しい更新をリモートにプッシュするため、あなたがする必要があるのはリモートからの最近の変更の*組み込み*です。それは、リモートブランチ(例えば、`o/master`)にリベース*か*マージのどちらかをあなたがする必要があるということを意味します。",
"",
"もしどっちの方法でも行うことができるなら、なぜこれまでのレッスンでは、リベースに焦点を当ててきたのでしょう？リモートへの作業で、なぜ`merge`を推してこなかったのでしょうか？",
""
]
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"開発コミュニティで、マージとリベースの間でのトレードオフについては多くの議論がなされています。ここでは一般的なリベースのメリット/デメリットを紹介しましょう:",
"",
"メリット:",
"",
"* リベースは全てが直線上にあるので、あなたのコミットツリーをとても綺麗にみせます。",
"",
"デメリット:",
"",
"* リベースは、コミットツリーの（見ため上の）履歴を改変してしまいます。",
"",
"例えば、`C1`コミットは*過去*の`C3`コミットにリベースすることができます。それは、実際には前に完了しているのにもかかわらず、`C1'`の作業がまるで`C3`の後に行われたものであるかのように見えるようになります。",
"",
"幾人かの開発者は、履歴をそのまま保持するのが好みで、マージを選択します。その他（例えば私は）きれいなコミットツリーを好むのでリベースを選択します。つまるところ、好みの問題というわけですね :D"
]
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"このレベルでは、前回のレベルを*マージ*を代わりに使って解いてみてください。ちょっと難しいかもしれませんが、このレッスンのポイントを把握するのに十分な知見を得られるはずです。"
]
}
}
]
}
}
};

2
src/levels/remote/pull.js
View file

@ -507,7 +507,7 @@ exports.level = {
"",
"今や私たちはリモートリポジトリから`git fetch`でデータを取ってくる方法を知っているので、今度は私たちの作業にその変更を反映することを学びましょう！",
"",
"実際には多くの方法があり、ローカルで利用可能な新しいコミットがあった場合、あなたはそれらが他のブランチの普通のコミットであるかのようにそれらを組み込むことができます。これは、あなたが次のようなコマンドを実行することで行えます:",
"実際には多くの方法があり、ローカルに利用可能なリモートの新しいコミットがある場合、あなたはそのコミットを他のブランチの通常のコミットと同じように、自分の作業に組み込むことができます。これは、あなたが次のようなコマンドを実行することで行えます:",
"",
"* `git cherry-pick o/master`",
"* `git rebase o/master`",

2
src/levels/remote/push.js
View file

@ -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の設定を確認する価値はあるでしょう。*"
]
}
},

55
src/levels/remote/pushManyFeatures.js
View file

@ -20,7 +20,7 @@ exports.level = {
"es_AR": "¡Push Master!",
"pt_BR": "Push Master!",
"de_DE": "Push Master!",
"ja": "Push Master!",
"ja" : "Push Master!",
"fr_FR": "Maître du push !",
"ru_RU": "Push Мастер!"
},
@ -449,6 +449,59 @@ exports.level = {
}
}
]
},
"ja": {
"childViews": [
{
"type": "ModalAlert",
"options": {
"markdowns": [
"## 機能別のブランチ（フィーチャーブランチ）をマージする",
"",
"今や、あなたは`fetch`、`pull`、`push`を十分に使えるようになったでしょうから、そのスキルを新しい作業の流れで試してみましょう。",
"",
"大きなプロジェクトの開発者にとって、フィーチャーブランチ（`master`を除く）上で全ての作業を行い、完成したら一度でその作業を統合するというような流れが一般的です。これは前のレッスンの内容（他のブランチからリモートにプッシュされるような状況のところが）に似ていますが、ここではもう一歩踏み込んで解説しましょう。",
"",
"開発者は、`master`ブランチにいるときプッシュとプルしかしません -- `master`は常にリモート(`o/master`）に追従した状態のままにします。",
"",
"この作業の流れでは、私たちは二つのことを組み合わせています:",
"",
"* `master`にフィーチャーブランチの作業を統合し、",
"* リモートへの`push`と`pull`を行う"
]
}
},
{
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"`master`の更新と作業の反映の方法を手早く復習しましょう。"
],
"afterMarkdowns": [
"我々はここで二つのコマンドを動かしました:",
"",
"* リモートから新しいコミットを我々の作業にリベースし、",
"* リモートに我々の作業を公開しました"
],
"command": "git pull --rebase; git push",
"beforeCommand": "git clone; git commit; git fakeTeamwork"
}
},
{
"type": "ModalAlert",
"options": {
"markdowns": [
"このレベルはかなり難しいです -- ここに解答の一般的な道のりを示しておきます:",
"",
"* 三つのフィーチャーブランチ、`side1`、`side2`、`side3`があります。",
"* この機能をそれぞれ、この順に、リモートにプッシュしてください。",
"* リモートが更新されたなら、次はより良く作業を統合する方法を紹介しましょう。",
"",
":O これはきつそうだ！このレベルを完了させることは大きな一歩となります。幸運を祈ります。"
]
}
}
]
}
}
};

2
src/levels/remote/remoteBranches.js
View file

@ -482,7 +482,7 @@ exports.level = {
"",
"これに基づいて、`o/master`と名付けられたブランチを見てみると、`master`はブランチの名前、`o`はリモートの名前であることが分かります。",
"",
"多くの開発者は、実際にはメインのリモート名として`o`ではなく`origin`を使います。これは一般的には、Gitが`git clone`した時に`origin`という名前をリモートに付与ためです。",
"多くの開発者は、実際にはメインのリモート名として`o`ではなく`origin`を使います。これは一般的には、Gitが`git clone`した時に`origin`という名前をリモートに付与するためです。",
"",
"残念ながら、`origin`という長い名前は私たちのUIには合いませんでした。なので、私たちは短い`o`を使っています（覚えておいてもらいたいのは、実際のGitでは、リモートはおそらく`origin`と名付けられるであろうということです！）",
"",