ukiuni · June 3, 2016 23:39 · Mar 14, 2016 · May 27, 2013 · Mar 13, 2013 · Mar 13, 2013
diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -80,7 +80,7 @@ fetchすると他の皆が現在作業しているトピックを知ることが
 
 GitHubのブランチリストページでは、最近どんなブランチで作業がされているのか、どれくらいの作業をしているのかを大まかに知ることができるので、その点でも素晴らしい。
 
-![github branch list](https://img.skitch.com/20110831-x5nyqid885aqnp7t2au5ckw929.png)
+![github branch list](https://cloud.githubusercontent.com/assets/70/6769774/7988902c-d0a8-11e4-94c9-dc132461ffe4.png)
 
 これは、もうすぐ実装される機能の一覧におおまかな現在の状況が付いているようなものだ。このページはとても素晴らしい − 現在選択しているブランチと比較して、それぞれのブランチがどのような固有の作業内容を含んでいるかだけが表示され、最も最近作業されたものが一番上に来る。興味を惹かれれば、Compareボタンをクリックして実際の差分を見たり、そのブランチ固有のコミット一覧を見ることもできる。
 
@@ -119,11 +119,11 @@ GitHubには、残念だが十分な人々には知られていない [プルリ
 
 実際、我々はプルリクエストよりもブランチでの会話ビューとしてもっとPull Requestsを使っている。GitHub上の1つのプロジェクト(パブリックまたはプライベート)において、あるブランチから他のブランチへプルリクエストを送ることができるので、「これをマージしてほしい」に加えて「これに助けやレビューを必要としているんだ」と言うのにプルリクエストを使うことができる。
 
-![early pr message](https://img.skitch.com/20110831-1mft7b5nbxrcghasbi9hkbs84s.png)
+![early pr message](https://cloud.githubusercontent.com/assets/70/6769770/61a2dcba-d0a8-11e4-9924-3576232053ee.png)
 
 JoshがBrianにレビューのためにCCして、Brianが何行かあるコードの1行へのアドバイスと共にコメントしたのが分かるだろう。さらにその下ではJoshがBrianの懸念に同意して、それらに取り組むためより多くのコードをプッシュしたことが分かる。
 
-![more discussion](https://img.skitch.com/20110831-j181q96hh7k8x2e1iuh38jsc8a.png)
+![more discussion](https://cloud.githubusercontent.com/assets/70/6769767/5054b4ba-d0a8-11e4-8d38-548ecf157018.png)
 
 結局、我々はまだ試行フェーズ ― これはまだデプロイの準備ができたブランチではないということ ― におり、我々は実際にデプロイのために `master` にマージしたいと思うよりずっと前からコードをレビューするためにPull Requestsを使っている。
 
@@ -133,15 +133,15 @@ JoshがBrianにレビューのためにCCして、Brianが何行かあるコー
 
 もしブランチがあまりに長くオープンになっていて、 masterブランチと同期しないようになってきたと感じたら、masterをあなたのトピック・ブランチにマージして進み続けよう。ブランチが 'master' に最後に更新したのがいつか、プルリクエストの議論やコミットリストで簡単に分かる。
 
-![master merge](https://img.skitch.com/20110831-q5dwhwk3dut7mdqm2kp7qwqu67.png)
+![master merge](https://cloud.githubusercontent.com/assets/70/6769754/2162f69e-d0a8-11e4-8c98-d2bb581f7152.png)
 
 ブランチですべてが本当に完了し、もうデプロイしてもいい頃だと感じた時、次のステップに進むことができる。
 
 #### #5 - マージはプルリクエストがレビューされた後だけ
 
 我々は単純に `master` で直接作業したり、トピック・ブランチで作業して完了したと思ったときにマージしたりはしない ― 我々は会社にいる他の誰かに締めくくってもらおうとする。これは一般に +1 や絵文字、 "`:shipit:`" コメントであるが、我々は他の誰かにこれを見てもらうようにするのだ。
 
-![shipit comment](https://img.skitch.com/20110831-8gg3uhb14adjis43wa6swiinik.png)
+![shipit comment](https://cloud.githubusercontent.com/assets/70/6769753/0ea37c4a-d0a8-11e4-8b61-7aa73b7e3b03.png)
 
 一度我々がこれをキメ、ブランチがCIをパスすると、我々はデプロイのためにこれをmasterにマージすることができ、それをプッシュしたときに自動的にプルリクエストをクローズする。
 
@@ -157,7 +157,7 @@ hubot deploy github to production
 
 がコードをデプロイし、ダウンタイムなしで必要なすべてのプロセスをリスタートする。これがGitHubでどれだけありふれたものか分かる:
 
-![our campfire logs](https://img.skitch.com/20110831-jcmx5qktw5beabq7q1rcpj1k6c.png)
+![our campfire logs](https://cloud.githubusercontent.com/assets/70/6769750/ebc7b3da-d0a7-11e4-96e3-cfe0cea6ae51.png)
 
 1日に約24時間、6人の異なる人々(サポート担当やデザイナーを含む)がデプロイしていることが分かるだろう。
 

diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -152,7 +152,7 @@ JoshがBrianにレビューのためにCCして、Brianが何行かあるコー
 我々のcampfire bot、hubotは、従業員の何でもをデプロイできるので、簡単な:
 
 ```
-hubot depoy github to production
+hubot deploy github to production
 ```
 
 がコードをデプロイし、ダウンタイムなしで必要なすべてのプロセスをリスタートする。これがGitHubでどれだけありふれたものか分かる:

diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -58,7 +58,7 @@ GitHub Flowとは何だろうか？
 
 #### #1 - masterブランチのものは何であれデプロイ可能である
 
-このシステムにおいて困難なルールは、おおむねこの点だけである。
+これが、おおむねこのシステムにおけるたった一つの厳格な *ルール* である。
 明確に一貫した目的をもつ唯一のブランチがあり、それを`master`と呼ぶ。
 それは、そのブランチが既にデプロイされているか、または最悪の場合でも数時間以内にはデプロイされる、ということを意味する。
 ブランチが巻き戻される（作業内容を取り消すためにブランチが古いコミットを指すようにする）ことは非常に稀である − もし問題が起きたら、コミットは取り消されるか（reverted）、問題を修正した新しいコミットが行われるが、ブランチ自身がロールバックすることはほとんどない。

diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -147,7 +147,7 @@ JoshがBrianにレビューのためにCCして、Brianが何行かあるコー
 
 #### #6 - レビューのあとは直ちにデプロイする
 
-最終的に、あなたの作業は完了し `master` ブランチにマージされる。これは、たとえあなたが今デプロイしなくとも、これを基に人々が新しい作業のベースにして、新しいデプロイが、これは数時間のうちに起こりそうであるが、押し出される。よって他の誰かにあなたの書いたものが壊してしまうような何かを本当にプッシュしてほしくないので、マージされた時には人々はそれが本当に安定していることを確かめたくなるし、彼らの変更をプッシュしたくなる。
+最終的に、あなたの作業は完了し `master` ブランチにマージされる。これは、たとえあなたが今デプロイしなくとも、これを基に人々が新しい作業のベースにして、次のデプロイが、数時間以内に起こるだろうが、それを押し出していくだろうということだ。よって他の誰かにあなたの書いたものが壊してしまうような何かを本当にプッシュしてほしくないので、マージされた時には人々はそれが本当に安定していることを確かめたくなるし、彼らの変更をプッシュしたくなる。
 
 我々のcampfire bot、hubotは、従業員の何でもをデプロイできるので、簡単な:
 

diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -8,7 +8,7 @@
 
 私は人々にGitを教えるためにあちこちを飛び回っているが、最近のほぼすべてのクラスやワークショップで [git-flow](http://nvie.com/posts/a-successful-git-branching-model/) についてどう思うかを尋ねられた。私はいつも、git-flowは素晴らしいと思うと答えている。何百万ものワークフローを持ったシステム（Git）を提供し、ドキュメントもあるし、よくテストされている。フレキシブルなワークフローは、実に容易なやり方で多くの開発者の役に立つ。標準的なものになりつつあり、開発者はプロジェクトや企業の間を移動しつつこの標準的なワークフローに馴染むことができる。
 
-しかしながら、それ故の問題も抱えている。新しいフィーチャーブランチをmasterではなくdevelopから開始するとか、hotfixesを扱う方法といったことを好まないような人たちから多くの意見を聞く。
+しかしながら、それ故の問題も抱えている。新しいフィーチャーブランチを `master` ではなく `develop` から開始するとか、hotfixesを扱う方法といったことを好まないような人たちから多くの意見を聞く。
 
 私が考える大きな問題のひとつは、それが、ほとんどの開発者や開発チームが実際に必要とするよりも複雑すぎやしないか、ということだ。フローの遂行を支援するために開発された巨大な [ヘルパースクリプト](https://github.com/nvie/gitflow) であり、あまりに複雑すぎる。
 
@@ -67,8 +67,8 @@ GitHub Flowとは何だろうか？
 テストされていなかったり、ビルドを破壊するようなコードを`master`にpushした場合には、開発チーム間におけるソーシャルな取り決めを破ることになり、ちょっと気まずい思いをすることになる。
 我々がpushしたすべてのブランチではテストが実行され、その結果がチャットルームに報告される。もしテストを手元で実行していない場合には、サーバー上のトピックブランチ（たいていは1つのコミットだけのブランチ）にpushして、 [Jenkins](http://jenkins-ci.org/) がその結果を教えてくれるのを待つこともできる。
 
-デプロイを行った時だけ更新されるdeployedブランチを用意することもできるが、我々はそのようなことはしない。
-我々は、現在デプロイされているSHA（ハッシュ）をWebアプリ経由で公開するようにし、比較が必要な場合はそれを単にcurlするだけにしている。
+デプロイを行った時だけ更新される `deployed` ブランチを用意することもできるが、我々はそのようなことはしない。
+我々は、現在デプロイされているSHA（ハッシュ）をWebアプリ経由で公開するようにし、比較が必要な場合はそれを単に `curl` するだけにしている。
 
 #### #2 - masterから説明的なブランチを作成する
 
@@ -90,7 +90,7 @@ GitHubのブランチリストページでは、最近どんなブランチで
 
 git-flowとの大きな違いのひとつが、名前を付けたブランチを定期的にサーバーにpushするという点だ。我々がデプロイの観点で本当に気にしているものは`master`だけなので、サーバーへpushすることが誰かの手を煩わせたり、混乱を引き起こしたりすることはない − `master`以外のものはすべて、単に作業中の何かだということに過ぎない。
 
-それによって、ノートパソコンを紛失したりハードディスクが故障した場合でも作業内容が常にバックアップされていることも確実となる。より重要なこととして、皆が定期的にコミュニケーションをとるようになる。単なる`git fetch`が、皆が作業していることについてのTODOリストを与えてくれる。
+それによって、ノートパソコンを紛失したりハードディスクが故障した場合でも作業内容が常にバックアップされていることも確実となる。より重要なこととして、皆が定期的にコミュニケーションをとるようになる。単なる 'git fetch' が、皆が作業していることについてのTODOリストを与えてくれる。
 
     $ git fetch
     remote: Counting objects: 3032, done.
@@ -131,7 +131,7 @@ JoshがBrianにレビューのためにCCして、Brianが何行かあるコー
 
 プルリクエストの機能によりunified diffや1コミット、またはプルリクエスト自体の各行にコメントを入れられて、インラインの全てを1つの会話ビューに持ってこられるので、これはクールだ。それはまたブランチにプッシュし続けられるので、もしあなたが何かをやり忘れたりコードにバグがあると誰かがコメントすれば、あなたはそれを修正してブランチにプッシュし、GitHubが会話ビューに新しいコミットを表示して、こんな風にブランチに繰り返していられるのだ。
 
-もしブランチがあまりに長くオープンになっていて、 `master` ブランチと同期しないようになってきたと感じたら、`master` をあなたのトピック・ブランチにマージして進み続けよう。ブランチが `master` に最後に更新したのがいつか、プルリクエストの議論やコミットリストで簡単に分かる。
+もしブランチがあまりに長くオープンになっていて、 masterブランチと同期しないようになってきたと感じたら、masterをあなたのトピック・ブランチにマージして進み続けよう。ブランチが 'master' に最後に更新したのがいつか、プルリクエストの議論やコミットリストで簡単に分かる。
 
 ![master merge](https://img.skitch.com/20110831-q5dwhwk3dut7mdqm2kp7qwqu67.png)
 
@@ -147,7 +147,7 @@ JoshがBrianにレビューのためにCCして、Brianが何行かあるコー
 
 #### #6 - レビューのあとは直ちにデプロイする
 
-最終的に、あなたの作業は完了しmasterブランチにマージされる。これは、たとえあなたが今デプロイしなくとも、これを基に人々が新しい作業のベースにして、新しいデプロイが、これは数時間のうちに起こりそうであるが、押し出される。よって他の誰かにあなたの書いたものが壊してしまうような何かを本当にプッシュしてほしくないので、マージされた時には人々はそれが本当に安定していることを確かめたくなるし、彼らの変更をプッシュしたくなる。
+最終的に、あなたの作業は完了し `master` ブランチにマージされる。これは、たとえあなたが今デプロイしなくとも、これを基に人々が新しい作業のベースにして、新しいデプロイが、これは数時間のうちに起こりそうであるが、押し出される。よって他の誰かにあなたの書いたものが壊してしまうような何かを本当にプッシュしてほしくないので、マージされた時には人々はそれが本当に安定していることを確かめたくなるし、彼らの変更をプッシュしたくなる。
 
 我々のcampfire bot、hubotは、従業員の何でもをデプロイできるので、簡単な:
 

diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -6,7 +6,7 @@
 
 ## git-flowの問題点 (Issues with git-flow)
 
-私は人々にGitを教えるためにあちこちを飛び回っているが、最近のほぼすべてのクラスやワークショップで [git-flow[(http://nvie.com/posts/a-successful-git-branching-model/) についてどう思うかを尋ねられた。私はいつも、git-flowは素晴らしいと思うと答えている。何百万ものワークフローを持ったシステム（Git）を提供し、ドキュメントもあるし、よくテストされている。フレキシブルなワークフローは、実に容易なやり方で多くの開発者の役に立つ。標準的なものになりつつあり、開発者はプロジェクトや企業の間を移動しつつこの標準的なワークフローに馴染むことができる。
+私は人々にGitを教えるためにあちこちを飛び回っているが、最近のほぼすべてのクラスやワークショップで [git-flow](http://nvie.com/posts/a-successful-git-branching-model/) についてどう思うかを尋ねられた。私はいつも、git-flowは素晴らしいと思うと答えている。何百万ものワークフローを持ったシステム（Git）を提供し、ドキュメントもあるし、よくテストされている。フレキシブルなワークフローは、実に容易なやり方で多くの開発者の役に立つ。標準的なものになりつつあり、開発者はプロジェクトや企業の間を移動しつつこの標準的なワークフローに馴染むことができる。
 
 しかしながら、それ故の問題も抱えている。新しいフィーチャーブランチをmasterではなくdevelopから開始するとか、hotfixesを扱う方法といったことを好まないような人たちから多くの意見を聞く。
 
@@ -115,7 +115,7 @@ git-flowとの大きな違いのひとつが、名前を付けたブランチを
 
 #### #4 - いつでもプルリクエストを作る
 
-GitHubには、残念だが十分な人々には知られていない [Pull Requests](http://help.github.com/send-pull-requests/) と呼ばれる素晴らしいコードレビューの仕組みがある。多くの人々はオープンソースでの活動 ― プロジェクトをフォークする、プロジェクトを更新する、メンテナーにプルリクエストを送る ― にそれを使っている。しかし、プルリクエストは内部コードレビューの仕組みとして簡単に利用することもできて、我々はそうしている。
+GitHubには、残念だが十分な人々には知られていない [プルリクエスト](http://help.github.com/send-pull-requests/) と呼ばれる素晴らしいコードレビューの仕組みがある。多くの人々はオープンソースでの活動 ― プロジェクトをフォークする、プロジェクトを更新する、メンテナーにプルリクエストを送る ― にそれを使っている。しかし、プルリクエストは内部コードレビューの仕組みとして簡単に利用することもできて、我々はそうしている。
 
 実際、我々はプルリクエストよりもブランチでの会話ビューとしてもっとPull Requestsを使っている。GitHub上の1つのプロジェクト(パブリックまたはプライベート)において、あるブランチから他のブランチへプルリクエストを送ることができるので、「これをマージしてほしい」に加えて「これに助けやレビューを必要としているんだ」と言うのにプルリクエストを使うことができる。
 

diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -6,11 +6,11 @@
 
 ## git-flowの問題点 (Issues with git-flow)
 
-私は人々にGitを教えるためにあちこちを飛び回っているが、最近のほぼすべてのクラスやワークショップで**git-flow**についてどう思うかを尋ねられた。私はいつも、git-flowは素晴らしいと思うと答えている。何百万ものワークフローを持ったシステム（Git）を提供し、ドキュメントもあるし、よくテストされている。フレキシブルなワークフローは、実に容易なやり方で多くの開発者の役に立つ。標準的なものになりつつあり、開発者はプロジェクトや企業の間を移動しつつこの標準的なワークフローに馴染むことができる。
+私は人々にGitを教えるためにあちこちを飛び回っているが、最近のほぼすべてのクラスやワークショップで [git-flow[(http://nvie.com/posts/a-successful-git-branching-model/) についてどう思うかを尋ねられた。私はいつも、git-flowは素晴らしいと思うと答えている。何百万ものワークフローを持ったシステム（Git）を提供し、ドキュメントもあるし、よくテストされている。フレキシブルなワークフローは、実に容易なやり方で多くの開発者の役に立つ。標準的なものになりつつあり、開発者はプロジェクトや企業の間を移動しつつこの標準的なワークフローに馴染むことができる。
 
 しかしながら、それ故の問題も抱えている。新しいフィーチャーブランチをmasterではなくdevelopから開始するとか、hotfixesを扱う方法といったことを好まないような人たちから多くの意見を聞く。
 
-私が考える大きな問題のひとつは、それが、ほとんどの開発者や開発チームが実際に必要とするよりも複雑すぎやしないか、ということだ。フローの遂行を支援するために開発された巨大な**ヘルパースクリプト**であり、あまりに複雑すぎる。
+私が考える大きな問題のひとつは、それが、ほとんどの開発者や開発チームが実際に必要とするよりも複雑すぎやしないか、ということだ。フローの遂行を支援するために開発された巨大な [ヘルパースクリプト](https://github.com/nvie/gitflow) であり、あまりに複雑すぎる。
 
 クールかもしれないが、GitのGUIツールには強制することができず、コマンドラインでしか使えないという問題がある。すべての手順を手動で行う必要もある。そのための複雑なワークフローをしっかりと学ばなければならない人たちが、コマンドラインでの作業に不慣れな人たちとイコールでもある。これは大きな問題点だ。
 
@@ -45,7 +45,7 @@ GitHub Flowとは何だろうか？
 * `master`ブランチのものは何であれデプロイ可能である
 * 新しい何かに取り組む際は、説明的な名前のブランチをmasterから作成する（例: `new-oauth2-scopes`）
 * 作成したブランチにローカルでコミットし、サーバー上の同じ名前のブランチにも定期的に作業内容をpushする
-* フィードバックや助言が欲しい時、ブランチをマージしてもよいと思ったときは、**プルリクエスト**を作成する
+* フィードバックや助言が欲しい時、ブランチをマージしてもよいと思ったときは、 [プルリクエスト](http://help.github.com/send-pull-requests/) を作成する
 * 他の誰かがレビューをして機能にOKを出してくれたら、あなたはコードを`master`へマージすることができる
 * マージをして`master`へpushしたら、直ちにデプロイをする
 
@@ -65,7 +65,7 @@ GitHub Flowとは何だろうか？
 
 `master`ブランチは安定しており、常に、そう常にデプロイ可能かつそこから新しいブランチを作成できる状態になっている。
 テストされていなかったり、ビルドを破壊するようなコードを`master`にpushした場合には、開発チーム間におけるソーシャルな取り決めを破ることになり、ちょっと気まずい思いをすることになる。
-我々がpushしたすべてのブランチではテストが実行され、その結果がチャットルームに報告される。もしテストを手元で実行していない場合には、サーバー上のトピックブランチ（たいていは1つのコミットだけのブランチ）にpushして、**Jenkins**がその結果を教えてくれるのを待つこともできる。
+我々がpushしたすべてのブランチではテストが実行され、その結果がチャットルームに報告される。もしテストを手元で実行していない場合には、サーバー上のトピックブランチ（たいていは1つのコミットだけのブランチ）にpushして、 [Jenkins](http://jenkins-ci.org/) がその結果を教えてくれるのを待つこともできる。
 
 デプロイを行った時だけ更新されるdeployedブランチを用意することもできるが、我々はそのようなことはしない。
 我々は、現在デプロイされているSHA（ハッシュ）をWebアプリ経由で公開するようにし、比較が必要な場合はそれを単にcurlするだけにしている。
@@ -115,7 +115,7 @@ git-flowとの大きな違いのひとつが、名前を付けたブランチを
 
 #### #4 - いつでもプルリクエストを作る
 
-GitHubには、残念だが十分な人々には知られていない **Pull Requests** と呼ばれる素晴らしいコードレビューの仕組みがある。多くの人々はオープンソースでの活動 ― プロジェクトをフォークする、プロジェクトを更新する、メンテナーにプルリクエストを送る ― にそれを使っている。しかし、プルリクエストは内部コードレビューの仕組みとして簡単に利用することもできて、我々はそうしている。
+GitHubには、残念だが十分な人々には知られていない [Pull Requests](http://help.github.com/send-pull-requests/) と呼ばれる素晴らしいコードレビューの仕組みがある。多くの人々はオープンソースでの活動 ― プロジェクトをフォークする、プロジェクトを更新する、メンテナーにプルリクエストを送る ― にそれを使っている。しかし、プルリクエストは内部コードレビューの仕組みとして簡単に利用することもできて、我々はそうしている。
 
 実際、我々はプルリクエストよりもブランチでの会話ビューとしてもっとPull Requestsを使っている。GitHub上の1つのプロジェクト(パブリックまたはプライベート)において、あるブランチから他のブランチへプルリクエストを送ることができるので、「これをマージしてほしい」に加えて「これに助けやレビューを必要としているんだ」と言うのにプルリクエストを使うことができる。
 
@@ -169,6 +169,6 @@ hubot depoy github to production
 
 Git自体は理解するのにかなり複雑である、つまりGitを必要以上に複雑に使うワークフローを作成することは、単に皆の時間に精神的なオーバーヘッドをさらに増やすことになるということだ。あなたのチームに機能するもっとも単純で可能なシステムを使うこと、およびそれがこれ以上機能しなくなるまで行うこと、そして絶対に必要である限りにおいてのみ複雑さを入れることを、私は常に推奨する。
 
-長いインターバル(リリースの間に数週から数カ月)で定型的なリリースを行わなければならないチームや、ホットフィックスやメンテナンス・ブランチ、そしてごくまれに出荷で発生するその他の事々にとって、 `git-flow` は意味があり、私はその使用を強く推奨するだろう。
+長いインターバル(リリースの間に数週から数カ月)で定型的なリリースを行わなければならないチームや、ホットフィックスやメンテナンス・ブランチ、そしてごくまれに出荷で発生するその他の事々にとって、 [git-flow](http://nvie.com/posts/a-successful-git-branching-model/) は意味があり、私はその使用を強く推奨するだろう。
 
 製品を毎日プッシュし、コンスタントにテストしデプロイするという、出荷の文化を作り上げてきたチームに対して、私はGitHub Flowのようなもっとシンプルな何かを選ぶことをお勧めする。
diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -92,26 +92,24 @@ git-flowとの大きな違いのひとつが、名前を付けたブランチを
 
 それによって、ノートパソコンを紛失したりハードディスクが故障した場合でも作業内容が常にバックアップされていることも確実となる。より重要なこととして、皆が定期的にコミュニケーションをとるようになる。単なる`git fetch`が、皆が作業していることについてのTODOリストを与えてくれる。
 
-```
-$ git fetch
-remote: Counting objects: 3032, done.
-remote: Compressing objects: 100% (947/947), done.
-remote: Total 2672 (delta 1993), reused 2328 (delta 1689)
-Receiving objects: 100% (2672/2672), 16.45 MiB | 1.04 MiB/s, done.
-Resolving deltas: 100% (1993/1993), completed with 213 local objects.
-From github.com:github/github
- * [new branch]      charlock-linguist -> origin/charlock-linguist
- * [new branch]      enterprise-non-config -> origin/enterprise-non-config
- * [new branch]      fi-signup  -> origin/fi-signup
-   2647a42..4d6d2c2  git-http-server -> origin/git-http-server
- * [new branch]      knyle-style-commits -> origin/knyle-style-commits
-   157d2b0..d33e00d  master     -> origin/master
- * [new branch]      menu-behavior-act-i -> origin/menu-behavior-act-i
-   ea1c5e2..dfd315a  no-inline-js-config -> origin/no-inline-js-config
- * [new branch]      svg-tests  -> origin/svg-tests
-   87bb870..9da23f3  view-modes -> origin/view-modes
- * [new branch]      wild-renaming -> origin/wild-renaming
- ```
+    $ git fetch
+    remote: Counting objects: 3032, done.
+    remote: Compressing objects: 100% (947/947), done.
+    remote: Total 2672 (delta 1993), reused 2328 (delta 1689)
+    Receiving objects: 100% (2672/2672), 16.45 MiB | 1.04 MiB/s, done.
+    Resolving deltas: 100% (1993/1993), completed with 213 local objects.
+    From github.com:github/github
+     * [new branch]      charlock-linguist -> origin/charlock-linguist
+     * [new branch]      enterprise-non-config -> origin/enterprise-non-config
+     * [new branch]      fi-signup  -> origin/fi-signup
+       2647a42..4d6d2c2  git-http-server -> origin/git-http-server
+     * [new branch]      knyle-style-commits -> origin/knyle-style-commits
+       157d2b0..d33e00d  master     -> origin/master
+     * [new branch]      menu-behavior-act-i -> origin/menu-behavior-act-i
+       ea1c5e2..dfd315a  no-inline-js-config -> origin/no-inline-js-config
+     * [new branch]      svg-tests  -> origin/svg-tests
+       87bb870..9da23f3  view-modes -> origin/view-modes
+     * [new branch]      wild-renaming -> origin/wild-renaming
 
 さらにそれによって、他の皆が何をしているのかを知ったり、助けを必要としていないかを確認するためにGitHubのブランチリストページを見るよう、全員が動くことにも繋がる。
 
@@ -133,7 +131,7 @@ JoshがBrianにレビューのためにCCして、Brianが何行かあるコー
 
 プルリクエストの機能によりunified diffや1コミット、またはプルリクエスト自体の各行にコメントを入れられて、インラインの全てを1つの会話ビューに持ってこられるので、これはクールだ。それはまたブランチにプッシュし続けられるので、もしあなたが何かをやり忘れたりコードにバグがあると誰かがコメントすれば、あなたはそれを修正してブランチにプッシュし、GitHubが会話ビューに新しいコミットを表示して、こんな風にブランチに繰り返していられるのだ。
 
-もしブランチがあまりに長くオープンになっていて、 `master` ブランチと同期しないようになってきたと感じたら、あなたのトピック・ブランチを `master` にマージして進み続けよう。ブランチが `master` に最後に更新したのがいつか、プルリクエストの議論やコミットリストで簡単に分かる。
+もしブランチがあまりに長くオープンになっていて、 `master` ブランチと同期しないようになってきたと感じたら、`master` をあなたのトピック・ブランチにマージして進み続けよう。ブランチが `master` に最後に更新したのがいつか、プルリクエストの議論やコミットリストで簡単に分かる。
 
 ![master merge](https://img.skitch.com/20110831-q5dwhwk3dut7mdqm2kp7qwqu67.png)
 

diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -141,7 +141,7 @@ JoshがBrianにレビューのためにCCして、Brianが何行かあるコー
 
 #### #5 - マージはプルリクエストがレビューされた後だけ
 
-我々は単純に `master` で直接作業したり、トピック・ブランチで作業して完了したと思ったときにマージしたりはしない ― 我々は会社にいる他の誰かに締めくくってもらおうとする。これは一般に +1 や絵文字、 "`:shipit:`" コメントであるが、我々はは他の誰かにこれを見てもらうようにするのだ。
+我々は単純に `master` で直接作業したり、トピック・ブランチで作業して完了したと思ったときにマージしたりはしない ― 我々は会社にいる他の誰かに締めくくってもらおうとする。これは一般に +1 や絵文字、 "`:shipit:`" コメントであるが、我々は他の誰かにこれを見てもらうようにするのだ。
 
 ![shipit comment](https://img.skitch.com/20110831-8gg3uhb14adjis43wa6swiinik.png)
 

diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -169,8 +169,8 @@ hubot depoy github to production
 
 ## まとめ
 
-Git自体は理解するのにかなり複雑、つまりGitを必要以上に複雑に使うワークフローを作成することは、単に皆の時間に精神的なオーバーヘッドをさらに増やすことになるということだ。私は常にあなたのチームに機能するもっとも単純で可能なシステムを使うこと、およびそれがこれ以上機能しなくなるまでおこなうこと、そして絶対に必要である限りにおいて複雑さを入れることを推奨してきた。
+Git自体は理解するのにかなり複雑である、つまりGitを必要以上に複雑に使うワークフローを作成することは、単に皆の時間に精神的なオーバーヘッドをさらに増やすことになるということだ。あなたのチームに機能するもっとも単純で可能なシステムを使うこと、およびそれがこれ以上機能しなくなるまで行うこと、そして絶対に必要である限りにおいてのみ複雑さを入れることを、私は常に推奨する。
 
 長いインターバル(リリースの間に数週から数カ月)で定型的なリリースを行わなければならないチームや、ホットフィックスやメンテナンス・ブランチ、そしてごくまれに出荷で発生するその他の事々にとって、 `git-flow` は意味があり、私はその使用を強く推奨するだろう。
 
-製品を毎日プッシュし、コンスタントにテストしデプロイする、出荷の文化を作り上げてきたチームに対して、私はGitHub Flowのようなもっとシンプルな何かを選ぶことをお勧めする。
+製品を毎日プッシュし、コンスタントにテストしデプロイするという、出荷の文化を作り上げてきたチームに対して、私はGitHub Flowのようなもっとシンプルな何かを選ぶことをお勧めする。
diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -141,15 +141,15 @@ JoshがBrianにレビューのためにCCして、Brianが何行かあるコー
 
 #### #5 - マージはプルリクエストがレビューされた後だけ
 
-我々は単純に `master` で直接作業したり、トピック・ブランチで作業して完了したと思ったときにマージしたりはしない ― 我々は会社にいる他の誰かに締めくくってもらおうとする。これは一般に +1 や絵文字、 ":shipit:" コメントであるが、我々はは他の誰かにこれを見てもらうようにするのだ。
+我々は単純に `master` で直接作業したり、トピック・ブランチで作業して完了したと思ったときにマージしたりはしない ― 我々は会社にいる他の誰かに締めくくってもらおうとする。これは一般に +1 や絵文字、 "`:shipit:`" コメントであるが、我々はは他の誰かにこれを見てもらうようにするのだ。
 
 ![shipit comment](https://img.skitch.com/20110831-8gg3uhb14adjis43wa6swiinik.png)
 
 一度我々がこれをキメ、ブランチがCIをパスすると、我々はデプロイのためにこれをmasterにマージすることができ、それをプッシュしたときに自動的にプルリクエストをクローズする。
 
 #### #6 - レビューのあとは直ちにデプロイする
 
-最後に、あなたの作業は完了しmasterブランチにマージされる。これは、たとえあなたがいまデプロイしなくとも、これを基に人々が新しい作業のベースにして、新しいデプロイが、これは数時間のうちに起こりそうであるが、押し出される。よって他の誰かにあなたの書いたものが壊してしまうような何かを本当にプッシュしてほしくないので、マージされた時には人々はそれが本当に安定していることを確かめたくなるし、彼らの変更をプッシュしたくなる。
+最終的に、あなたの作業は完了しmasterブランチにマージされる。これは、たとえあなたが今デプロイしなくとも、これを基に人々が新しい作業のベースにして、新しいデプロイが、これは数時間のうちに起こりそうであるが、押し出される。よって他の誰かにあなたの書いたものが壊してしまうような何かを本当にプッシュしてほしくないので、マージされた時には人々はそれが本当に安定していることを確かめたくなるし、彼らの変更をプッシュしたくなる。
 
 我々のcampfire bot、hubotは、従業員の何でもをデプロイできるので、簡単な:
 
@@ -163,14 +163,14 @@ hubot depoy github to production
 
 1日に約24時間、6人の異なる人々(サポート担当やデザイナーを含む)がデプロイしていることが分かるだろう。
 
-私はこれを、1行の変更を含む1つのコミットでもって複数のブランチに行ったことがある。プロセスはシンプルで一本道、拡張性があって力強い。あなたはそれを、フィーチャー・ブランチに2週間かかる50コミットでやることことも、10分かかる1コミットでやることもできる。こんなにも単純で摩擦の無いプロセスなので、1コミットでさえ、これは変更がとても小さかったり大したことがないので問題にならない限りは、人々がめったにプロセスをスキップしたり迂回したりしようとしないことを意味するが、それをしなければならないか悩まなくてよい。
+私はこれを、1行の変更を含む1つのコミットでもって複数のブランチに行ったことがある。プロセスはシンプルで一本道、拡張性があって力強い。あなたはそれを、フィーチャー・ブランチに2週間かかる50コミットでやることも、10分かかる1コミットでやることもできる。こんなにも単純で摩擦の無いプロセスなので、1コミットでさえ、これは変更がとても小さかったり大したことがないため問題にならない限りは、人々がめったにプロセスをスキップしたり迂回したりしようとしないことを意味するが、それをしなければならないか悩まなくてよい。
 
 これは信じられないほど簡単でパワフルなプロセスだ。GitHubがとても安定したプラットフォームを持ち、もしイシューが起票されたならそれらは速やかに対処され、新しい機能は迅速なペースで導入されるということに、ほとんどの人々が同意してくれるものと考えている。我々はさらなるスピードや単純さ、より少ないプロセスが得られるように、品質や安定性への妥協がない。
 
 ## まとめ
 
-Git itself is fairly complex to understand, making the workflow that you use with it more complex than necessary is simply adding more mental overhead to everybody’s day. I would always advocate using the simplest possible system that will work for your team and doing so until it doesn’t work anymore and then adding complexity only as absolutely needed.
+Git自体は理解するのにかなり複雑、つまりGitを必要以上に複雑に使うワークフローを作成することは、単に皆の時間に精神的なオーバーヘッドをさらに増やすことになるということだ。私は常にあなたのチームに機能するもっとも単純で可能なシステムを使うこと、およびそれがこれ以上機能しなくなるまでおこなうこと、そして絶対に必要である限りにおいて複雑さを入れることを推奨してきた。
 
-For teams that have to do formal releases on a longer term interval (a few weeks to a few months between releases), and be able to do hot-fixes and maintenance branches and other things that arise from shipping so infrequently, git-flow makes sense and I would highly advocate it’s use.
+長いインターバル(リリースの間に数週から数カ月)で定型的なリリースを行わなければならないチームや、ホットフィックスやメンテナンス・ブランチ、そしてごくまれに出荷で発生するその他の事々にとって、 `git-flow` は意味があり、私はその使用を強く推奨するだろう。
 
-For teams that have set up a culture of shipping, who push to production every day, who are constantly testing and deploying, I would advocate picking something simpler like GitHub Flow.
+製品を毎日プッシュし、コンスタントにテストしデプロイする、出荷の文化を作り上げてきたチームに対して、私はGitHub Flowのようなもっとシンプルな何かを選ぶことをお勧めする。
diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -149,23 +149,23 @@ JoshがBrianにレビューのためにCCして、Brianが何行かあるコー
 
 #### #6 - レビューのあとは直ちにデプロイする
 
-Finally, your work is done and merged into the master branch. This means that even if you don’t deploy it now, people will base new work off of it and the next deploy, which will likely happen in a few hours, will push it out. So since you really don’t want someone else to push something that you wrote that breaks things, people tend to make sure that it really is stable when it’s merged and people also tend to push their own changes.
+最後に、あなたの作業は完了しmasterブランチにマージされる。これは、たとえあなたがいまデプロイしなくとも、これを基に人々が新しい作業のベースにして、新しいデプロイが、これは数時間のうちに起こりそうであるが、押し出される。よって他の誰かにあなたの書いたものが壊してしまうような何かを本当にプッシュしてほしくないので、マージされた時には人々はそれが本当に安定していることを確かめたくなるし、彼らの変更をプッシュしたくなる。
 
-Our campfire bot, hubot, can do deployments for any of the employees, so a simple:
+我々のcampfire bot、hubotは、従業員の何でもをデプロイできるので、簡単な:
 
 ```
 hubot depoy github to production
 ```
 
-will deploy the code and zero-downtime restart all the necessary processes. You can see how common this is at GitHub:
+がコードをデプロイし、ダウンタイムなしで必要なすべてのプロセスをリスタートする。これがGitHubでどれだけありふれたものか分かる:
 
 ![our campfire logs](https://img.skitch.com/20110831-jcmx5qktw5beabq7q1rcpj1k6c.png)
 
-You can see 6 different people (including a support guy and a designer) deploying about 24 times in one day.
+1日に約24時間、6人の異なる人々(サポート担当やデザイナーを含む)がデプロイしていることが分かるだろう。
 
-I have done this for branches with one commit containing a one line change. The process is simple, straightforward, scalable and powerful. You can do it with feature branches with 50 commits on them that took 2 weeks, or 1 commit that took 10 minutes. It is such a simple and frictionless process that you are not annoyed that you have to do it even for 1 commit, which means people rarely try to skip or bypass the process unless the change is so small or insignificant that it just doesn’t matter.
+私はこれを、1行の変更を含む1つのコミットでもって複数のブランチに行ったことがある。プロセスはシンプルで一本道、拡張性があって力強い。あなたはそれを、フィーチャー・ブランチに2週間かかる50コミットでやることことも、10分かかる1コミットでやることもできる。こんなにも単純で摩擦の無いプロセスなので、1コミットでさえ、これは変更がとても小さかったり大したことがないので問題にならない限りは、人々がめったにプロセスをスキップしたり迂回したりしようとしないことを意味するが、それをしなければならないか悩まなくてよい。
 
-This is an incredibly simple and powerful process. I think most people would agree that GitHub has a very stable platform, that issues are addressed quickly if they ever come up at all, and that new features are introduced at a rapid pace. There is no compromise of quality or stability so that we can get more speed or simplicity or less process.
+これは信じられないほど簡単でパワフルなプロセスだ。GitHubがとても安定したプラットフォームを持ち、もしイシューが起票されたならそれらは速やかに対処され、新しい機能は迅速なペースで導入されるということに、ほとんどの人々が同意してくれるものと考えている。我々はさらなるスピードや単純さ、より少ないプロセスが得られるように、品質や安定性への妥協がない。
 
 ## まとめ
 

diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -119,19 +119,19 @@ From github.com:github/github
 
 GitHubには、残念だが十分な人々には知られていない **Pull Requests** と呼ばれる素晴らしいコードレビューの仕組みがある。多くの人々はオープンソースでの活動 ― プロジェクトをフォークする、プロジェクトを更新する、メンテナーにプルリクエストを送る ― にそれを使っている。しかし、プルリクエストは内部コードレビューの仕組みとして簡単に利用することもできて、我々はそうしている。
 
-実際、我々はプルリクエストよりもブランチでの会話を見るのによりPull Requestsを使っている。GitHub上の1つのプロジェクト(パブリックまたはプライベート)において、あるブランチから他のブランチへプルリクエストを送ることができるので、「これをマージしてほしい」に加えて「こいつへの助けかレビューを必要としているんだ」と言うためにプルリクエストを使うことができる。
+実際、我々はプルリクエストよりもブランチでの会話ビューとしてもっとPull Requestsを使っている。GitHub上の1つのプロジェクト(パブリックまたはプライベート)において、あるブランチから他のブランチへプルリクエストを送ることができるので、「これをマージしてほしい」に加えて「これに助けやレビューを必要としているんだ」と言うのにプルリクエストを使うことができる。
 
 ![early pr message](https://img.skitch.com/20110831-1mft7b5nbxrcghasbi9hkbs84s.png)
 
-JoshがBrianにレビューのためにCCして、Brianが何行かあるコードの1行へのアドバイスと共にやってきたのが分かるだろう。さらにその下ではJoshがBrianの懸念に同意して、それらに取り組むためより多くのコードをプッシュしたことが分かる。
+JoshがBrianにレビューのためにCCして、Brianが何行かあるコードの1行へのアドバイスと共にコメントしたのが分かるだろう。さらにその下ではJoshがBrianの懸念に同意して、それらに取り組むためより多くのコードをプッシュしたことが分かる。
 
 ![more discussion](https://img.skitch.com/20110831-j181q96hh7k8x2e1iuh38jsc8a.png)
 
-結局、我々はまだ試行フェーズにいる ― まだデプロイの準備ができたブランチではないということ、我々は実際にデプロイのために `master` にマージしたいと思うよりずっと前からコードをレビューするためにPull Requestsを使っている。
+結局、我々はまだ試行フェーズ ― これはまだデプロイの準備ができたブランチではないということ ― におり、我々は実際にデプロイのために `master` にマージしたいと思うよりずっと前からコードをレビューするためにPull Requestsを使っている。
 
 もしあなたが機能やブランチの進捗で嵌っていて助けやアドバイスが必要なら、またはもしあなたが開発者であなたの作業のレビューをしてくれるデザイナーが必要なら、あるいはたとえあなたがほとんどまたは全くコードを持っていないがスクリーンショットや一般的なアイディアがあるなら、プルリクエストをオープンするのだ。GitHubのシステム上で @ユーザ名 を追加することで人々をccすることができるので、もし特定の人のレビューやフィードバックが欲しいなら、(上でJoshがやったのを見たように)プルリクエスト・メッセージ内で単純に彼らにccすればいいのだ。
 
-プルリクエストの機能によりunified diffや1コミット、またはプルリクエスト自体の各行にコメントを入れられて、インラインの全てを1つの会話ビューに持ってこられるので、これはクールだ。それはまたブランチにプッシュし続けられるので、もし誰かがあなたが何かをやり忘れたりコードにバグがあるとコメントすれば、あなたはそれを修正してブランチにプッシュし、GitHubが会話ビューに新しいコミットを表示して、こんな風にブランチに繰り返していられるのだ。
+プルリクエストの機能によりunified diffや1コミット、またはプルリクエスト自体の各行にコメントを入れられて、インラインの全てを1つの会話ビューに持ってこられるので、これはクールだ。それはまたブランチにプッシュし続けられるので、もしあなたが何かをやり忘れたりコードにバグがあると誰かがコメントすれば、あなたはそれを修正してブランチにプッシュし、GitHubが会話ビューに新しいコミットを表示して、こんな風にブランチに繰り返していられるのだ。
 
 もしブランチがあまりに長くオープンになっていて、 `master` ブランチと同期しないようになってきたと感じたら、あなたのトピック・ブランチを `master` にマージして進み続けよう。ブランチが `master` に最後に更新したのがいつか、プルリクエストの議論やコミットリストで簡単に分かる。
 
@@ -141,11 +141,11 @@ JoshがBrianにレビューのためにCCして、Brianが何行かあるコー
 
 #### #5 - マージはプルリクエストがレビューされた後だけ
 
-We don’t simply do work directly on `master` or work on a topic branch and merge it in when we think it’s done - we try to get signoff from someone else in the company. This is generally a +1 or emoji or “:shipit:” comment, but we try to get someone else to look at it.
+我々は単純に `master` で直接作業したり、トピック・ブランチで作業して完了したと思ったときにマージしたりはしない ― 我々は会社にいる他の誰かに締めくくってもらおうとする。これは一般に +1 や絵文字、 ":shipit:" コメントであるが、我々はは他の誰かにこれを見てもらうようにするのだ。
 
 ![shipit comment](https://img.skitch.com/20110831-8gg3uhb14adjis43wa6swiinik.png)
 
-Once we get that, and the branch passes CI, we can merge it into master for deployment, which will automatically close the Pull Request when we push it.
+一度我々がこれをキメ、ブランチがCIをパスすると、我々はデプロイのためにこれをmasterにマージすることができ、それをプッシュしたときに自動的にプルリクエストをクローズする。
 
 #### #6 - レビューのあとは直ちにデプロイする
 

diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -117,27 +117,27 @@ From github.com:github/github
 
 #### #4 - いつでもプルリクエストを作る
 
-GitHub has an amazing code review system called **Pull Requests** that I fear not enough people know about. Many people use it for open source work - fork a project, update the project, send a pull request to the maintainer. However, it can also easily be used as an internal code review system, which is what we do.
+GitHubには、残念だが十分な人々には知られていない **Pull Requests** と呼ばれる素晴らしいコードレビューの仕組みがある。多くの人々はオープンソースでの活動 ― プロジェクトをフォークする、プロジェクトを更新する、メンテナーにプルリクエストを送る ― にそれを使っている。しかし、プルリクエストは内部コードレビューの仕組みとして簡単に利用することもできて、我々はそうしている。
 
-Actually, we use it more as a branch conversation view more than a pull request. You can send pull requests from one branch to another in a single project (public or private) in GitHub, so you can use them to say “I need help or review on this” in addition to “Please merge this in”.
+実際、我々はプルリクエストよりもブランチでの会話を見るのによりPull Requestsを使っている。GitHub上の1つのプロジェクト(パブリックまたはプライベート)において、あるブランチから他のブランチへプルリクエストを送ることができるので、「これをマージしてほしい」に加えて「こいつへの助けかレビューを必要としているんだ」と言うためにプルリクエストを使うことができる。
 
 ![early pr message](https://img.skitch.com/20110831-1mft7b5nbxrcghasbi9hkbs84s.png)
 
-Here you can see Josh cc’ing Brian for review and Brian coming in with some advice on one of the lines of code. Further down we can see Josh acknowledging Brian’s concerns and pushing more code to address them.
+JoshがBrianにレビューのためにCCして、Brianが何行かあるコードの1行へのアドバイスと共にやってきたのが分かるだろう。さらにその下ではJoshがBrianの懸念に同意して、それらに取り組むためより多くのコードをプッシュしたことが分かる。
 
 ![more discussion](https://img.skitch.com/20110831-j181q96hh7k8x2e1iuh38jsc8a.png)
 
-Finally you can see that we’re still in the trial phase - this is not a deployment ready branch yet, we use the Pull Requests to review the code long before we actually want to merge it into `master` for deployment.
+結局、我々はまだ試行フェーズにいる ― まだデプロイの準備ができたブランチではないということ、我々は実際にデプロイのために `master` にマージしたいと思うよりずっと前からコードをレビューするためにPull Requestsを使っている。
 
-If you are stuck in the progress of your feature or branch and need help or advice, or if you are a developer and need a designer to review your work (or vice versa), or even if you have little or no code but some screenshot comps or general ideas, you open a pull request. You can cc people in the GitHub system by adding in a @username, so if you want the review or feedback of specific people, you simply cc them in the PR message (as you saw Josh do above).
+もしあなたが機能やブランチの進捗で嵌っていて助けやアドバイスが必要なら、またはもしあなたが開発者であなたの作業のレビューをしてくれるデザイナーが必要なら、あるいはたとえあなたがほとんどまたは全くコードを持っていないがスクリーンショットや一般的なアイディアがあるなら、プルリクエストをオープンするのだ。GitHubのシステム上で @ユーザ名 を追加することで人々をccすることができるので、もし特定の人のレビューやフィードバックが欲しいなら、(上でJoshがやったのを見たように)プルリクエスト・メッセージ内で単純に彼らにccすればいいのだ。
 
-This is cool because the Pull Request feature let’s you comment on individual lines in the unified diff, on single commits or on the pull request itself and pulls everything inline to a single conversation view. It also let you continue to push to the branch, so if someone comments that you forgot to do something or there is a bug in the code, you can fix it and push to the branch, GitHub will show the new commits in the conversation view and you can keep iterating on a branch like that.
+プルリクエストの機能によりunified diffや1コミット、またはプルリクエスト自体の各行にコメントを入れられて、インラインの全てを1つの会話ビューに持ってこられるので、これはクールだ。それはまたブランチにプッシュし続けられるので、もし誰かがあなたが何かをやり忘れたりコードにバグがあるとコメントすれば、あなたはそれを修正してブランチにプッシュし、GitHubが会話ビューに新しいコミットを表示して、こんな風にブランチに繰り返していられるのだ。
 
-If the branch has been open for too long and you feel it’s getting out of sync with the `master` branch, you can merge `master` into your topic branch and keep going. You can easily see in the pull request discussion or commit list when the branch was last brought up to date with the `master`.
+もしブランチがあまりに長くオープンになっていて、 `master` ブランチと同期しないようになってきたと感じたら、あなたのトピック・ブランチを `master` にマージして進み続けよう。ブランチが `master` に最後に更新したのがいつか、プルリクエストの議論やコミットリストで簡単に分かる。
 
 ![master merge](https://img.skitch.com/20110831-q5dwhwk3dut7mdqm2kp7qwqu67.png)
 
-When everything is really and truly done on the branch and you feel it’s ready to deploy, you can move on to the next step.
+ブランチですべてが本当に完了し、もうデプロイしてもいい頃だと感じた時、次のステップに進むことができる。
 
 #### #5 - マージはプルリクエストがレビューされた後だけ
 

diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -12,7 +12,7 @@
 
 私が考える大きな問題のひとつは、それが、ほとんどの開発者や開発チームが実際に必要とするよりも複雑すぎやしないか、ということだ。フローの遂行を支援するために開発された巨大な**ヘルパースクリプト**であり、あまりに複雑すぎる。
 
-クールかもしれないが、GitのGUIツールには強制できず、コマンドラインでしか使えないという問題がある。すべての手順を手動で行う必要があり、そのための複雑なワークフローをしっかりと学ばなければならない人たちというのは、コマンドラインでの作業に不慣れな人たちとイコールでもある。これは大きな問題点だ。
+クールかもしれないが、GitのGUIツールには強制することができず、コマンドラインでしか使えないという問題がある。すべての手順を手動で行う必要もある。そのための複雑なワークフローをしっかりと学ばなければならない人たちが、コマンドラインでの作業に不慣れな人たちとイコールでもある。これは大きな問題点だ。
 
 これらの問題点は、手順をもっとシンプルにするだけで容易に解決できる。GitHubでは、git-flowを使っていない。私たちが使う手順、いつも使っている手順はとてもシンプルなGitワークフローだ。
 

diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -90,7 +90,7 @@ GitHubのブランチリストページでは、最近どんなブランチで
 
 git-flowとの大きな違いのひとつが、名前を付けたブランチを定期的にサーバーにpushするという点だ。我々がデプロイの観点で本当に気にしているものは`master`だけなので、サーバーへpushすることが誰かの手を煩わせたり、混乱を引き起こしたりすることはない − `master`以外のものはすべて、単に作業中の何かだということに過ぎない。
 
-また、それによって、ノートパソコンを紛失したりハードディスクが故障した場合でも作業内容が常にバックアップされていることが確実となる。より重要なこととして、皆が定期的にコミュニケーションをとるようになる。単なる`git fetch`が、皆が作業していることについてのTODOリストを与えてくれる。
+それによって、ノートパソコンを紛失したりハードディスクが故障した場合でも作業内容が常にバックアップされていることも確実となる。より重要なこととして、皆が定期的にコミュニケーションをとるようになる。単なる`git fetch`が、皆が作業していることについてのTODOリストを与えてくれる。
 
 ```
 $ git fetch

diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -88,7 +88,7 @@ GitHubのブランチリストページでは、最近どんなブランチで
 
 #### #3 - 名前をつけたブランチに定期的にpushする
 
-git-flowとの大きな違いのひとつが、名前を付けたブランチを定期的にサーバーにpushするという点だ。我々がデプロイの観点で本当に気にしているものは`master`だけなので、サーバーへpushすることが誰かの手を煩わせたり、混乱を引き起こしたりすることはない − `master`以外のものはすべて、単に作業中のなにかだということに過ぎない。
+git-flowとの大きな違いのひとつが、名前を付けたブランチを定期的にサーバーにpushするという点だ。我々がデプロイの観点で本当に気にしているものは`master`だけなので、サーバーへpushすることが誰かの手を煩わせたり、混乱を引き起こしたりすることはない − `master`以外のものはすべて、単に作業中の何かだということに過ぎない。
 
 また、それによって、ノートパソコンを紛失したりハードディスクが故障した場合でも作業内容が常にバックアップされていることが確実となる。より重要なこととして、皆が定期的にコミュニケーションをとるようになる。単なる`git fetch`が、皆が作業していることについてのTODOリストを与えてくれる。
 

diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -88,9 +88,9 @@ GitHubのブランチリストページでは、最近どんなブランチで
 
 #### #3 - 名前をつけたブランチに定期的にpushする
 
-Another big difference from git-flow is that we push to named branches on the server constantly. Since the only thing we really have to worry about is `master` from a deployment standpoint, pushing to the server doesn’t mess anyone up or confuse things - everything that is not master is simply something being worked on.
+git-flowとの大きな違いのひとつが、名前を付けたブランチを定期的にサーバーにpushするという点だ。我々がデプロイの観点で本当に気にしているものは`master`だけなので、サーバーへpushすることが誰かの手を煩わせたり、混乱を引き起こしたりすることはない − `master`以外のものはすべて、単に作業中のなにかだということに過ぎない。
 
-It also make sure that our work is always backed up in case of laptop loss or hard drive failure. More importantly, it puts everyone in constant communication. A simple ‘git fetch’ will basically give you a TODO list of what every is currently working on.
+また、それによって、ノートパソコンを紛失したりハードディスクが故障した場合でも作業内容が常にバックアップされていることが確実となる。より重要なこととして、皆が定期的にコミュニケーションをとるようになる。単なる`git fetch`が、皆が作業していることについてのTODOリストを与えてくれる。
 
 ```
 $ git fetch
@@ -113,7 +113,7 @@ From github.com:github/github
  * [new branch]      wild-renaming -> origin/wild-renaming
  ```
 
-It also lets everyone see, by looking at the GitHub Branch List page, what everyone else is working on so they can inspect them and see if they want to help with something.
+さらにそれによって、他の皆が何をしているのかを知ったり、助けを必要としていないかを確認するためにGitHubのブランチリストページを見るよう、全員が動くことにも繋がる。
 
 #### #4 - いつでもプルリクエストを作る
 

diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -82,9 +82,9 @@ GitHubのブランチリストページでは、最近どんなブランチで
 
 ![github branch list](https://img.skitch.com/20110831-x5nyqid885aqnp7t2au5ckw929.png)
 
-It’s almost like a list of upcoming features with current rough status. This page is awesome if you’re not using it - it only shows you branches that have unique work on them relative to your currently selected branch and it sorts them so that the ones most recently worked on are at the top. If I get really curious, I can click on the ‘Compare’ button to see what the actual unified diff and commit list is that is unique to that branch.
+これは、もうすぐ実装される機能の一覧におおまかな現在の状況が付いているようなものだ。このページはとても素晴らしい − 現在選択しているブランチと比較して、それぞれのブランチがどのような固有の作業内容を含んでいるかだけが表示され、最も最近作業されたものが一番上に来る。興味を惹かれれば、Compareボタンをクリックして実際の差分を見たり、そのブランチ固有のコミット一覧を見ることもできる。
 
-So, as of this writing, we have 44 branches in our repository with unmerged work in them, but I can also see that only about 9 or 10 of them have been pushed to in the last week.
+この文章を書いている時点では、我々のリポジトリにはまだマージされていない作業を含む44のブランチがあり、そのうち先週pushされたものが9個から10個ほどあることもわかる。
 
 #### #3 - 名前をつけたブランチに定期的にpushする
 

diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -72,9 +72,13 @@ GitHub Flowとは何だろうか？
 
 #### #2 - masterから説明的なブランチを作成する
 
-When you want to start work on anything, you create a descriptively named branch off of the stable `master` branch. Some examples in the GitHub codebase right now would be `user-content-cache-key`, `submodules-init-task` or `redis2-transition`. This has several advantages - one is that when you fetch, you can see the topics that everyone else has been working on. Another is that if you abandon a branch for a while and go back to it later, it’s fairly easy to remember what it was.
+何か作業を始めたい時は、安定した`master`ブランチから説明的な名前のブランチを作成する。
+GitHubの今のコードでは、`user-content-cache-key`や`submodules-init-task`、`redis2-transition`といった感じだ。
+このやり方にはいくつか利点がある。
+fetchすると他の皆が現在作業しているトピックを知ることができる、というのが1つ。
+しばらくの間ブランチを放っておいて後からその作業に戻った時に、何をしていたかすぐに思い出せるという利点もある。
 
-This is nice because when we go to the GitHub branch list page we can easily see what branches have been worked on recently and roughly how much work they have on them.
+GitHubのブランチリストページでは、最近どんなブランチで作業がされているのか、どれくらいの作業をしているのかを大まかに知ることができるので、その点でも素晴らしい。
 
 ![github branch list](https://img.skitch.com/20110831-x5nyqid885aqnp7t2au5ckw929.png)
 

diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -63,9 +63,12 @@ GitHub Flowとは何だろうか？
 それは、そのブランチが既にデプロイされているか、または最悪の場合でも数時間以内にはデプロイされる、ということを意味する。
 ブランチが巻き戻される（作業内容を取り消すためにブランチが古いコミットを指すようにする）ことは非常に稀である − もし問題が起きたら、コミットは取り消されるか（reverted）、問題を修正した新しいコミットが行われるが、ブランチ自身がロールバックすることはほとんどない。
 
-The `master` branch is stable and it is always, always safe to deploy from it or create new branches off of it. If you push something to `master` that is not tested or breaks the build, you break the social contract of the development team and you normally feel pretty bad about it. Every branch we push has tests run on it and reported into the chat room, so if you haven’t run them locally, you can simply push to a topic branch (even a branch with a single commit) on the server and wait for **Jenkins** to tell you if it passes everything.
+`master`ブランチは安定しており、常に、そう常にデプロイ可能かつそこから新しいブランチを作成できる状態になっている。
+テストされていなかったり、ビルドを破壊するようなコードを`master`にpushした場合には、開発チーム間におけるソーシャルな取り決めを破ることになり、ちょっと気まずい思いをすることになる。
+我々がpushしたすべてのブランチではテストが実行され、その結果がチャットルームに報告される。もしテストを手元で実行していない場合には、サーバー上のトピックブランチ（たいていは1つのコミットだけのブランチ）にpushして、**Jenkins**がその結果を教えてくれるのを待つこともできる。
 
-You could have a deployed branch that is updated only when you deploy, but we don’t do that. We simply expose the currently deployed SHA through the webapp itself and curl it if we need a comparison made.
+デプロイを行った時だけ更新されるdeployedブランチを用意することもできるが、我々はそのようなことはしない。
+我々は、現在デプロイされているSHA（ハッシュ）をWebアプリ経由で公開するようにし、比較が必要な場合はそれを単にcurlするだけにしている。
 
 #### #2 - masterから説明的なブランチを作成する
 

diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -58,7 +58,7 @@ GitHub Flowとは何だろうか？
 
 #### #1 - masterブランチのものは何であれデプロイ可能である
 
-このシステムにおいて困難な*ルール*は、おおむねこの点だけである。
+このシステムにおいて困難なルールは、おおむねこの点だけである。
 明確に一貫した目的をもつ唯一のブランチがあり、それを`master`と呼ぶ。
 それは、そのブランチが既にデプロイされているか、または最悪の場合でも数時間以内にはデプロイされる、ということを意味する。
 ブランチが巻き戻される（作業内容を取り消すためにブランチが古いコミットを指すようにする）ことは非常に稀である − もし問題が起きたら、コミットは取り消されるか（reverted）、問題を修正した新しいコミットが行われるが、ブランチ自身がロールバックすることはほとんどない。

diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -58,7 +58,10 @@ GitHub Flowとは何だろうか？
 
 #### #1 - masterブランチのものは何であれデプロイ可能である
 
-This is basically the only hard *rule* of the system. There is only one branch that has any specific and consistent meaning and we named it `master`. To us, this means that it has been deployed or at the worst will be deployed within hours. It’s incredibly rare that this gets rewound (the branch is moved back to an older commit to revert work) - if there is an issue, commits will be reverted or new commits will be introduced that fixes the issue, but the branch itself is almost never rolled back.
+このシステムにおいて困難な*ルール*は、おおむねこの点だけである。
+明確に一貫した目的をもつ唯一のブランチがあり、それを`master`と呼ぶ。
+それは、そのブランチが既にデプロイされているか、または最悪の場合でも数時間以内にはデプロイされる、ということを意味する。
+ブランチが巻き戻される（作業内容を取り消すためにブランチが古いコミットを指すようにする）ことは非常に稀である − もし問題が起きたら、コミットは取り消されるか（reverted）、問題を修正した新しいコミットが行われるが、ブランチ自身がロールバックすることはほとんどない。
 
 The `master` branch is stable and it is always, always safe to deploy from it or create new branches off of it. If you push something to `master` that is not tested or breaks the build, you break the social contract of the development team and you normally feel pretty bad about it. Every branch we push has tests run on it and reported into the chat room, so if you haven’t run them locally, you can simply push to a topic branch (even a branch with a single commit) on the server and wait for **Jenkins** to tell you if it passes everything.
 

diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -58,14 +58,109 @@ GitHub Flowとは何だろうか？
 
 #### #1 - masterブランチのものは何であれデプロイ可能である
 
+This is basically the only hard *rule* of the system. There is only one branch that has any specific and consistent meaning and we named it `master`. To us, this means that it has been deployed or at the worst will be deployed within hours. It’s incredibly rare that this gets rewound (the branch is moved back to an older commit to revert work) - if there is an issue, commits will be reverted or new commits will be introduced that fixes the issue, but the branch itself is almost never rolled back.
+
+The `master` branch is stable and it is always, always safe to deploy from it or create new branches off of it. If you push something to `master` that is not tested or breaks the build, you break the social contract of the development team and you normally feel pretty bad about it. Every branch we push has tests run on it and reported into the chat room, so if you haven’t run them locally, you can simply push to a topic branch (even a branch with a single commit) on the server and wait for **Jenkins** to tell you if it passes everything.
+
+You could have a deployed branch that is updated only when you deploy, but we don’t do that. We simply expose the currently deployed SHA through the webapp itself and curl it if we need a comparison made.
+
 #### #2 - masterから説明的なブランチを作成する
 
+When you want to start work on anything, you create a descriptively named branch off of the stable `master` branch. Some examples in the GitHub codebase right now would be `user-content-cache-key`, `submodules-init-task` or `redis2-transition`. This has several advantages - one is that when you fetch, you can see the topics that everyone else has been working on. Another is that if you abandon a branch for a while and go back to it later, it’s fairly easy to remember what it was.
+
+This is nice because when we go to the GitHub branch list page we can easily see what branches have been worked on recently and roughly how much work they have on them.
+
+![github branch list](https://img.skitch.com/20110831-x5nyqid885aqnp7t2au5ckw929.png)
+
+It’s almost like a list of upcoming features with current rough status. This page is awesome if you’re not using it - it only shows you branches that have unique work on them relative to your currently selected branch and it sorts them so that the ones most recently worked on are at the top. If I get really curious, I can click on the ‘Compare’ button to see what the actual unified diff and commit list is that is unique to that branch.
+
+So, as of this writing, we have 44 branches in our repository with unmerged work in them, but I can also see that only about 9 or 10 of them have been pushed to in the last week.
+
 #### #3 - 名前をつけたブランチに定期的にpushする
 
+Another big difference from git-flow is that we push to named branches on the server constantly. Since the only thing we really have to worry about is `master` from a deployment standpoint, pushing to the server doesn’t mess anyone up or confuse things - everything that is not master is simply something being worked on.
+
+It also make sure that our work is always backed up in case of laptop loss or hard drive failure. More importantly, it puts everyone in constant communication. A simple ‘git fetch’ will basically give you a TODO list of what every is currently working on.
+
+```
+$ git fetch
+remote: Counting objects: 3032, done.
+remote: Compressing objects: 100% (947/947), done.
+remote: Total 2672 (delta 1993), reused 2328 (delta 1689)
+Receiving objects: 100% (2672/2672), 16.45 MiB | 1.04 MiB/s, done.
+Resolving deltas: 100% (1993/1993), completed with 213 local objects.
+From github.com:github/github
+ * [new branch]      charlock-linguist -> origin/charlock-linguist
+ * [new branch]      enterprise-non-config -> origin/enterprise-non-config
+ * [new branch]      fi-signup  -> origin/fi-signup
+   2647a42..4d6d2c2  git-http-server -> origin/git-http-server
+ * [new branch]      knyle-style-commits -> origin/knyle-style-commits
+   157d2b0..d33e00d  master     -> origin/master
+ * [new branch]      menu-behavior-act-i -> origin/menu-behavior-act-i
+   ea1c5e2..dfd315a  no-inline-js-config -> origin/no-inline-js-config
+ * [new branch]      svg-tests  -> origin/svg-tests
+   87bb870..9da23f3  view-modes -> origin/view-modes
+ * [new branch]      wild-renaming -> origin/wild-renaming
+ ```
+
+It also lets everyone see, by looking at the GitHub Branch List page, what everyone else is working on so they can inspect them and see if they want to help with something.
+
 #### #4 - いつでもプルリクエストを作る
 
+GitHub has an amazing code review system called **Pull Requests** that I fear not enough people know about. Many people use it for open source work - fork a project, update the project, send a pull request to the maintainer. However, it can also easily be used as an internal code review system, which is what we do.
+
+Actually, we use it more as a branch conversation view more than a pull request. You can send pull requests from one branch to another in a single project (public or private) in GitHub, so you can use them to say “I need help or review on this” in addition to “Please merge this in”.
+
+![early pr message](https://img.skitch.com/20110831-1mft7b5nbxrcghasbi9hkbs84s.png)
+
+Here you can see Josh cc’ing Brian for review and Brian coming in with some advice on one of the lines of code. Further down we can see Josh acknowledging Brian’s concerns and pushing more code to address them.
+
+![more discussion](https://img.skitch.com/20110831-j181q96hh7k8x2e1iuh38jsc8a.png)
+
+Finally you can see that we’re still in the trial phase - this is not a deployment ready branch yet, we use the Pull Requests to review the code long before we actually want to merge it into `master` for deployment.
+
+If you are stuck in the progress of your feature or branch and need help or advice, or if you are a developer and need a designer to review your work (or vice versa), or even if you have little or no code but some screenshot comps or general ideas, you open a pull request. You can cc people in the GitHub system by adding in a @username, so if you want the review or feedback of specific people, you simply cc them in the PR message (as you saw Josh do above).
+
+This is cool because the Pull Request feature let’s you comment on individual lines in the unified diff, on single commits or on the pull request itself and pulls everything inline to a single conversation view. It also let you continue to push to the branch, so if someone comments that you forgot to do something or there is a bug in the code, you can fix it and push to the branch, GitHub will show the new commits in the conversation view and you can keep iterating on a branch like that.
+
+If the branch has been open for too long and you feel it’s getting out of sync with the `master` branch, you can merge `master` into your topic branch and keep going. You can easily see in the pull request discussion or commit list when the branch was last brought up to date with the `master`.
+
+![master merge](https://img.skitch.com/20110831-q5dwhwk3dut7mdqm2kp7qwqu67.png)
+
+When everything is really and truly done on the branch and you feel it’s ready to deploy, you can move on to the next step.
+
 #### #5 - マージはプルリクエストがレビューされた後だけ
 
+We don’t simply do work directly on `master` or work on a topic branch and merge it in when we think it’s done - we try to get signoff from someone else in the company. This is generally a +1 or emoji or “:shipit:” comment, but we try to get someone else to look at it.
+
+![shipit comment](https://img.skitch.com/20110831-8gg3uhb14adjis43wa6swiinik.png)
+
+Once we get that, and the branch passes CI, we can merge it into master for deployment, which will automatically close the Pull Request when we push it.
+
 #### #6 - レビューのあとは直ちにデプロイする
 
+Finally, your work is done and merged into the master branch. This means that even if you don’t deploy it now, people will base new work off of it and the next deploy, which will likely happen in a few hours, will push it out. So since you really don’t want someone else to push something that you wrote that breaks things, people tend to make sure that it really is stable when it’s merged and people also tend to push their own changes.
+
+Our campfire bot, hubot, can do deployments for any of the employees, so a simple:
+
+```
+hubot depoy github to production
+```
+
+will deploy the code and zero-downtime restart all the necessary processes. You can see how common this is at GitHub:
+
+![our campfire logs](https://img.skitch.com/20110831-jcmx5qktw5beabq7q1rcpj1k6c.png)
+
+You can see 6 different people (including a support guy and a designer) deploying about 24 times in one day.
+
+I have done this for branches with one commit containing a one line change. The process is simple, straightforward, scalable and powerful. You can do it with feature branches with 50 commits on them that took 2 weeks, or 1 commit that took 10 minutes. It is such a simple and frictionless process that you are not annoyed that you have to do it even for 1 commit, which means people rarely try to skip or bypass the process unless the change is so small or insignificant that it just doesn’t matter.
+
+This is an incredibly simple and powerful process. I think most people would agree that GitHub has a very stable platform, that issues are addressed quickly if they ever come up at all, and that new features are introduced at a rapid pace. There is no compromise of quality or stability so that we can get more speed or simplicity or less process.
+
 ## まとめ
+
+Git itself is fairly complex to understand, making the workflow that you use with it more complex than necessary is simply adding more mental overhead to everybody’s day. I would always advocate using the simplest possible system that will work for your team and doing so until it doesn’t work anymore and then adding complexity only as absolutely needed.
+
+For teams that have to do formal releases on a longer term interval (a few weeks to a few months between releases), and be able to do hot-fixes and maintenance branches and other things that arise from shipping so infrequently, git-flow makes sense and I would highly advocate it’s use.
+
+For teams that have set up a culture of shipping, who push to production every day, who are constantly testing and deploying, I would advocate picking something simpler like GitHub Flow.
diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -40,6 +40,22 @@ git-flowのプロセスは主として「リリース」を中心に設計され
 
 ### どうやっているのか
 
+GitHub Flowとは何だろうか？
+
+* `master`ブランチのものは何であれデプロイ可能である
+* 新しい何かに取り組む際は、説明的な名前のブランチをmasterから作成する（例: `new-oauth2-scopes`）
+* 作成したブランチにローカルでコミットし、サーバー上の同じ名前のブランチにも定期的に作業内容をpushする
+* フィードバックや助言が欲しい時、ブランチをマージしてもよいと思ったときは、**プルリクエスト**を作成する
+* 他の誰かがレビューをして機能にOKを出してくれたら、あなたはコードを`master`へマージすることができる
+* マージをして`master`へpushしたら、直ちにデプロイをする
+
+これがフローのすべてだ。
+とてもシンプルかつ効率的で、かなり大きなチームでも機能する。現在GitHubは35人で、そのうちの約15〜20人が一度に同じプロジェクト（github.com）で作業している（訳注：数字は2011年8月時点のもの）。
+ほとんどの開発チーム（同時期に同じコードで作業をし、コンフリクトを発生させる可能性のある集団）はこれくらいか、もっと小さいと思う。
+とりわけ、迅速に一貫したデプロイを行なうような進歩的なチームなら。
+
+では、各ステップを順に見て行こう。
+
 #### #1 - masterブランチのものは何であれデプロイ可能である
 
 #### #2 - masterから説明的なブランチを作成する

diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -38,18 +38,18 @@ git-flowのプロセスは主として「リリース」を中心に設計され
 
 すべてが同じプロセスであり、すべてがとてもシンプルだ。
 
-### How We Do It
+### どうやっているのか
 
-#### #1 - ANYTHING IN THE MASTER BRANCH IS DEPLOYABLE
+#### #1 - masterブランチのものは何であれデプロイ可能である
 
-#### #2 - CREATE DESCRIPTIVE BRANCHES OFF OF MASTER
+#### #2 - masterから説明的なブランチを作成する
 
-#### #3 - PUSH TO NAMED BRANCHES CONSTANTLY
+#### #3 - 名前をつけたブランチに定期的にpushする
 
-#### #4 - OPEN A PULL REQUEST AT ANY TIME
+#### #4 - いつでもプルリクエストを作る
 
-#### #5 - MERGE ONLY AFTER PULL REQUEST REVIEW
+#### #5 - マージはプルリクエストがレビューされた後だけ
 
-#### #6 - DEPLOY IMMEDIATELY AFTER REVIEW
+#### #6 - レビューのあとは直ちにデプロイする
 
-## Conclusion
+## まとめ
diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -30,7 +30,7 @@ git-flowのプロセスは主として「リリース」を中心に設計され
 定期的にデプロイを行うことにはいくつかの利点がある。
 数時間毎にデプロイをすれば、大きなバグが沢山入るようなことはほぼありえない。
 小さなバグが入ることはあるだろうが、そういったものは素早く修正して再デプロイすることができる。
-本来なら「hotfix」ブランチや普段の手順とは違う形で修正を行おうとするだろうが、私たちの場合それは通常のプロセスの一貫でしかない。GitHubのやり方では、hotfixとと小さな機能追加とで違いはまったくない。
+本来なら「hotfix」ブランチや普段の手順とは違う形で修正を行おうとするだろうが、私たちの場合はそれも通常のプロセスの一貫でしかない。GitHubのやり方では、hotfixと小さな機能追加とに違いはまったくない。
 
 四六時中デプロイすることのもうひとつの利点は、あらゆる種類の問題を迅速に解決することが可能になる点だ。
 私たちは、セキュリティ上の問題や、小さいけれども重要な機能の要望にとても迅速に対応することができる。

diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -20,6 +20,24 @@
 
 ## GitHub Flow
 
+さて、なぜGitHubではgit-flowを使わないのだろうか？
+私たちが常にデプロイをするから、というのが主な理由ではある。
+git-flowのプロセスは主として「リリース」を中心に設計されている。
+私たちはプロダクション環境へのデプロイを毎日（たいていは日に何回も）行うため、「リリース」というものがない。
+私たちはチャットルーム内のロボットを通じてデプロイをすることができ、そこにはCIの結果も表示される。
+私たちはテストとデプロイの手順を可能な限りシンプルにするようにしており、それらをすべての従業員が安心して行うことができる。
+
+定期的にデプロイを行うことにはいくつかの利点がある。
+数時間毎にデプロイをすれば、大きなバグが沢山入るようなことはほぼありえない。
+小さなバグが入ることはあるだろうが、そういったものは素早く修正して再デプロイすることができる。
+本来なら「hotfix」ブランチや普段の手順とは違う形で修正を行おうとするだろうが、私たちの場合それは通常のプロセスの一貫でしかない。GitHubのやり方では、hotfixとと小さな機能追加とで違いはまったくない。
+
+四六時中デプロイすることのもうひとつの利点は、あらゆる種類の問題を迅速に解決することが可能になる点だ。
+私たちは、セキュリティ上の問題や、小さいけれども重要な機能の要望にとても迅速に対応することができる。
+そして、それらの変更に対処する際は、普段の開発や大きな機能の開発をする際に使うのとまったく同じプロセスを使うことができる。
+
+すべてが同じプロセスであり、すべてがとてもシンプルだ。
+
 ### How We Do It
 
 #### #1 - ANYTHING IN THE MASTER BRANCH IS DEPLOYABLE

diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -8,16 +8,15 @@
 
 私は人々にGitを教えるためにあちこちを飛び回っているが、最近のほぼすべてのクラスやワークショップで**git-flow**についてどう思うかを尋ねられた。私はいつも、git-flowは素晴らしいと思うと答えている。何百万ものワークフローを持ったシステム（Git）を提供し、ドキュメントもあるし、よくテストされている。フレキシブルなワークフローは、実に容易なやり方で多くの開発者の役に立つ。標準的なものになりつつあり、開発者はプロジェクトや企業の間を移動しつつこの標準的なワークフローに馴染むことができる。
 
-しかしながら、それ故の問題も抱えている。新しいフィーチャーブランチをmasterではなくdevelopから開始するとか、hotfixesを扱う方法といったことを好まないような人たちから多くの意見をもらう。
+しかしながら、それ故の問題も抱えている。新しいフィーチャーブランチをmasterではなくdevelopから開始するとか、hotfixesを扱う方法といったことを好まないような人たちから多くの意見を聞く。
 
 私が考える大きな問題のひとつは、それが、ほとんどの開発者や開発チームが実際に必要とするよりも複雑すぎやしないか、ということだ。フローの遂行を支援するために開発された巨大な**ヘルパースクリプト**であり、あまりに複雑すぎる。
 
-クールではあるが、GitのGUIには強制できず、コマンドラインでしか使えないという問題がある。
-すべての手順を手動で行う必要があるため、複雑なワークフローをしっかりと学ばなければならない人たちは、コマンドラインでの作業に不慣れな人たちとイコールである。これは大きな問題点だ。
+クールかもしれないが、GitのGUIツールには強制できず、コマンドラインでしか使えないという問題がある。すべての手順を手動で行う必要があり、そのための複雑なワークフローをしっかりと学ばなければならない人たちというのは、コマンドラインでの作業に不慣れな人たちとイコールでもある。これは大きな問題点だ。
 
-これらの問題点は、手順をもっとシンプルにするだけで容易に解決することができる。GitHubでは、git-flowを使っていない。我々が使う手順、いつも使っている手順はとてもシンプルなGitワークフローだ。
+これらの問題点は、手順をもっとシンプルにするだけで容易に解決できる。GitHubでは、git-flowを使っていない。私たちが使う手順、いつも使っている手順はとてもシンプルなGitワークフローだ。
 
-そのシンプルさには多くの利点がある。ひとつは、簡単に理解できるということ。そのため、より早く作業ができ、何かを台無しにしてしまったり、間違ってしまった手順をやり直すといったこともめったに起こらない。他に、プロセスを支援するためのラッパースクリプトが必要ないので、GUIプログラムも問題なく使えるという利点もある。
+そのシンプルさには多くのメリットがある。ひとつは、簡単に理解できるということ。より素早く作業ができ、何かを台無しにしてしまうとか間違ってしまった手順をやり直すといったこともめったに起こらない。他にも、プロセスを支援するためのラッパースクリプトが必要ないため、GUIプログラムも問題なく使えるというメリットもある。
 
 ## GitHub Flow
 

diff --git a/github-flow.ja.md b/github-flow.ja.md
@@ -0,0 +1,38 @@
+# GitHub Flow
+
+* [Scott Chacon on the Interwebs](http://scottchacon.com/2011/08/31/github-flow.html)
+
+31 Aug 2011
+
+## git-flowの問題点 (Issues with git-flow)
+
+私は人々にGitを教えるためにあちこちを飛び回っているが、最近のほぼすべてのクラスやワークショップで**git-flow**についてどう思うかを尋ねられた。私はいつも、git-flowは素晴らしいと思うと答えている。何百万ものワークフローを持ったシステム（Git）を提供し、ドキュメントもあるし、よくテストされている。フレキシブルなワークフローは、実に容易なやり方で多くの開発者の役に立つ。標準的なものになりつつあり、開発者はプロジェクトや企業の間を移動しつつこの標準的なワークフローに馴染むことができる。
+
+しかしながら、それ故の問題も抱えている。新しいフィーチャーブランチをmasterではなくdevelopから開始するとか、hotfixesを扱う方法といったことを好まないような人たちから多くの意見をもらう。
+
+私が考える大きな問題のひとつは、それが、ほとんどの開発者や開発チームが実際に必要とするよりも複雑すぎやしないか、ということだ。フローの遂行を支援するために開発された巨大な**ヘルパースクリプト**であり、あまりに複雑すぎる。
+
+クールではあるが、GitのGUIには強制できず、コマンドラインでしか使えないという問題がある。
+すべての手順を手動で行う必要があるため、複雑なワークフローをしっかりと学ばなければならない人たちは、コマンドラインでの作業に不慣れな人たちとイコールである。これは大きな問題点だ。
+
+これらの問題点は、手順をもっとシンプルにするだけで容易に解決することができる。GitHubでは、git-flowを使っていない。我々が使う手順、いつも使っている手順はとてもシンプルなGitワークフローだ。
+
+そのシンプルさには多くの利点がある。ひとつは、簡単に理解できるということ。そのため、より早く作業ができ、何かを台無しにしてしまったり、間違ってしまった手順をやり直すといったこともめったに起こらない。他に、プロセスを支援するためのラッパースクリプトが必要ないので、GUIプログラムも問題なく使えるという利点もある。
+
+## GitHub Flow
+
+### How We Do It
+
+#### #1 - ANYTHING IN THE MASTER BRANCH IS DEPLOYABLE
+
+#### #2 - CREATE DESCRIPTIVE BRANCHES OFF OF MASTER
+
+#### #3 - PUSH TO NAMED BRANCHES CONSTANTLY
+
+#### #4 - OPEN A PULL REQUEST AT ANY TIME
+
+#### #5 - MERGE ONLY AFTER PULL REQUEST REVIEW
+
+#### #6 - DEPLOY IMMEDIATELY AFTER REVIEW
+
+## Conclusion