Webcast • Github for Project Management

(シンシア) 皆さん こんにちは

ウェビナー開始１分前なので

ちゃんと聞こえているかどうか

オーディオのチェックを行いますね

画面にアンケートを出したので

聞こえ具合について教えてください

(アレン) いいですね

(シンシア) 参加者も集まって
ちゃんと聞こえているようですね

ちょうど12時になったので
始めることにしましょう

まず自己紹介しますね
私はシンシア・リッチといいます

GitHub Teacherです
今日はアレン・スミスという―

もう１人のGitHub Teacherも一緒です

今日はトピックを通じて

皆さんにも関連する
私たちの経験を共有したいと思います

このセッションでは
プロジェクト・マネジメントと

GitHubを使ってプロジェクトを
管理する方法についてです

では手短に 誰が電話に―

いえ ウェビナーに参加しているか

知るためにアンケートを出しました

あなたのプロジェクト・マネジメントの
経験を教えてください

皆さんが答えている間に

今日の目標についてお話します

今日のウェビナーでは
GitHubの仕組みを使って

プロジェクトを管理するための

良い方法をいくつかお教えします

私たちはすべてのプロジェクトを
このプラットフォームで管理し

会話ややり取りをすべて
ここに記録します

お伝えしたいのは
効果的にこれを用いて

チーム内で効果的なコラボレーションと

コミュニケーションが
行えるようにする秘訣です

さて 結果を見ると―
いいですね

プロジェクト・マネジメントの

経験豊富な人たちと

このトピックに関心のある人たちが
参加していますね

このウェブキャストを見せたい人が
皆さんのチームにいるなら

録画してリンクを
後ほどお送りしますので大丈夫です

アンケートを閉じて
先に進みましょう

それでは本題に入って

今日の目標をお見せしましょう

今日お見せするために
作っておいたプロジェクトは

とても基本的なGitHub Pages
というページです

GitHub Pagesを知らない人のために

GitHub Pagesというのは
基本的に無料で使える―

ウェブホスティングのプラットフォームです

あなたのGitHubレポジトリを
直接このGitHub Pagesに

つなげることができ
プロジェクトについて

外の世界とやり取りができる
プロジェクト・ウェブページを作れます

これらは無料でセットアップできます

使い方は今表示されている―

pages.github.comのページで
見られます

このページでは
レポジトリのセットアップの仕方から

このページとのやり取りの仕方まで
わかります

セットアップしておいたページは
ちょっとしたレシピ集です

見てみると こちらですね

Project Management Cookbookです

とてもシンプルなページであることが
わかると思います

例として使うために
様々なレシピに飛ぶことのできる―

リンクをいくつか作りました

終わったころには
おなかがすいているでしょうから

今がお昼時ではないといいのですが

申し上げたように
とてもシンプルなページです

仕組みがどうなっているか
このプロジェクトを管理するのに

どのような作業が裏で行われているかを
お見せするためのものですから

ご存じのとおり GitHubでは
すべてがレポジトリで管理され

レポジトリとはプロジェクトに関する
すべてを集めたものです

プロジェクト・ファイルからやり取り
プロジェクトに関する―

測定基準など

プロジェクトに関わるすべてが
このレポジトリにあります

今日お見せすることのいくつかを
実行するために

いくつか前提を設けました

ひとつは皆さんが作業を行う
レポジトリの管理者であることです

レポジトリの管理者でない場合

お見せする事柄のうち 実行できないことも

いくつかあると思います

ですから権限のレベルを変更するか

権限のある人にタスクを完了してもらうよう

手配する必要があるかもしれません

それではまずインターフェースを
ざっとご紹介して

GiHubの異なるセクションの
使い方をお見せします

右側から始めましょう

現在は右側にあるCodeという
タブを開いています

Codeタブはその名の通り
ソースファイルがある場所です

これがレポジトリに属する
すべてのコンテンツで―

ウェブページに表示されるものです

その下にはIssuesと
Pullリクエストがあります

これらについては後ほど説明しますので

後で戻ることにします

プロジェクト内で非常に役に立つのは
Read Meファイルです

Read Meファイルというのは―

いくつか魔法のような言葉があって
Read Meファイルはそのひとつです

Read Meファイルで

あるページを自動的に
プロジェクトの前面に出せます

誰かがアクセスしたときに
あらゆる情報を―

ここにあるように
Read Meファイルで読めるのです

このRead Meファイルには
レシピ集にレシピを追加する方法―

つまりちょっと貢献する方法について

加えることにしました

レシピのテンプレートも提供しているので

レシピを共有したければ

テキストファイルに
コピー＆ペーストして

レシピを記入したらコミットし

Pull Requestを送信します

使いたい人がすぐ使えるよう
とても簡単なものにしました

もうひとつよく目にするファイルは

CONTRIBUTING.mdというもので

このファイルには―

どうやって参加するかが書かれています

このページが少し違っているのは

誰かがレシピ集にレシピを投稿したいと

Pull Requestを投稿した時にだけ

表示されるということです

もう少ししたら実際にお見せします

お気づきかと思いますが

これらのページのフォーマットは
とてもシンプルで

鉛筆のボタンをクリックすれば

これらのページがすべて―

Markdownという非常に軽量な
言語で書かれているとわかります

Markdownはとても基礎的で
シンプルです

ヘッダーはハッシュマークと
スペースだけで書かれており

ヘッダーです

箇条書きの点は
シンプルにダッシュでできています

Markdownの使い方の
ガイドもあります

コースでは触れませんが
ノートの中に

リンクを含めておくので
自分でアクセスして

Markdownの使い方を覚えられます

言った通り とてもシンプルな言語です

後ほど これでできる様々な
すごいことをお見せします

プロジェクトマネジャーにとって
とても役に立つ

別の選択肢はwikiです

深くは触れませんが
ほとんどの皆さんは

wikiをご存じでしょう
ページを集めたもので―

プロジェクトのスケジュールや
予算を保存したい場合に最適です

他にはチームの設立趣意なんかを

ここに保存できます

これにはあまり時間はかけません

トップバーを見てみましょう

watchしたり starしたり
forkするのが何かを見ていきます

プロジェクト・マネジャーとしては
プロジェクト内で

何が起きているかに
関心があるでしょう

ですから今起きているアクションから
発生しているコミュニケーションや

会話をwatchしたいと思うでしょう

この場合 watchするという
この選択肢を選びます

そうすれば 誰かがPull Requestする度に

コミットしたり何かを閉じる度に
通知が来ます

プロジェクトについてそこまでの
情報はいらないと思うなら

Not watchingも選べます

Not watchingを選んでも
会話に参加していれば

通知は送られてきますので

ディスカッションに何か言い足せば
そのディスカッションに関する

通知は送られてきます

もうひとつの鍵は誰かが@を使って
mentionする場合です

誰かがある事柄について とりわけ―

「ビル 力を貸してほしい
意見を聞かせてくれないかな」と

言ってきた場合は通知を受けます

Not watchingといっても
何も情報が入ってこないのでなく

単により限られた情報が
入ってくるということなのです

もちろん無視することも可能です

プロジェクト・マネジャーとしては
そうしたくはないでしょうが

そうすることも可能です

別のオプションはレポジトリに
Starをつけることです

Starをつけることは
お気に入りに登録するようなものです

WatchとStarの違いは何かと
よく聞かれますが―

Starはこれらのstarを
皆さんのホームページに追加します

このページをstarしてから
GitHub Teachersのホームページに行けば

左側にStarredとあります

皆さんは自分でstarしたページを
どれでも閲覧できるのです

ですから 興味があるページを
記録しておく方法です

後で閲覧するために
ブックマークしておくのです

ではメインのレポジトリに戻って

私たちがプロジェクトに用いた

主要なコミュニケーションツールについて
お話しします

IssuesとPull Requestsから
始めましょう

ここでアレンに参加してもらい

Issuesについてアレンに
説明してもらいます

その前に これら2つの概念的な違いを

述べておきましょう
Issuesは―

「質問があったり 不具合があるけど

どうしたらいいかわからない」
そんな時はIssueを使います

一方で 質問があり

解決法を知っているか
すでに解決済みの場合は

Pull Requestを使います

これら2つのオプションの

使い分け方は このような感じです

それではアレンに登場してもらって

Issuesについて説明してもらいます

(アレン) わかりました
ありがとう シンシア

それでは早速このIssuesのタブにある
Issuesを見ていきましょう

Codeタブのすぐ下にあるので
早速クリックします

従来「Issues (問題)」というと

ソフトウェア開発の観点では

問題点やバグなんかを考えますが

まさしくその通りです

プロジェクトのセットアップにもよりますが
Issuesはバグの追跡や

拡張などにも使えます

一般的なプロジェクトなら

例えば プロジェクトの要求を
追跡するのに使うかもしれません

この例で行ったのは まさにそれです

Issuesのリストには
レシピ集に追加される予定の

様々なレシピがあるのがわかります

メキシコ風ホットチョコレートや
ホリデー・パンチのレシピがありますが

他の人によって入力された
他のIssuesがあるのもわかります

例えば これは問題ですね

レモン・アイスボックス・パイのレシピに
作り方が欠けています

この場合 これがissue―

失礼 バグあるいはエラーにあたり
修正が必要です

Issuesは大変柔軟性が高く
様々な問題を管理するのに

使いやすいのです (笑)

最終的に目指しているのは
労力の管理ですね？

Issuesはすべき仕事を追跡します

GitHubには仕事を高レベルで

なおかつ非常に細かく見ることもできる
ツールがそろっています

では早速新しいIssueを
作ってみましょう

緑のNew Issuesボタンを
クリックします

issueのタイトルを入力する
このような画面が現れます

何か説明的なものがいいですが

できるだけ説明的にしましょう
ここでは例えば―

「ランチのメニューを追加する」
とかそういうものです

その下にはGitHubの他のエリアと
同様にコメント欄があります

このコメント欄はMarkdownを
サポートしているので

それを使ってIssueに関係のある
タスクを管理するために

いくつかのことをやることにしましょう

例えば ランチのセクションが
必要ですので アイデアはこちらです

Markdownのシンタックスを使って
このIssueの中にto-doリストの

アイテムを作れます

例えばホーギーがあります
それから―

イチゴサラダがあります
誰でも好きですね

ですから 勧められたアイテムの
チェックリストを作れます

また―

この下の部分でわかるように

直接画像をドラッグ＆ドロップできます

例えば issueを報告する場合
スクリーンショットを撮って

ブラウザのウィンドウに
直接ドラッグすると自動的に

GitHubにアップロードして
Issueに投稿されます

issueを見たままに伝えられます

他のエリアと同様にここでも
@を使って誰かをメンションすれば

GitHubはその人にも通知を送るので

人を会話に取り込むには
この機能は便利です

シンシアが言った通りですね

特に必ずしもレポジトリを
見ていない人にとっては便利です

そこで別のコメントを入力します

この場合はGitHub Studentが通知を受け取り

GitHub Teacherによる会話に参加しており

GitHub Teacherがインプットを
リクエストしているとわかります

そこで...

Issueの画面に戻ると
新しいIssueが上部に

作られたことがわかります

ここでお見せしたいのは
Issueの説明の右側に

小さなチェックボックスがあり

3分の0とあります

そこでメニューアイテムに
もう1度戻りましょう

そこでGitHubが
これらのチェックボックスを―

Markdownで作ったものに基づいて
作ったことがわかります

そこで試しにホーギーのチェックをはずして

ホーギーがレシピ集に
追加されたとしましょう

Issuesのページに戻ると
GitHubによって

Issueの3つのタスクのうち1つが
完了したと示すタスクリストが

アップデートされています

考えてみると これはサブタスクを
伴うかもしれないような

Issuesを掘り下げる上で

とても役に立つ機能です

タスクを分割して管理でき
なおかつ―

進捗を追跡できるのは
とても役に立ちます

ではGitHubでどうやって―

リストを管理するかを見てみましょう

アイテムはいくつあるでしょう？

オープンアイテムが20
クローズドアイテムが6あります

あるアイテムのある事柄を
追跡したいとしましょう

Labelを使って
Issuesに割り当てられます

新しく作ったランチメニューの
アイテムIssueに戻ります

画面右側にLabelsという
オプションがあります

Labelsの機能は
特定のカテゴリーや文脈とともに

Issueをタグ付けすることができるので
とても便利です

後にフィルタリングするのに使えます

これを用いる際の
いくつかの異なる例があります

進捗を追跡することもできます

例えば このレポジトリでは

あるIssueの進捗を示すのに
異なるlabelを用いています

未処理なのか進行中なのか―

完了しているのか
それぞれlabelをつけられます

そのタグで―　いや失礼
そのlabelで後にフィルタリングできます

Labelの他の使い方は

優先順位の追跡です

例えば とても重要な問題があったり

優先順位の低いものがあった場合

そのようにlabelを使うこともできます

Issueの性質でLabelを
使うこともできます

この場合では異なる部門があります

ContentとDesign
そしてEditorialです

これらのIssuesをチェックしてから

後にフィルタリングできます
今やってみましょう

Issuesのページに進んだら

Labelのヘッダーをクリックし

進行中でなおかつ重要なものを

すべて見てみましょう

Labelのヘッダーを再びクリックすると

こうしたフィルターは
追加されたものだとわかります

進行中のもので重要なものはないので
よかったですね

とはいえ未処理のものに
重要なissueがあるかもしれません

そこで未処理のもので

重要なものがないか見てみます

何もないので これは良い知らせです

ですからIssueリストを
フィルタリングする上でLabelを

どうやって使うか
多くのIssuesを少しの手間で

どう管理して

どの仕事に集中すべきかがわかります

もう1点はGitHubではLabelを

まとめて管理できることです

とても役に立ちますね？

なぜなら各Issueを見る必要がなく

単に「60の異なるIssues」という
Labelをつければいいのです

Issuesの左側にある
チェックボックスを使えば

複数のIssuesを選択でき

これらのIssuesすべてに
同じlabelを割り当てられるのです

例えば これらを進行中と
しるしをつけたければ

In Progressをクリックすると
そのLabelを他のIssuesにも

すでになければ追加します

ここではlabelsの割り当てを
変更もできます

複数のアイテムを選択した時に
できるもう1つのことは

複数のアイテムをある特定のユーザーに
割り当ててしまうことです

これが役に立つのは

終了したら他のユーザーに

引き渡されるissueが
いくつかある場合です

例えば これらのIssuesすべてが
GitHub TeacherとStudentの両方でなく

GitHub Teacherだけによって
閲覧・管理されるのなら

これをクリックしてIssuesが

えーと

GitHub Teacherに
再割り当てされるはずです

GitHub Teacherに
割り当てられていたものが

割り当てが外れたように
なっていますが

ここでもBulk Addという機能を使って

GitHub Teacherに
割り当てし直すことができます

この場合はGitHub Teacherが
メールか―

GitHubで通知を受け取り

このIssueを
割り当てられたことを知ります

タスクを管理するもうひとつの方法は

トップバーの右側にある
Sortオプションです

いくつかの異なる基準で
並べ替えてみましょう

新しいものからあるいは古いものから
順番に並べ替えられます

これは新しく追加されたものを
確認する良い方法です

新しいものから順番に並べれば
入ってきたばかりのIssueが目に入ります

古いものから順番にすれば
レポジトリにずっと残っている

Issuesを確認できます

まだ解決されていないIssuesが
あるかもしれない場合は

このように並べれば
どれが最も長い時間あるかわかります

別の方法はMost Commentedと
Least Commentedです

これらは例えば
たくさんコメントがついていても

そのIssueが進んでいなければ

何か解決すべき矛盾が
生じているのかもしれません

Issueを解決すべく
話し合いがされていても

誰も先に進めていないのかもしれません

ですから 話し合いが行われていても
必ずしも解決がされていないような

Issuesを掘り下げるには
とても良い方法です

あるいは コメントがない順で
Issuesで並べてみると

それらのIssuesは向けられるべき
注目を得られていないのかもしれません

コメントの中で誰かに対して
@でメンションを送って

「ねぇ これに関わってくれないかな」
と言うのもいいでしょう

並べ替えの最後の方法は

Recently Updatedと
Not Recently Updatedです

これを使えば
どのIssuesが活発で―

つまりたくさんの活動が行われており

どれがあまり活動が
行われていないかがわかります

ここでも タスクが若干古くなって

先に進めなければならないことが
あるでしょう

そこで ここではGitHub Studentに
メンションを送って

GitHub Studentが
これに取り組んでくれないか頼みます

では先に進んで 一歩引いて見ることで
より大きな目で

何に取り組むかを話しましょう

ここではIssuesにある
個々のタスクを管理する方法を

掘り下げました

ここで一歩引いて
より大きな目標や目的を見てみましょう

Milestonesという機能を使います

Issueにある このMilestoneの
リンクをクリックすると

いくつか異なるMilestonesが
ありますが

Milestoneはここにしかありません
Third Editionです

MilestonesではIssuesを

グループに分類し

特定の期間内で
目的を達成するようにします

これは普通の仕事の流れですから

プロジェクト・マネジメント全般と
うまくつながるでしょう

締め切りまでに
ある量の仕事によって

達成すべきmilestoneがあるでしょう

ではIssuesのリストに戻って

一番上にある
Milestonesをクリックして

よく見てみましょう

レポジトリにはMilestoneがひとつあり

Third Editionと呼ばれています

ここでMilestonesを用いるのは

レシピ集の出版用エディションを
管理するためです

ここでは開示されているIssuesが
4つあり―

2015年3月21日までに
完了されなければなりません

そこでThird Editionをクリックすると

フィルターを使い
特定のMilestoneに割り当てられた

Issuesをすべて見ることができます

レモン・アイスボックス・パイが
作り方が欠けていることと

レシピが重複して表示されていること

野菜を使った副菜のレシピを
追加するリクエストがあります

下にあるホリデー・パンチに
関するIssueは

今のところ未処理になっていますが

3月中旬までに

このMilestoneを達成するためには
タスクが多すぎるかもしれません

ここでできることは

Milestoneを変更することです

GitHubではその場で
このページから

Milestoneを作成できます

Milestoneがなければ
名前を入力して

Fourth Editionとでもいいましょうか

GitHubは自動的にこのIssueを
新しいMilestoneに割り当てる

オプションを与えてくれ
これはすごい近道です

ですから Issueのページに戻ると

Milestonesのページに戻って

見てみましょう

さて 2つのMilestoneがあります

Fourth Editionをクリックしましょう

おっと失礼
Milestonesのページに戻りましょう

Fourth Editionの中にある
Editをクリックします

お気づきのように
Milestoneを作るとき件名と

説明を加えられ
任意で期限も設定できます

説明そのものも任意ですが

追加しておくと便利です

なぜならプロジェクト・マネジメントでは

目標をはっきりとわかりやすく伝えるために

コミュニケーションを増やすことを
考えるものだからです

締切がアップデートされたのがわかります

ひとつの応用法は
プロジェクトの文脈にもよりますが

回転の速い環境で
仕事をしているなら

Milestoneを使ってIssuesを
短いスパンで管理できます

スパンを1か月にしたり
2週間にしたりできるでしょう

好きなように管理できます

それによってプロジェクト・マネジャーの
あなたは特定のスパンで

どのissueが完了されねばならないか
確認できるのです

ここでも issueをすべて完了したら

Milestoneを終了できます

終了セクションに行けば

終了されたMilestonesを
見ることができます

この場合 いくつかのMilestoneは

完了されなかったようです

デモ用には これでいいのですが

ここで完了されたものと

されていないものが見られます

ですから より大きな目で
仕事を把握するにはいい方法です

さてIssuesでは
やるべきタスクの管理方法を

見てきました
そうですね？

ここでシンシアにお返しして

今まさに行われているタスクを
レビュー・承認する方法について

見ていくことにしましょう

(シンシア) どうもありがとう アレン

それでは次は...

問題の解決法がわからない場合
どうするかを見てきましたが

次は問題の解決法がわかる場合
どうするかを見ていきます

とてもシンプルかもしれません

「プロジェクト・マネジャーなんだから
レシピに作り方を追加できる」

「誰か 他のデベロッパーに
頼まなくてもいい」

「実際に自分で問題を解決できる」

それでは作り方が欠けていた
レシピに戻りましょう

Issuesにありましたね

レモン・アイスボックス・パイの作り方が
欠けていたのでした

それではこれに関する―

開示されたIssueがあることを念頭に

コードビューを使って

レモン・アイスボックス・パイのレシピを
見ていきましょう

レシピをクリックして
デザートへと進み

アイスボックス・パイに到達します

ここでわかるのは
これがMarkdownで書かれた

実際のファイルだということです

GitHubではMarkdownで
あらゆるコンテンツを書くことができ

Jekyllでウェブ上に
表示させています

この場合は Markdownのファイルを
編集することにします

トップバーに鉛筆のマークが
あるのがわかります

これをクリックします

ここにMarkdownで書かれていますね

Markdownのフォーマットに関する
オプションが目に入ります

アステリスクを2つで太字になり

ハッシュマークを3つで
サードレベルの見出しが作成できます

作り方の部分を見てみると

そうですね ここを直す必要があります

「生地の材料を全て混ぜて焼く」

いくつか段階が抜けています

フィリングの材料も混ぜ合わせて

焼く前に生地の中に入れるように
しなくてはなりません

(タイプする音)

完璧です
いくつか変更を加えました

GitHubのいいことは
やることすべてがバージョンとして

管理されることです

ですからこの文書の
新しいバージョンを作成したわけです

これを保存して
バージョン管理に入れるためには

これらの変更をコミットしなければなりません

いいですよ GitHubは
この文書に加えた変更を知っているので

これらの変更をコミットするかどうか
選択肢を与えてくれます

ここです
他には何もしなくていいです

さらにこのコミットに対して
推奨される件名も提示してくれます

ですからここが このコミットにおいて
あなたが何をしたのかが

皆にわかるように
説明的な件名を書く部分です

このコミットについては
ごくシンプルに

「作り方を追加」とします

詳しい説明は任意なので
使う必要はありません

今日は使わないでおきます

それから下の方に

2つの異なる変更―
いえ オプションがあることがわかります

1つ目のオプションは
GH Pages Branchに

直接コミットするものです

branchesについては
まだあまりお話ししていませんが

基本的にbranchというのは
一連のコードです

この例においては
GH Pagesというのは

外部のウェブサイトに表示するための
一連のコードのことです

ですから GH Pages Branchに
直接コミットすれば

すぐにオンラインにアップされ

レシピのウェブサイトに
アクセスしている人全員が

加えた変更を見ることができます

そうしたいわけではありませんね

他の人たちが―

シェフがレシピを確認して

正しいかを確認したいかもしれません

ですからここでは
新しいbranchを作成します

新しいbranchを作成すると
ウェブサイトに表示される

ライブコードから
変更を切り離して

コードに変更を加えたり

それについて会話をしたり
何をすべきか話し合っても

完全に切り離して行えるので

ウェブサイトにあるコード自体には
影響を与えずに済みます

ご存じのように

結局この変更は加えないことにすれば

このbranchを削除すればいいので
変更はメインのサイトには

反映されません

この場合は branchを作成し

「レシピのアップデート」
と名前を付けましょう

それからファイルの変更の提案に
取り組みます

次のステップはPull Requestを
作成することです

覚えているでしょうか
少し前に

CONTRIBUTING.mdという文書を
見ましたね

この黄色のボックスの中に

contributingのための
ガイドラインが入っていますが

ここにファイルが現れます

ですから 今はやりませんが
このリンクをクリックすれば

contributingのための
説明を見ることができます

この場合は変更を加えたので

それについての
ディスカッションをしたいので

次にすべきことは

同僚からのフィードバックを
もらうことです

GitHubではPull Requestを
作成することでそれを行います

ですからPull Requestを

変更をする前に
コメントをもらうためのものであり

フィードバックをもらうためのものだと
考えてください

ここではコメントを
書き加えることができます

ここには例えばこんなコメントを
書くことができます

「作り方を追加したので
確認をお願いします」

(タイプする音)

こんな感じです

また そうしたければ

Issuesと同じように
画像をドロップすることもできます

数分前にアレンが
見せてくれましたね

このメモはなかなかいいですね

では先に進んで
Pull Requestsを作成すると書いてある

大きな緑のボタンをクリックします

GitHubが自動的に
会話を作成してくれました

オリジナルのコミットも追加されています

よく見てみると

「作り方を追加」と書いてあり

横には数字が書いてあります

これはコミットです
そのバージョンを保存したので

同僚や友人がアクセスして

フィードバックをくれることのできる

コメントが追加されています

ここでの選択肢には

すぐにこれを反映する
というものもありますが

ここではフィードバックをもらい
ディスカッションをしたいと

考えています

そこで下へスクロールすると

Issuesで見たものと同じように

コメントを残すという
オプションがあるのがわかります

続けてコメントをすることも
ファイルに変更を加えることもでき

全てこのbranch内の
安全な場所に保管されます

メインページにアップする前に

完璧な物に仕上げられます

Pull Requestのいいところは

変更を見るというオプションを
与えてくれるところです

トップに行き
Files Changedを見ると

ビューを提示してくれます

オリジナルのファイルは左側

追加や変更後のものは右側です

この場合 いくつか
追加しただけなので

新しい部分を緑のハイライトで
示してくれています

何か削除されたものがある場合は
赤で表示されるので

どこが削除されたかわかります

これによって

誰かがPull Requestを作成した場合

何が変更されたかが
実際にわかるためとても便利です

コードレビューを行う
より複雑なプロジェクトにも便利で

このようなものを...

コードを見て

何が変わったか知りたいと
思うかもしれません

これを他のツールと
統合することができます

continuous integration toolsという
ツールがあり

Pull Requestを提出すると

自動的にコードをチェックして

正しいか確認してくれます

とてもいいツールです

これらについての詳細は
github.com/integrationsでどうぞ

この場合では

もっと詳しい作り方が
必要かもしれません

材料を生地に入れて焼いたら

終わりではなさそうです

ですから この行にメモを加えます

「材料を生地に入れる
ここにもう少し説明が必要」

この行をクリックすることで

コメントを挿入することができます

これもコードについて
コメントをする場合にはとても便利です

ここでもMarkdownが
サポートされています

このコメントに画像を
付け加えることもできます

その場合はCommentを
クリックするだけです

この場合 もう少し作り方を
加える必要があるので

ファイルに戻りましょう

(クリックする音)

オンライン・エディターを使って

再び変更を加えるオプションがあります

この場合は 材料を生地に入れて
焼くのですが

メレンゲも作る必要があるでしょう

下に移動して

そこにトッピングのメレンゲを
作るための指示も加えましょう

そして...

できました
メレンゲを加えました

ここで今回聞かれるのは

「レシピのアップデートのbranchに
直接コミットしますか？」ということです

Pull Requestを通じて
このファイルにたどり着いたので

メインのGitHub Pagesではなく
このbranchを

アップデートしているのだと
わかったのです

この場合は 「はい」
そうするのがいいですね

branchをアップデートして
変更をコミットします

さて2つの違いがわかるビューに

やってきました

メレンゲのトッピングを
加えたことがわかります

なかなかいいですね

では会話に戻りましょう

ここで確認をして

お互いに更新してよいと
考えていることを知らせるために

コメント欄に行きます

絵文字もよく使うので

小さな+1の絵文字を入力して
了解したと伝えます

そしてCommentです

いいですね 次の段階に進めそうです

この例では トップに戻って
見てみましょう

ほんの少しだけ戻って

レシピの全体を見ることができます

変更を加え始めてから
レシピに起こったことがわかります

GitHub Teacherが
作り方の説明を追加し

誰かがそれに対して
「ここにもう少し説明が必要」という

コメントを追加して

これらの作り方を追加するための
2回目のコミットが行われています

ここまではいいですね

先に進んで このPull Requestを
統合してみましょう

大きな緑のボタンをクリックします

このPull Requestを統合することで

実際に行われるのは
このレシピを―

メインのGitHub Pagesという

branchに戻すことで

世界で見られるようにするということです

今加えたばかりの変更を
誰でも見られるようにするのです

別のとてもいい機能は

GitHubによって
時間が節約できることです

オリジナルのIssueを参照すれば―

レモン・メレンゲ・パイに
作り方を追加すべきだと

書かれたIssueを覚えていますね？

いくつかのキーワードが使え
そのひとつはFixesです

「これがfixする」とか
「これがcloseする」と言うことができます

それからハッシュマークも使えます

そして開示されたあなたのIssueが
引き寄せられたのがわかります

ですからPull Requestに
関係しているIssueや

fixしようとしているIssueを

見つけることができ

リストがとても長い場合は

ここでやってみたように
そのIssueに関する言葉を

タイプしてみればいいのです

レモン・アイスボックス・パイの作り方が
ありました

Issue 32です
これをクリックして

統合すると確認します

Pull Requestが成功したとあるので

統合され終了されました

このbranchはもう必要ないため

というのも もうからっぽですから―

これを削除できます

でもご心配なく
オプションにあるように

いつでも回復できます

それではこのPull Requestに
何が起こったかを見てみましょう

Pull Requestのトップへと
スクロールすると

Pull Requestが
統合されたとわかります

できました

でもあのIssueはどうなったのでしょう？

Issueに戻ってみてみましょう

ここではClosedを選びます

あのIssueがありますね

左手を見ればわかるように

このIssueはClosedに
移動されました

変更を加える方法の

簡単な紹介でした