Merge pull request #26 from sutatoruta/fix/typo

typoとリンク切れの修正

README.md

@@ -143,7 +143,7 @@
 * [講義スライド](https://speakerdeck.com/kaityo256/github-practice-github-advanced)
 * MNISTの学習済みモデルをウェブで試す
 * 簡単なゲーム作成
-* 余談：余談：CEOからのメッセージ
+* 余談：CEOからのメッセージ
 
 ## [おわりに](postface/README.md)
 

advanced/README.md

@@ -240,7 +240,7 @@ Dropped refs/stash@{0} (171f9ddd0c02ed7e7ed9105aa9ef30f3553aa742)
 
 これにより、あたかも「最初から`feature`ブランチを切ってから修正をした」ような状態となった。あとはキリの良いところまで作業してコミットし、`main`ブランチにマージするなりその前にリベースするなりすれば良い。うっかりメインブランチで作業を開始しがちな人(例えば私)は覚えておきたいコマンドだ。
 
-なお、`git stash`を実行するたびに修正が詰みあがっていく。それぞれに`stash@{0}`、`stash@{1}`という名前がつき、`git stash apply`により名前を指定して適用することもできる。しかし、その場合は適用した修正がスタックに残るため、後で`git stash drop`で消さなければならない。一方、`git stash pop`は、最後に積んだ修正を適用し、その修正をスタックから削除する。
+なお、`git stash`を実行するたびに修正が積みあがっていく。それぞれに`stash@{0}`、`stash@{1}`という名前がつき、`git stash apply`により名前を指定して適用することもできる。しかし、その場合は適用した修正がスタックに残るため、後で`git stash drop`で消さなければならない。一方、`git stash pop`は、最後に積んだ修正を適用し、その修正をスタックから削除する。
 
 あまり積むと後で見てわからなくなるので、原則として`git stash`は`git stash pop`と対で利用すると良い。
 

advanced/index.html

@@ -215,7 +215,7 @@ <h1 class="title">Gitの使い方(応用編)</h1>
 <span id="cb22-11"><a href="#cb22-11" aria-hidden="true" tabindex="-1"></a><span class="ex">no</span> changes added to commit <span class="er">(</span><span class="ex">use</span> <span class="st">&quot;git add&quot;</span> and/or <span class="st">&quot;git commit -a&quot;</span><span class="kw">)</span></span>
 <span id="cb22-12"><a href="#cb22-12" aria-hidden="true" tabindex="-1"></a><span class="ex">Dropped</span> refs/stash@{0} <span class="er">(</span><span class="ex">171f9ddd0c02ed7e7ed9105aa9ef30f3553aa742</span><span class="kw">)</span></span></code></pre></div>
                   <p>これにより、あたかも「最初から<code>feature</code>ブランチを切ってから修正をした」ような状態となった。あとはキリの良いところまで作業してコミットし、<code>main</code>ブランチにマージするなりその前にリベースするなりすれば良い。うっかりメインブランチで作業を開始しがちな人(例えば私)は覚えておきたいコマンドだ。</p>
-                  <p>なお、<code>git stash</code>を実行するたびに修正が詰みあがっていく。それぞれに<code>stash@{0}</code>、<code>stash@{1}</code>という名前がつき、<code>git stash apply</code>により名前を指定して適用することもできる。しかし、その場合は適用した修正がスタックに残るため、後で<code>git stash drop</code>で消さなければならない。一方、<code>git stash pop</code>は、最後に積んだ修正を適用し、その修正をスタックから削除する。</p>
+                  <p>なお、<code>git stash</code>を実行するたびに修正が積みあがっていく。それぞれに<code>stash@{0}</code>、<code>stash@{1}</code>という名前がつき、<code>git stash apply</code>により名前を指定して適用することもできる。しかし、その場合は適用した修正がスタックに残るため、後で<code>git stash drop</code>で消さなければならない。一方、<code>git stash pop</code>は、最後に積んだ修正を適用し、その修正をスタックから削除する。</p>
                   <p>あまり積むと後で見てわからなくなるので、原則として<code>git stash</code>は<code>git stash pop</code>と対で利用すると良い。</p>
                   <h2
                   id="プッシュしようとしたらリジェクトされた">プッシュしようとしたらリジェクトされた</h2>

branch/README.md

@@ -10,7 +10,7 @@ Gitは「玉(コミット)」と「線(コミット間の関係)」で構成さ
 
 ## なぜブランチをわけるか
 
-現代においてソフトウェア開発を完全に一人で開発することは稀であり、多くの場合、複数人で分担して開発することになるだろう。開発者が同じソフトウェアに対してばらばらに修正を加えたらプロジェクトが混乱することが予想されるであろう。その「交通整理」を行うためのスールが**ワークフロー (workflow)** である。
+現代においてソフトウェア開発を完全に一人で開発することは稀であり、多くの場合、複数人で分担して開発することになるだろう。開発者が同じソフトウェアに対してばらばらに修正を加えたらプロジェクトが混乱することが予想されるであろう。その「交通整理」を行うためのルールが**ワークフロー (workflow)** である。
 
 今、AliceとBobの二人が開発するプロジェクトがあったとしよう。Aliceは機能Aを、Bobは機能Bを開発することになった。機能Aの実現には、サブモジュールA1とA2を実装する必要があるが、A1を実装しただけではプログラムが正しく動作せず、A2まで実装して初めて全体として正しく動作する。
 
@@ -50,7 +50,7 @@ Aliceは機能Aを実装するため、`main`ブランチから`feature_A`ブラ
 
 ![current_branch.png](fig/current_branch.png)
 
-今、カレントブランチが`branch`だとしよう。カレントブランチとは、`HEAD`というラベルが指すブランチのことなので、`HEAD`は`branch`を指してしている。あるブランチ`branch`が、別のブランチ`other`と同じコミットを指していたとする。この状態でコミットをすると、新たにコミットが作られ、カレントブランチが指すコミットにつなげられることで歴史が伸びる。そして、カレントブランチは新たに作られたコミットを指す。具体的には、`HEAD`が`branch`を指したまま、`branch`が新たにできたコミットを差す。この時、カレントブランチ以外のブランチは移動しないことに注意。この状態でカレントブランチを`other`に変更してコミットをすると、歴史が分岐することになる。
+今、カレントブランチが`branch`だとしよう。カレントブランチとは、`HEAD`というラベルが指すブランチのことなので、`HEAD`は`branch`を指している。あるブランチ`branch`が、別のブランチ`other`と同じコミットを指していたとする。この状態でコミットをすると、新たにコミットが作られ、カレントブランチが指すコミットにつなげられることで歴史が伸びる。そして、カレントブランチは新たに作られたコミットを指す。具体的には、`HEAD`が`branch`を指したまま、`branch`が新たにできたコミットを指す。この時、カレントブランチ以外のブランチは移動しないことに注意。この状態でカレントブランチを`other`に変更してコミットをすると、歴史が分岐することになる。
 
 ### コミットと差分
 
@@ -178,7 +178,7 @@ $ git branch -D branch
 Deleted branch branch (was f59b8e4).
 ```
 
-なお、このエラーが出る条件は、「カレントブランチからたどることができる歴史のコミットを指しているかどうか」である。したがって、以下のような歴史がある場合、カレントブランチが`main`の時には`old_branch`は`git branch -d`では消せないが、カレントブランチが`latest_branch`の場合は`old_branch`を消すことができる。
+なお、このエラーが出る条件は、「カレントブランチからたどることができる歴史のコミットを指しているかどうか」である。したがって、以下のような歴史がある場合、カレントブランチが`main`の時には`old_branch`は`git branch -d`では消せないが、カレントブランチが`new_branch`の場合は`old_branch`を消すことができる。
 
 ![tadoreru.png](fig/tadoreru.png)
 

branch/index.html

@@ -54,7 +54,7 @@ <h1 id="はじめに">はじめに</h1>
                   <p>以下では、特になぜブランチが必要か、ブランチを使ってどのように開発を進めるのか、「歴史を分岐、改変する」とはどういうことかについて説明する。</p>
                   <h1
                   id="なぜブランチをわけるか">なぜブランチをわけるか</h1>
-                  <p>現代においてソフトウェア開発を完全に一人で開発することは稀であり、多くの場合、複数人で分担して開発することになるだろう。開発者が同じソフトウェアに対してばらばらに修正を加えたらプロジェクトが混乱することが予想されるであろう。その「交通整理」を行うためのスールが<strong>ワークフロー
+                  <p>現代においてソフトウェア開発を完全に一人で開発することは稀であり、多くの場合、複数人で分担して開発することになるだろう。開発者が同じソフトウェアに対してばらばらに修正を加えたらプロジェクトが混乱することが予想されるであろう。その「交通整理」を行うためのルールが<strong>ワークフロー
                   (workflow)</strong> である。</p>
                   <p>今、AliceとBobの二人が開発するプロジェクトがあったとしよう。Aliceは機能Aを、Bobは機能Bを開発することになった。機能Aの実現には、サブモジュールA1とA2を実装する必要があるが、A1を実装しただけではプログラムが正しく動作せず、A2まで実装して初めて全体として正しく動作する。</p>
                   <figure>
@@ -103,7 +103,7 @@ <h1 id="ブランチの基本">ブランチの基本</h1>
                   <figcaption
                   aria-hidden="true">current_branch.png</figcaption>
                   </figure>
-                  <p>今、カレントブランチが<code>branch</code>だとしよう。カレントブランチとは、<code>HEAD</code>というラベルが指すブランチのことなので、<code>HEAD</code>は<code>branch</code>を指してしている。あるブランチ<code>branch</code>が、別のブランチ<code>other</code>と同じコミットを指していたとする。この状態でコミットをすると、新たにコミットが作られ、カレントブランチが指すコミットにつなげられることで歴史が伸びる。そして、カレントブランチは新たに作られたコミットを指す。具体的には、<code>HEAD</code>が<code>branch</code>を指したまま、<code>branch</code>が新たにできたコミットを差す。この時、カレントブランチ以外のブランチは移動しないことに注意。この状態でカレントブランチを<code>other</code>に変更してコミットをすると、歴史が分岐することになる。</p>
+                  <p>今、カレントブランチが<code>branch</code>だとしよう。カレントブランチとは、<code>HEAD</code>というラベルが指すブランチのことなので、<code>HEAD</code>は<code>branch</code>を指している。あるブランチ<code>branch</code>が、別のブランチ<code>other</code>と同じコミットを指していたとする。この状態でコミットをすると、新たにコミットが作られ、カレントブランチが指すコミットにつなげられることで歴史が伸びる。そして、カレントブランチは新たに作られたコミットを指す。具体的には、<code>HEAD</code>が<code>branch</code>を指したまま、<code>branch</code>が新たにできたコミットを指す。この時、カレントブランチ以外のブランチは移動しないことに注意。この状態でカレントブランチを<code>other</code>に変更してコミットをすると、歴史が分岐することになる。</p>
                   <h2 id="コミットと差分">コミットと差分</h2>
                   <figure>
                   <img src="fig/commit.png" alt="commit.png" />
@@ -212,7 +212,7 @@ <h2 id="ブランチの削除">ブランチの削除</h2>
                   <div class="sourceCode" id="cb9"><pre
                   class="sourceCode sh"><code class="sourceCode bash"><span id="cb9-1"><a href="#cb9-1" aria-hidden="true" tabindex="-1"></a><span class="ex">$</span> git branch <span class="at">-D</span> branch</span>
 <span id="cb9-2"><a href="#cb9-2" aria-hidden="true" tabindex="-1"></a><span class="ex">Deleted</span> branch branch <span class="er">(</span><span class="ex">was</span> f59b8e4<span class="kw">)</span><span class="bu">.</span></span></code></pre></div>
-                  <p>なお、このエラーが出る条件は、「カレントブランチからたどることができる歴史のコミットを指しているかどうか」である。したがって、以下のような歴史がある場合、カレントブランチが<code>main</code>の時には<code>old_branch</code>は<code>git branch -d</code>では消せないが、カレントブランチが<code>latest_branch</code>の場合は<code>old_branch</code>を消すことができる。</p>
+                  <p>なお、このエラーが出る条件は、「カレントブランチからたどることができる歴史のコミットを指しているかどうか」である。したがって、以下のような歴史がある場合、カレントブランチが<code>main</code>の時には<code>old_branch</code>は<code>git branch -d</code>では消せないが、カレントブランチが<code>new_branch</code>の場合は<code>old_branch</code>を消すことができる。</p>
                   <figure>
                   <img src="fig/tadoreru.png" alt="tadoreru.png" />
                   <figcaption

command/README.md

@@ -258,7 +258,7 @@ $ cp -r dir1 dir2 # dir2が無い場合はその場所にコピー、ある場
 
 #### `rm`,`rmdir`
 
-ファイルを削除するには`rm`を使う。なお、中身が空ではないいディレクトリを削除する場合は`rm -r dir`と`-r`オプションを付ける必要があるが、再帰的に全てのファイル、サブディレクトリが削除されてしまうので、慣れないうちは実行しない方がよい。また、空のディレクトリを削除するために`rmdir`というコマンドがあるが、普段使うことは少ないので「`mkdir`の対になるコマンドが`rmdir`」とだけ覚えておけばよいだろう。
+ファイルを削除するには`rm`を使う。なお、中身が空ではないディレクトリを削除する場合は`rm -r dir`と`-r`オプションを付ける必要があるが、再帰的に全てのファイル、サブディレクトリが削除されてしまうので、慣れないうちは実行しない方がよい。また、空のディレクトリを削除するために`rmdir`というコマンドがあるが、普段使うことは少ないので「`mkdir`の対になるコマンドが`rmdir`」とだけ覚えておけばよいだろう。
 
 #### `cat`
 

command/index.html

@@ -262,7 +262,7 @@ <h3 id="cp"><code>cp</code></h3>
 <span id="cb19-3"><a href="#cb19-3" aria-hidden="true" tabindex="-1"></a><span class="ex">$</span> cp <span class="at">-r</span> dir1 dir2 <span class="co"># dir2が無い場合はその場所にコピー、ある場合はdir2の下にコピー</span></span></code></pre></div>
                   <h3
                   id="rmrmdir"><code>rm</code>,<code>rmdir</code></h3>
-                  <p>ファイルを削除するには<code>rm</code>を使う。なお、中身が空ではないいディレクトリを削除する場合は<code>rm -r dir</code>と<code>-r</code>オプションを付ける必要があるが、再帰的に全てのファイル、サブディレクトリが削除されてしまうので、慣れないうちは実行しない方がよい。また、空のディレクトリを削除するために<code>rmdir</code>というコマンドがあるが、普段使うことは少ないので「<code>mkdir</code>の対になるコマンドが<code>rmdir</code>」とだけ覚えておけばよいだろう。</p>
+                  <p>ファイルを削除するには<code>rm</code>を使う。なお、中身が空ではないディレクトリを削除する場合は<code>rm -r dir</code>と<code>-r</code>オプションを付ける必要があるが、再帰的に全てのファイル、サブディレクトリが削除されてしまうので、慣れないうちは実行しない方がよい。また、空のディレクトリを削除するために<code>rmdir</code>というコマンドがあるが、普段使うことは少ないので「<code>mkdir</code>の対になるコマンドが<code>rmdir</code>」とだけ覚えておけばよいだろう。</p>
                   <h3 id="cat"><code>cat</code></h3>
                   <p>ファイルの中身を表示するには<code>cat</code>を使う。これは<code>concatenate</code>(連結する)の略で、複数のファイルを指定することで結合ができるが、ここではファイル内容の表示にしか使わない。</p>
                   <div class="sourceCode" id="cb20"><pre

index.html

@@ -227,7 +227,7 @@ <h2 id="githubの操作応用編"><a
                   href="https://speakerdeck.com/kaityo256/github-practice-github-advanced">講義スライド</a></li>
                   <li>MNISTの学習済みモデルをウェブで試す</li>
                   <li>簡単なゲーム作成</li>
-                  <li>余談：余談：CEOからのメッセージ</li>
+                  <li>余談：CEOからのメッセージ</li>
                   </ul>
                   <h1 id="おわりに"><a
                   href="postface/index.html">おわりに</a></h1>