Return to Video

Webcast • Github for Project Management

  • 0:01 - 0:02
    (シンシア) 皆さん こんにちは
  • 0:02 - 0:05
    ウェビナー開始１分前なので
  • 0:05 - 0:07
    ちゃんと聞こえているかどうか
  • 0:07 - 0:10
    オーディオのチェックを行いますね
  • 0:10 - 0:13
    画面にアンケートを出したので
  • 0:13 - 0:16
    聞こえ具合について教えてください
  • 0:22 - 0:24
    (アレン) いいですね
  • 0:24 - 0:29
    (シンシア) 参加者も集まって
    ちゃんと聞こえているようですね
  • 0:33 - 0:38
    ちょうど12時になったので
    始めることにしましょう
  • 0:38 - 0:41
    まず自己紹介しますね
    私はシンシア・リッチといいます
  • 0:41 - 0:45
    GitHubの講師です
    今日はアレン・スミスという―
  • 0:45 - 0:47
    もう１人のGitHub講師も一緒です
  • 0:47 - 0:50
    今日はトピックを通じて
  • 0:50 - 0:53
    皆さんにも関連する
    私たちの経験を共有したいと思います
  • 0:53 - 0:58
    このセッションでは
    プロジェクト・マネジメントと
  • 0:58 - 1:01
    GitHubを使ってプロジェクトを
    管理する方法についてです
  • 1:01 - 1:05
    では手短に 誰が電話に―
  • 1:05 - 1:08
    いえ ウェビナーに参加しているか
  • 1:08 - 1:11
    知るためにアンケートを出しました
  • 1:11 - 1:14
    あなたのプロジェクト・マネジメントの
    経験を教えてください
  • 1:14 - 1:17
    皆さんが答えている間に
  • 1:17 - 1:19
    今日の目標についてお話します
  • 1:19 - 1:22
    今日のウェビナーでは
    GitHubの仕組みを使って
  • 1:22 - 1:25
    プロジェクトを管理するための
  • 1:25 - 1:28
    良い方法をいくつかお教えします
  • 1:28 - 1:33
    私たちはすべてのプロジェクトを
    このプラットフォームで管理し
  • 1:33 - 1:38
    会話ややり取りをすべて
    ここに記録します
  • 1:38 - 1:42
    お伝えしたいのは
    効果的にこれを用いて
  • 1:42 - 1:46
    チーム内で効果的なコラボレーションと
  • 1:46 - 1:48
    コミュニケーションが
    行えるようにする秘訣です
  • 1:51 - 1:54
    さて 結果を見ると―
    いいですね
  • 1:54 - 1:56
    プロジェクト・マネジメントの
  • 1:56 - 1:59
    経験豊富な人たちと
  • 1:59 - 2:02
    このトピックに関心のある人たちが
    参加していますね
  • 2:02 - 2:08
    このウェブキャストを見せたい人が
    皆さんのチームにいるなら
  • 2:08 - 2:12
    録画してリンクを
    後ほどお送りしますので大丈夫です
  • 2:12 - 2:15
    アンケートを閉じて
    先に進みましょう
  • 2:19 - 2:22
    それでは本題に入って
  • 2:22 - 2:24
    今日の目標をお見せしましょう
  • 2:24 - 2:28
    今日お見せするために
    作っておいたプロジェクトは
  • 2:29 - 2:33
    とても基本的なGitHub Pages
    というページです
  • 2:33 - 2:35
    GitHub Pagesを知らない人のために
  • 2:35 - 2:39
    GitHub Pagesというのは
    基本的に無料で使える―
  • 2:39 - 2:41
    ウェブホスティングのプラットフォームです
  • 2:41 - 2:45
    あなたのGitHubレポジトリを
    直接このGitHub Pagesに
  • 2:45 - 2:49
    つなげることができ
    プロジェクトについて
  • 2:49 - 2:53
    外の世界とやり取りができる
    プロジェクト・ウェブページを作れます
  • 2:53 - 2:55
    これらは無料でセットアップできます
  • 2:55 - 2:57
    使い方は今表示されている―
  • 2:57 - 3:00
    pages.github.comのページで
    見られます
  • 3:00 - 3:03
    このページでは
    レポジトリのセットアップの仕方から
  • 3:03 - 3:06
    このページとのやり取りの仕方まで
    わかります
  • 3:06 - 3:11
    セットアップしておいたページは
    ちょっとしたレシピ集です
  • 3:12 - 3:16
    見てみると こちらですね
  • 3:16 - 3:18
    Project Management Cookbookです
  • 3:18 - 3:20
    とてもシンプルなページであることが
    わかると思います
  • 3:20 - 3:22
    例として使うために
    様々なレシピに飛ぶことのできる―
  • 3:22 - 3:25
    リンクをいくつか作りました
  • 3:25 - 3:28
    終わったころには
    おなかがすいているでしょうから
  • 3:28 - 3:30
    今がお昼時ではないといいのですが
  • 3:30 - 3:32
    申し上げたように
    とてもシンプルなページです
  • 3:32 - 3:35
    仕組みがどうなっているか
    このプロジェクトを管理するのに
  • 3:35 - 3:39
    どのような作業が裏で行われているかを
    お見せするためのものですから
  • 3:39 - 3:44
    ご存じのとおり GitHubでは
    すべてがレポジトリで管理され
  • 3:44 - 3:48
    レポジトリとはプロジェクトに関する
    すべてを集めたものです
  • 3:48 - 3:52
    プロジェクト・ファイルからやり取り
    プロジェクトに関する―
  • 3:52 - 3:54
    測定基準など
  • 3:54 - 3:59
    プロジェクトに関わるすべてが
    このレポジトリにあります
  • 3:59 - 4:03
    今日お見せすることのいくつかを
    実行するために
  • 4:03 - 4:04
    いくつか前提を設けました
  • 4:04 - 4:08
    ひとつは皆さんが作業を行う
    レポジトリの管理者であることです
  • 4:08 - 4:11
    レポジトリの管理者でない場合
  • 4:11 - 4:13
    お見せする事柄のうち 実行できないことも
  • 4:13 - 4:15
    いくつかあると思います
  • 4:16 - 4:21
    ですから権限のレベルを変更するか
  • 4:21 - 4:25
    権限のある人にタスクを完了してもらうよう
  • 4:25 - 4:27
    手配する必要があるかもしれません
  • 4:28 - 4:32
    それではまずインターフェースを
    ざっとご紹介して
  • 4:32 - 4:36
    GiHubの異なるセクションの
    使い方をお見せします
  • 4:36 - 4:38
    右側から始めましょう
  • 4:38 - 4:43
    現在は右側にあるCodeという
    タブを開いています
  • 4:43 - 4:48
    Codeタブはその名の通り
    ソースファイルがある場所です
  • 4:48 - 4:52
    これがレポジトリに属する
    すべてのコンテンツで―
  • 4:52 - 4:55
    ウェブページに表示されるものです
  • 4:56 - 5:00
    その下にはIssuesと
    Pullリクエストがあります
  • 5:00 - 5:02
    これらについては後ほど説明しますので
  • 5:02 - 5:04
    後で戻ることにします
  • 5:04 - 5:09
    プロジェクト内で非常に役に立つのは
    Read Meファイルです
  • 5:10 - 5:11
    Read Meファイルというのは―
  • 5:11 - 5:15
    いくつか魔法のような言葉があって
    Read Meファイルはそのひとつです
  • 5:15 - 5:16
    Read Meファイルで
  • 5:16 - 5:20
    あるページを自動的に
    プロジェクトの前面に出せます
  • 5:20 - 5:24
    誰かがアクセスしたときに
    あらゆる情報を―
  • 5:24 - 5:28
    ここにあるように
    Read Meファイルで読めるのです
  • 5:28 - 5:32
    このRead Meファイルには
    レシピ集にレシピを追加する方法―
  • 5:32 - 5:35
    つまりちょっと貢献する方法について
  • 5:35 - 5:38
    加えることにしました
  • 5:38 - 5:40
    レシピのテンプレートも提供しているので
  • 5:41 - 5:43
    レシピを寄稿したければ
  • 5:43 - 5:46
    テキストファイルに
    コピー＆ペーストして
  • 5:46 - 5:49
    レシピを記入したらコミットし
  • 5:49 - 5:53
    Pull Requestを送信します
  • 5:54 - 5:57
    使いたい人がすぐ使えるよう
    とても簡単なものにしました
  • 5:57 - 6:01
    もうひとつよく目にするファイルは
  • 6:01 - 6:04
    CONTRIBUTING.mdというもので
  • 6:04 - 6:06
    このファイルには―
  • 6:07 - 6:10
    どうやって参加するかが書かれています
  • 6:10 - 6:12
    このページが少し違っているのは
  • 6:12 - 6:14
    誰かがレシピ集にレシピを投稿したいと
  • 6:14 - 6:17
    Pull Requestを投稿した時にだけ
  • 6:17 - 6:20
    表示されるということです
  • 6:20 - 6:23
    もう少ししたら実際にお見せします
  • 6:23 - 6:24
    お気づきかと思いますが
  • 6:24 - 6:27
    これらのページのフォーマットは
    とてもシンプルで
  • 6:27 - 6:31
    鉛筆のボタンをクリックすれば
  • 6:33 - 6:34
    これらのページがすべて―
  • 6:34 - 6:37
    Markdownという非常に軽量な
    言語で書かれているとわかります
  • 6:37 - 6:40
    Markdownはとても基礎的で
    シンプルです
  • 6:40 - 6:44
    ヘッダーはハッシュマークと
    スペースだけで書かれており
  • 6:44 - 6:45
    ヘッダーです
  • 6:45 - 6:48
    箇条書きの点は
    シンプルにダッシュでできています
  • 6:48 - 6:52
    Markdownの使い方の
    ガイドもあります
  • 6:52 - 6:56
    このコースでは触れませんが
    ノートの中に
  • 6:56 - 7:00
    リンクを含めておくので
    自分でアクセスして
  • 7:00 - 7:02
    Markdownの使い方を学べます
  • 7:02 - 7:05
    言った通り とてもシンプルな言語です
  • 7:05 - 7:09
    後ほど これでできる様々な
    すごいことをお見せします
  • 7:11 - 7:14
    プロジェクトマネジャーにとって
    とても役に立つ
  • 7:14 - 7:18
    別の選択肢はwikiです
  • 7:19 - 7:22
    深くは触れませんが
    ほとんどの皆さんは
  • 7:22 - 7:25
    wikiをご存じでしょう
    ページを集めたもので―
  • 7:25 - 7:29
    プロジェクトのスケジュールや
    予算を保存したい場合に最適です
  • 7:29 - 7:33
    他にはチームの設立趣意なんかを
  • 7:33 - 7:35
    ここに保存できます
  • 7:35 - 7:37
    これにはあまり時間はかけません
  • 7:37 - 7:41
    トップバーを見てみましょう
  • 7:41 - 7:44
    watchしたり starしたり
    forkするのが何かを見ていきます
  • 7:44 - 7:47
    プロジェクト・マネジャーとしては
    プロジェクト内で
  • 7:47 - 7:49
    何が起きているかに
    関心があるでしょう
  • 7:49 - 7:53
    ですから今起きているアクションから
    発生しているコミュニケーションや
  • 7:53 - 7:55
    会話をwatchしたいと思うでしょう
  • 7:55 - 8:00
    この場合 watchするという
    この選択肢を選びます
  • 8:00 - 8:05
    そうすれば 誰かがPull Requestする度に
  • 8:06 - 8:09
    コミットしたり何かを閉じる度に
    通知が来ます
  • 8:09 - 8:14
    プロジェクトについてそこまでの
    情報はいらないと思うなら
  • 8:14 - 8:17
    Not watchingも選べます
  • 8:17 - 8:22
    Not watchingを選んでも
    会話に参加していれば
  • 8:22 - 8:24
    通知は送られてきますので
  • 8:24 - 8:27
    ディスカッションに何か言い足せば
    そのディスカッションに関する
  • 8:27 - 8:29
    通知は送られてきます
  • 8:29 - 8:32
    もうひとつの鍵は誰かが@を使って
    mentionする場合です
  • 8:32 - 8:36
    誰かがある事柄について とりわけ―
  • 8:36 - 8:41
    「ビル 力を貸してほしい
    意見を聞かせてくれないかな」と
  • 8:41 - 8:44
    言ってきた場合は通知を受けます
  • 8:44 - 8:47
    Not watchingといっても
    何も情報が入ってこないのでなく
  • 8:47 - 8:51
    単により限られた情報が
    入ってくるということなのです
  • 8:51 - 8:53
    もちろん無視することも可能です
  • 8:53 - 8:55
    プロジェクト・マネジャーとしては
    そうしたくはないでしょうが
  • 8:55 - 8:57
    そうすることも可能です
  • 8:57 - 9:01
    別のオプションはレポジトリに
    Starをつけることです
  • 9:01 - 9:04
    Starをつけることは
    お気に入りに登録するようなものです
  • 9:04 - 9:07
    WatchとStarの違いは何かと
    よく聞かれますが―
  • 9:07 - 9:12
    Starはこれらのstarを
    皆さんのホームページに追加します
  • 9:12 - 9:19
    このページをstarしてから
    GitHub Teachersのホームページに行けば
  • 9:19 - 9:23
    左側にStarredとあります
  • 9:23 - 9:27
    皆さんは自分でstarしたページを
    どれでも閲覧できるのです
  • 9:27 - 9:30
    ですから 興味があるページを
    記録しておく方法です
  • 9:31 - 9:35
    後で閲覧するために
    ブックマークしておくのです
  • 9:37 - 9:42
    ではメインのレポジトリに戻って
  • 9:42 - 9:46
    私たちがプロジェクトに用いた
  • 9:46 - 9:49
    主要なコミュニケーションツールについて
    お話しします
  • 9:49 - 9:52
    IssuesとPull Requestsから
    始めましょう
  • 9:52 - 9:55
    ここでアレンに参加してもらい
  • 9:55 - 9:59
    Issuesについてアレンに
    説明してもらいます
  • 9:59 - 10:03
    その前に これら2つの概念的な違いを
  • 10:03 - 10:07
    述べておきましょう
    Issuesは―
  • 10:08 - 10:11
    「質問があったり 不具合があるけど
  • 10:11 - 10:14
    どうしたらいいかわからない」
    そんな時はIssueを使います
  • 10:14 - 10:17
    一方で 質問があり
  • 10:17 - 10:20
    解決法を知っているか
    すでに解決済みの場合は
  • 10:20 - 10:21
    Pull Requestを使います
  • 10:21 - 10:23
    これら2つのオプションの
  • 10:23 - 10:26
    使い分け方は このような感じです
  • 10:26 - 10:28
    それではアレンに登場してもらって
  • 10:28 - 10:31
    Issuesについて説明してもらいます
  • 10:31 - 10:33
    (アレン) わかりました
    ありがとう シンシア
  • 10:33 - 10:38
    それでは早速このIssuesのタブにある
    Issuesを見ていきましょう
  • 10:39 - 10:45
    Codeタブのすぐ下にあるので
    早速クリックします
  • 10:46 - 10:50
    従来「Issues (問題)」というと
  • 10:50 - 10:51
    ソフトウェア開発の観点では
  • 10:51 - 10:55
    問題点やバグなんかを考えますが
  • 10:55 - 10:57
    まさしくその通りです
  • 10:57 - 11:01
    プロジェクトのセットアップにもよりますが
    Issuesはバグの追跡や
  • 11:01 - 11:04
    拡張などにも使えます
  • 11:04 - 11:07
    一般的なプロジェクトなら
  • 11:07 - 11:13
    例えば プロジェクトの要求を
    追跡するのに使うかもしれません
  • 11:13 - 11:15
    この例で行ったのは まさにそれです
  • 11:15 - 11:21
    Issuesのリストには
    レシピ集に追加される予定の
  • 11:21 - 11:25
    様々なレシピがあるのがわかります
  • 11:25 - 11:29
    メキシコ風ホットチョコレートや
    ホリデー・パンチのレシピがありますが
  • 11:30 - 11:34
    他の人によって入力された
    他のIssuesがあるのもわかります
  • 11:34 - 11:36
    例えば これは問題ですね
  • 11:36 - 11:39
    レモン・アイスボックス・パイのレシピに
    作り方が欠けています
  • 11:39 - 11:41
    この場合 これがissue―
  • 11:41 - 11:45
    失礼 バグあるいはエラーにあたり
    修正が必要です
  • 11:45 - 11:48
    Issuesは大変柔軟性が高く
    様々な問題を管理するのに
  • 11:49 - 11:53
    使いやすいのです (笑)
  • 11:54 - 11:57
    最終的に目指しているのは
    労力の管理ですね？
  • 11:57 - 12:02
    Issuesはすべき仕事を追跡します
  • 12:04 - 12:08
    GitHubには仕事を高レベルで
  • 12:08 - 12:11
    なおかつ非常に細かく見ることもできる
    ツールがそろっています
  • 12:11 - 12:16
    では早速新しいIssueを
    作ってみましょう
  • 12:18 - 12:22
    緑のNew Issuesボタンを
    クリックします
  • 12:22 - 12:26
    issueのタイトルを入力する
    このような画面が現れます
  • 12:26 - 12:30
    何か説明的なものがいいですが
  • 12:30 - 12:34
    できるだけ説明的にしましょう
    ここでは例えば―
  • 12:35 - 12:41
    「新しいランチのメニューを追加する」
    とかそういうものです
  • 12:46 - 12:50
    その下にはGitHubの他のエリアと
    同様にコメント欄があります
  • 12:50 - 12:53
    このコメント欄はMarkdownを
    サポートしているので
  • 12:53 - 12:56
    それを使ってIssueに関係のある
    タスクを管理するために
  • 12:56 - 13:00
    いくつかのことをやることにしましょう
  • 13:00 - 13:07
    例えば ランチのセクションが
    必要ですので アイデアはこちらです
  • 13:07 - 13:11
    Markdownのシンタックスを使って
    このIssueの中にto-doリストの
  • 13:11 - 13:13
    アイテムを作れます
  • 13:13 - 13:17
    例えばホーギーがあります
    それから―
  • 13:17 - 13:22
    イチゴサラダがあります
    誰でも好きですね
  • 13:22 - 13:30
    ですから 提案されたアイテムの
    チェックリストを作れます
  • 13:32 - 13:33
    また―
  • 13:35 - 13:37
    この下の部分でわかるように
  • 13:37 - 13:40
    直接画像をドラッグ＆ドロップできます
  • 13:40 - 13:43
    例えば issueを報告する場合
    スクリーンショットを撮って
  • 13:43 - 13:47
    ブラウザのウィンドウに
    直接ドラッグすると自動的に
  • 13:47 - 13:49
    GitHubにアップロードして
    Issueに投稿されます
  • 13:49 - 13:53
    issueを見たままに伝えられます
  • 13:54 - 13:58
    他のエリアと同様にここでも
    @を使って誰かの名前を入れると
  • 13:58 - 14:02
    GitHubはその人にも通知を送るので
  • 14:02 - 14:06
    人を会話に誘い込むには
    この機能は便利です
  • 14:06 - 14:08
    シンシアが言った通りですね
  • 14:09 - 14:15
    特に必ずしもレポジトリを
    見ていない人にとっては便利です
  • 14:19 - 14:22
    そこで別のコメントを入力します
  • 14:22 - 14:26
    この場合はGitHub Studentが通知を受け取り
  • 14:26 - 14:29
    GitHub Teacherによる会話に誘い込まれています
  • 14:29 - 14:33
    GitHub Teacherがインプットを
    リクエストしているとわかります
  • 14:35 - 14:36
    そこで...
  • 14:38 - 14:43
    Issueの画面に戻ると
    新しいIssueが上部に
  • 14:43 - 14:46
    作られたことがわかります
  • 14:46 - 14:51
    ここでお見せしたいのは
    Issueの説明の右側に
  • 14:51 - 14:54
    小さなチェックボックスがあり
  • 14:54 - 14:55
    3分の0とあります
  • 14:55 - 14:58
    そこでメニューアイテムに
    もう1度戻りましょう
  • 15:00 - 15:03
    そこでGitHubが
    これらのチェックボックスを―
  • 15:03 - 15:05
    Markdownで作ったものに基づいて
    作ったことがわかります
  • 15:05 - 15:07
    そこで試しにホーギーのチェックをはずして
  • 15:07 - 15:10
    ホーギーがレシピ集に
    追加されたとしましょう
  • 15:10 - 15:15
    Issuesのページに戻ると
    GitHubによって
  • 15:15 - 15:20
    Issueの3つのタスクのうち1つが
    完了したと示すタスクリストが
  • 15:20 - 15:22
    アップデートされています
  • 15:22 - 15:26
    考えてみると これはサブタスクを
    伴うかもしれないような
  • 15:26 - 15:28
    Issuesを掘り下げる上で
  • 15:28 - 15:31
    とても役に立つ機能です
  • 15:31 - 15:34
    タスクを分割して管理でき
    なおかつ―
  • 15:34 - 15:37
    進捗を追跡できるのは
    とても役に立ちます
  • 15:45 - 15:49
    ではGitHubでどうやって―
  • 15:49 - 15:52
    リストを管理するかを見てみましょう
  • 15:52 - 15:54
    アイテムはいくつあるでしょう？
  • 15:54 - 15:56
    オープンアイテムが20
    クローズドアイテムが6あります
  • 15:56 - 16:01
    あるアイテムのある事柄を
    追跡したいとしましょう
  • 16:01 - 16:05
    Labelを使って
    Issuesに割り当てられます
  • 16:05 - 16:09
    新しく作ったランチメニューの
    アイテムIssueに戻ります
  • 16:11 - 16:14
    画面右側にLabelsという
    オプションがあります
  • 16:14 - 16:18
    Labelsの機能は
    特定のカテゴリーや文脈とともに
  • 16:18 - 16:23
    Issueをタグ付けすることができるので
    とても便利です
  • 16:23 - 16:25
    後にフィルタリングするのに使えます
  • 16:25 - 16:28
    これを用いる際の
    いくつかの異なる例があります
  • 16:29 - 16:31
    進捗を追跡することもできます
  • 16:31 - 16:34
    例えば このレポジトリでは
  • 16:34 - 16:37
    あるIssueの進捗を示すのに
    異なるlabelを用いています
  • 16:37 - 16:40
    未処理なのか進行中なのか―
  • 16:40 - 16:43
    完了しているのか
    それぞれlabelをつけられます
  • 16:43 - 16:47
    そのタグで―　いや失礼
    そのlabelで後にフィルタリングできます
  • 16:48 - 16:50
    Labelの他の使い方は
  • 16:50 - 16:53
    優先順位の追跡です
  • 16:53 - 16:55
    例えば とても重要な問題があったり
  • 16:55 - 16:57
    優先順位の低いものがあった場合
  • 16:57 - 16:59
    そのようにlabelを使うこともできます
  • 17:05 - 17:10
    Issueの性質でLabelを
    使うこともできます
  • 17:10 - 17:14
    この場合では異なる部門があります
  • 17:14 - 17:17
    ContentとDesign
    そしてEditorialです
  • 17:18 - 17:21
    これらのIssuesをチェックしてから
  • 17:22 - 17:27
    後にフィルタリングできます
    今やってみましょう
  • 17:28 - 17:31
    Issuesのページに進んだら
  • 17:33 - 17:36
    Labelのヘッダーをクリックし
  • 17:38 - 17:43
    進行中でなおかつ重要なものを
  • 17:46 - 17:48
    すべて見てみましょう
  • 17:50 - 17:52
    Labelのヘッダーを再びクリックすると
  • 17:52 - 17:54
    こうしたフィルターは
    追加されたものだとわかります
  • 17:54 - 17:58
    進行中のもので重要なものはないので
    よかったですね
  • 17:58 - 18:01
    とはいえ未処理のものに
    重要なissueがあるかもしれません
  • 18:01 - 18:03
    そこで未処理のもので
  • 18:03 - 18:05
    重要なものがないか見てみます
  • 18:11 - 18:14
    何もないので これは良い知らせです
  • 18:14 - 18:18
    ですからLabelを使ってどのように
    Issueリストをフィルタリングするか
  • 18:18 - 18:20
    わかり
    それによって
  • 18:20 - 18:23
    多くのIssuesを少しの手間で管理することで
  • 18:23 - 18:26
    必要な仕事に集中することができます
  • 18:35 - 18:37
    もう1つGitHubでできることは
  • 18:37 - 18:41
    これらのLabelをまとめて管理できます
  • 18:41 - 18:42
    とても役に立ちますね？
  • 18:42 - 18:45
    なぜなら各Issueを見る必要がなく
  • 18:45 - 18:48
    単に「60の異なるIssues」という
    Labelをつければいいのです
  • 18:48 - 18:51
    Issuesの左側にある
    チェックボックスを使えば
  • 18:51 - 18:54
    複数のIssuesを選択でき
  • 18:56 - 18:59
    これらのIssuesすべてに
    同じlabelを割り当てられるのです
  • 18:59 - 19:03
    例えば これらを進行中と
    しるしをつけたければ
  • 19:03 - 19:07
    In Progressをクリックすると
    他のLabelがついてないIssuesにも
  • 19:07 - 19:08
    まとまてLabelを追加できます
  • 19:08 - 19:10
    ここではlabelsの割り当てを
    変更もできます
  • 19:15 - 19:18
    複数のアイテムを選択した時に
    できるもう1つのことは
  • 19:18 - 19:21
    複数のアイテムをある特定のユーザーに
    割り当ててしまうことです
  • 19:22 - 19:24
    これが役に立つのは
  • 19:24 - 19:27
    終了したら他のユーザーに
  • 19:27 - 19:30
    引き渡されるissueが
    いくつかある場合です
  • 19:30 - 19:34
    例えば これらのIssuesすべてが
    GitHub TeacherとStudentの両方でなく
  • 19:34 - 19:39
    GitHub Teacherだけによって
    閲覧・管理されるのなら
  • 19:39 - 19:42
    これをクリックしてIssuesが
  • 19:42 - 19:43
    えーと
  • 19:43 - 19:46
    GitHub Teacherに
    再割り当てされるはずです
  • 19:47 - 19:49
    GitHub Teacherに
    割り当てられていたものが
  • 19:49 - 19:51
    割り当てが外れたように
    なっていますが
  • 19:51 - 19:54
    ここでもBulk Addという機能を使って
  • 19:54 - 19:56
    GitHub Teacherに
    割り当てし直すことができます
  • 19:56 - 19:59
    この場合はGitHub Teacherが
    メールか―
  • 19:59 - 20:01
    GitHubで通知を受け取り
  • 20:01 - 20:05
    このIssueを
    割り当てられたことを知ります
  • 20:10 - 20:12
    タスクを管理するもうひとつの方法は
  • 20:12 - 20:17
    トップバーの右側にある
    Sortオプションです
  • 20:18 - 20:21
    いくつかの異なる基準で
    並べ替えてみましょう
  • 20:21 - 20:24
    新しいものからあるいは古いものから
    順番に並べ替えられます
  • 20:24 - 20:27
    これは新しく追加されたものを
    確認する良い方法です
  • 20:27 - 20:30
    新しいものから順番に並べれば
    入ってきたばかりのIssueが目に入ります
  • 20:30 - 20:34
    古いものから順番にすれば
    レポジトリにずっと残っている
  • 20:34 - 20:36
    Issuesを確認できます
  • 20:36 - 20:39
    まだ解決されていないIssuesが
    あるかもしれない場合は
  • 20:39 - 20:42
    このように並べれば
    どれが最も長い時間あるかわかります
  • 20:44 - 20:48
    別の並べ替えの方法はMost Commentedと
    Least Commentedです
  • 20:49 - 20:53
    これらは例えば
    たくさんコメントがついていても
  • 20:53 - 20:56
    そのIssueが進んでいなければ
  • 20:57 - 21:00
    何か解決すべき矛盾が
    生じているのかもしれません
  • 21:00 - 21:03
    Issueを解決すべく
    話し合いがされていても
  • 21:03 - 21:05
    誰も先に進めていないのかもしれません
  • 21:05 - 21:07
    ですから 話し合いが行われていても
    必ずしも解決がされていないような
  • 21:07 - 21:12
    Issuesを掘り下げるには
    とても良い方法です
  • 21:12 - 21:16
    あるいは コメントがない順で
    Issuesで並べてみると
  • 21:16 - 21:20
    充分な検討がなされていないIssuesが
    みつけるかもしれません
  • 21:20 - 21:23
    コメントの中で誰かに対して
    @でメンションを送って
  • 21:23 - 21:25
    「ねぇ これに関わってくれないかな」
    と言うのもいいでしょう
  • 21:28 - 21:31
    並べ替えの最後の方法は
  • 21:32 - 21:36
    Recently Updatedと
    Not Recently Updatedです
  • 21:37 - 21:40
    これを使えば
    どのIssuesが活発で―
  • 21:40 - 21:42
    つまりたくさんの活動が行われており
  • 21:42 - 21:45
    どれがあまり活動が
    行われていないかがわかります
  • 21:45 - 21:48
    ここでも タスクが若干古くなって
  • 21:49 - 21:51
    先に進めなければならないことが
    あるでしょう
  • 21:56 - 21:59
    ここではGitHub Studentに
    メンションを送って
  • 22:01 - 22:04
    GitHub Studentが
    これに取り組んでくれないか頼みます
  • 22:11 - 22:17
    では 先に進むにあたり
    一歩戻って見ることでより大きな目で
  • 22:17 - 22:19
    何に取り組むかを話しましょう
  • 22:19 - 22:22
    ここではIssuesにある
    個々のタスクを管理する方法を
  • 22:22 - 22:24
    掘り下げました
  • 22:25 - 22:29
    ここで一歩さがって
    より大きな目標や目的を見てみましょう
  • 22:29 - 22:31
    Milestonesという機能を使います
  • 22:31 - 22:36
    Issueにある このMilestoneの
    リンクをクリックすると
  • 22:36 - 22:38
    いくつか異なるMilestonesが
    ありますが
  • 22:38 - 22:41
    ここにMilestoneは１つしかありません
    Third Editionです
  • 22:41 - 22:46
    MilestonesではIssuesを
  • 22:46 - 22:49
    グループに分類し
  • 22:49 - 22:53
    特定の期間内で
    目的を達成するようにします
  • 22:53 - 22:57
    これは普通の仕事の流れですから
  • 22:57 - 23:00
    プロジェクト・マネジメント全般と
    うまくつながるでしょう
  • 23:00 - 23:01
    締め切りまでに
    ある量の仕事によって
  • 23:01 - 23:05
    達成すべきmilestoneがあるでしょう
  • 23:05 - 23:07
    ではIssuesのリストに戻って
  • 23:07 - 23:11
    一番上にある
    Milestonesをクリックして
  • 23:11 - 23:13
    よく見てみましょう
  • 23:13 - 23:19
    レポジトリには開いているMilestoneがひとつあり
  • 23:19 - 23:20
    Third Editionと呼ばれています
  • 23:20 - 23:22
    ここでMilestonesを用いるのは
  • 23:22 - 23:26
    レシピ集の出版用エディションを
    管理するためです
  • 23:26 - 23:29
    ここでは開示されているIssuesが
    4つあり―
  • 23:29 - 23:33
    2015年3月21日までに
    完了されなければなりません
  • 23:35 - 23:37
    そこでThird Editionをクリックすると
  • 23:37 - 23:42
    フィルターを使い
    特定のMilestoneに割り当てられた
  • 23:42 - 23:44
    Issuesをすべて見ることができます
  • 23:44 - 23:48
    レモン・アイスボックス・パイが
    作り方が欠けていることと
  • 23:48 - 23:50
    レシピが重複して表示されていること
  • 23:50 - 23:53
    野菜を使った副菜のレシピを
    追加するリクエストがあります
  • 23:53 - 23:57
    下にあるホリデー・パンチに
    関するIssueは
  • 23:57 - 23:59
    今のところ未処理になっていますが
  • 23:59 - 24:01
    3月中旬までに
  • 24:01 - 24:05
    このMilestoneを達成するためには
    タスクが多すぎるかもしれません
  • 24:05 - 24:07
    ここでできることは
  • 24:07 - 24:10
    Milestoneを変更することです
  • 24:10 - 24:15
    GitHubではその場で
    このページから
  • 24:15 - 24:17
    Milestoneを作成できます
  • 24:17 - 24:20
    Milestoneがなければ
    名前を入力して
  • 24:20 - 24:23
    Fourth Editionとでもいいましょうか
  • 24:24 - 24:29
    GitHubは自動的にこのIssueを
    新しいMilestoneに割り当てる
  • 24:29 - 24:34
    オプションを与えてくれ
    これはすごい近道です
  • 24:36 - 24:38
    ですから Issueのページに戻ると
  • 24:38 - 24:41
    Milestonesのページに戻って
  • 24:42 - 24:43
    見てみましょう
  • 24:43 - 24:48
    Third EditionとFourth Edition Milestonesの
    2つのMilestoneがあります
  • 24:49 - 24:52
    Fourth Editionをクリックしましょう
  • 24:54 - 24:58
    おっと失礼
    Milestonesのページに戻りましょう
  • 24:59 - 25:02
    Fourth Editionの中にある
    Editをクリックします
  • 25:03 - 25:07
    お気づきのように
    Milestoneを作るとき件名と
  • 25:07 - 25:11
    説明を加えられ
    任意で締め切りも設定できます
  • 25:15 - 25:19
    説明そのものも任意ですが
  • 25:19 - 25:20
    追加しておくと便利です
  • 25:20 - 25:22
    なぜならプロジェクト・マネジメントでは
  • 25:22 - 25:24
    目標をはっきりとわかりやすく伝えるために
  • 25:24 - 25:29
    コミュニケーションを増やすことを
    考えるものだからです
  • 25:33 - 25:36
    締切が更新されたのがわかります
  • 25:37 - 25:41
    ひとつの応用法は
    プロジェクトの内容にもよりますが
  • 25:41 - 25:44
    回転の速い環境で
    仕事をしているなら
  • 25:44 - 25:47
    Milestoneを使ってIssuesを
    短い期間で管理できます
  • 25:47 - 25:51
    期間を1か月にしたり
    2週間にしたりできるでしょう
  • 25:51 - 25:53
    好きなように管理できます
  • 25:53 - 25:56
    それによってプロジェクト・マネジャーの
    あなたは特定の期間で
  • 25:56 - 26:00
    どのissueが完了されねばならないか
    確認できるのです
  • 26:10 - 26:14
    ここでも issueをすべて完了したら
  • 26:14 - 26:17
    Milestoneを閉じることができます
  • 26:17 - 26:20
    閉じられたセクションに行けば
  • 26:20 - 26:23
    終了されたMilestonesを
    見ることができます
  • 26:23 - 26:26
    この場合 いくつかのMilestoneは
  • 26:26 - 26:27
    完了されなかったようです
  • 26:27 - 26:30
    デモ用には これでいいのですが
  • 26:30 - 26:31
    ここで完了されたものと
  • 26:31 - 26:33
    されていないものが見られます
  • 26:33 - 26:38
    ですから より大きな目で
    仕事を把握するにはいい方法です
  • 26:39 - 26:43
    さてIssuesでは
    やるべきタスクの管理方法を
  • 26:43 - 26:45
    見てきました
    そうですね？
  • 26:45 - 26:48
    ここでシンシアにお返しして
  • 26:48 - 26:52
    今まさに行われているタスクを
    レビュー・承認する方法について
  • 26:52 - 26:54
    見ていくことにしましょう
  • 26:56 - 26:57
    (シンシア) どうもありがとう アレン
  • 26:57 - 27:00
    それでは次は...
  • 27:00 - 27:03
    問題の解決法がわからない場合
    どうするかを見てきましたが
  • 27:03 - 27:06
    次は問題の解決法がわかる場合
    どうするかを見ていきます
  • 27:06 - 27:08
    とてもシンプルかもしれません
  • 27:08 - 27:11
    「プロジェクト・マネジャーなんだから
    レシピに作り方を追加できる」
  • 27:11 - 27:14
    「誰か 他のデベロッパーに
    頼まなくてもいい」
  • 27:14 - 27:17
    「実際に自分で問題を解決できる」
  • 27:17 - 27:22
    それでは作り方が欠けていた
    レシピに戻りましょう
  • 27:22 - 27:24
    Issuesにありましたね
  • 27:24 - 27:29
    レモン・アイスボックス・パイの作り方が
    欠けていました
  • 27:29 - 27:31
    それではこれに関する―
  • 27:31 - 27:34
    開示されたIssueがあることを念頭に
  • 27:34 - 27:37
    コードビューを使って
  • 27:37 - 27:40
    レモン・アイスボックス・パイのレシピを
    見ていきましょう
  • 27:42 - 27:45
    レシピをクリックして
    デザートへと進み
  • 27:45 - 27:49
    アイスボックス・パイに到達します
  • 27:50 - 27:53
    ここでわかるのは
    これがMarkdownで書かれた
  • 27:53 - 27:55
    実際のファイルだということです
  • 27:55 - 27:59
    GitHubではMarkdownで
    あらゆるコンテンツを書くことができ
  • 27:59 - 28:04
    Jekyllでウェブ上に
    表示させています
  • 28:04 - 28:07
    この場合は Markdownのファイルを
    編集することにします
  • 28:07 - 28:10
    トップバーに鉛筆のマークが
    あるのがわかります
  • 28:10 - 28:12
    これをクリックします
  • 28:15 - 28:17
    ここにMarkdownで書かれていますね
  • 28:17 - 28:20
    Markdownのフォーマットに関する
    オプションが目に入ります
  • 28:20 - 28:24
    アステリスクを2つで太字になり
  • 28:24 - 28:28
    ハッシュマークを3つで
    サードレベルの見出しが作成できます
  • 28:28 - 28:30
    作り方の部分を見てみると
  • 28:30 - 28:32
    そうですね ここを直す必要があります
  • 28:32 - 28:35
    「生地の材料を全て混ぜて焼く」
  • 28:35 - 28:37
    いくつか段階が抜けています
  • 28:37 - 28:42
    フィリングの材料も混ぜ合わせて
  • 28:42 - 28:44
    焼く前に生地の中に入れるように
    しなくてはなりません
  • 28:45 - 28:47
    (タイプする音)
  • 28:58 - 29:02
    完璧です
    いくつか変更を加えました
  • 29:02 - 29:05
    GitHubのいいことは
    やることすべてがバージョンとして
  • 29:05 - 29:06
    管理されることです
  • 29:06 - 29:09
    ですからこの文書の
    新しいバージョンを作成したわけです
  • 29:09 - 29:13
    これを保存して
    バージョン管理に入れるためには
  • 29:13 - 29:15
    これらの変更をコミットしなければなりません
  • 29:16 - 29:20
    いいですよ GitHubは
    この文書に加えた変更を知っているので
  • 29:20 - 29:23
    これらの変更をコミットするかどうか
    選択肢を与えてくれます
  • 29:23 - 29:26
    ここです
    他の場所で行なう必要はありません
  • 29:26 - 29:31
    さらにこのコミットに対して
    推奨される件名も提示してくれます
  • 29:31 - 29:35
    ですからここが このコミットにおいて
    あなたが何をしたのかが
  • 29:35 - 29:38
    皆にわかるように
    説明的な件名を書く部分です
  • 29:38 - 29:40
    このコミットについては
    ごくシンプルに
  • 29:40 - 29:44
    「作り方を追加」とします
  • 29:44 - 29:48
    詳しい説明は任意なので
    使う必要はありません
  • 29:48 - 29:50
    今日は使わないでおきます
  • 29:50 - 29:51
    それから下の方に
  • 29:51 - 29:55
    2つの異なる変更―
    いえ オプションがあることがわかります
  • 29:55 - 29:57
    1つ目のオプションは
    GH Pages ブランチに
  • 29:57 - 30:00
    直接コミットするものです
  • 30:00 - 30:02
    ブランチについては
    まだあまりお話ししていませんが
  • 30:02 - 30:06
    基本的にブランチというのは
    一連のコードです
  • 30:06 - 30:11
    この例においては
    GH Pagesというのは
  • 30:11 - 30:14
    外部のウェブサイトに表示するための
    一連のコードのことです
  • 30:14 - 30:18
    ですから GH Pages ブランチに
    直接コミットすれば
  • 30:18 - 30:19
    すぐにオンラインにアップされ
  • 30:19 - 30:23
    レシピのウェブサイトに
    アクセスしている人全員が
  • 30:23 - 30:25
    加えた変更を見ることができます
  • 30:25 - 30:26
    そうしたいわけではありませんね
  • 30:26 - 30:29
    他の人たちが―
  • 30:29 - 30:31
    シェフがレシピを確認して
  • 30:31 - 30:33
    正しいかを確認したいかもしれません
  • 30:33 - 30:37
    ですからここでは
    新しいブランチを作成します
  • 30:37 - 30:40
    新しいブランチを作成すると
    ウェブサイトに表示される
  • 30:40 - 30:44
    ライブコードから
    変更を切り離して
  • 30:44 - 30:46
    コードに変更を加えたり
  • 30:46 - 30:50
    それについて会話をしたり
    何をすべきか話し合っても
  • 30:50 - 30:52
    完全に切り離して行えるので
  • 30:52 - 30:56
    ウェブサイトにあるコード自体には
    影響を与えずに済みます
  • 30:56 - 30:57
    ご存じのように
  • 30:57 - 31:00
    結局この変更は加えないことにすれば
  • 31:00 - 31:04
    このブランチを削除すればいいので
    変更はメインのサイトには
  • 31:04 - 31:06
    反映されません
  • 31:06 - 31:08
    この場合はブランチを作成し
  • 31:08 - 31:11
    「updating-recipe」
    と名前を付けましょう
  • 31:14 - 31:18
    それからproposed file changeに
    行きます
  • 31:20 - 31:25
    次のステップでPull Requestを
    作成するかどうか問われます
  • 31:25 - 31:27
    覚えているでしょうか
    少し前に
  • 31:27 - 31:30
    CONTRIBUTING.mdという文書を
    見ましたね
  • 31:30 - 31:32
    この黄色のボックスの中に
  • 31:32 - 31:35
    contributingのための
    ガイドラインが入っていますが
  • 31:35 - 31:36
    ここにファイルが現れます
  • 31:36 - 31:39
    ですから 今はやりませんが
    このリンクをクリックすれば
  • 31:39 - 31:43
    投稿のための
    説明を見ることができます
  • 31:43 - 31:46
    この場合は変更を加えたので
  • 31:46 - 31:48
    それについての
    ディスカッションをしたいので
  • 31:48 - 31:50
    次にすべきことは
  • 31:50 - 31:53
    同僚からのフィードバックを
    もらうことです
  • 31:53 - 31:56
    GitHubではPull Requestを
    作成することでそれを行います
  • 31:56 - 31:59
    ですからPull Requestを
  • 31:59 - 32:01
    変更をする前に
    コメントをもらうためのものであり
  • 32:01 - 32:04
    フィードバックをもらうためのものだと
    考えてください
  • 32:05 - 32:08
    ここではコメントを
    書き加えることができます
  • 32:08 - 32:11
    ここには例えばこんなコメントを
    書くことができます
  • 32:12 - 32:17
    「作り方を追加したので
    確認をお願いします」
  • 32:17 - 32:20
    (タイプする音)
  • 32:25 - 32:26
    こんな感じです
  • 32:26 - 32:29
    また そうしたければ
  • 32:29 - 32:32
    Issuesと同じように
    画像をドロップすることもできます
  • 32:32 - 32:34
    数分前にアレンが
    見せてくれましたね
  • 32:34 - 32:36
    このメモはなかなかいいですね
  • 32:36 - 32:38
    では先に進んで
    Pull Requestsを作成すると書いてある
  • 32:38 - 32:41
    大きな緑のボタンをクリックします
  • 32:44 - 32:48
    GitHubが自動的に
    会話を作成してくれました
  • 32:48 - 32:50
    オリジナルのコミットも追加されています
  • 32:50 - 32:52
    よく見てみると
  • 32:52 - 32:53
    「作り方を追加」と書いてあり
  • 32:53 - 32:57
    横には数字が書いてあります
  • 32:57 - 33:00
    これはコミットです
    そのバージョンを保存したので
  • 33:00 - 33:04
    同僚や友人がアクセスして
  • 33:04 - 33:06
    フィードバックをくれることのできる
  • 33:06 - 33:09
    コメントが追加されています
  • 33:09 - 33:11
    ここでの選択肢には
  • 33:11 - 33:14
    すぐにこれをマージする
    というものもありますが
  • 33:14 - 33:16
    ここではフィードバックをもらい
    ディスカッションをしたいと
  • 33:16 - 33:18
    考えています
  • 33:18 - 33:20
    そこで下へスクロールすると
  • 33:21 - 33:23
    Issuesで見たものと同じように
  • 33:23 - 33:27
    コメントを残すという
    オプションがあるのがわかります
  • 33:27 - 33:30
    続けてコメントをすることも
    ファイルに変更を加えることもでき
  • 33:30 - 33:33
    全てこのブランチ内の
    安全な場所に保管されます
  • 33:33 - 33:36
    メインページにアップする前に
  • 33:36 - 33:39
    完璧な物に仕上げられます
  • 33:40 - 33:42
    Pull Requestのいいところは
  • 33:42 - 33:45
    変更を表示するオプションを
    与えてくれるところです
  • 33:45 - 33:50
    トップに行き
    Files Changedを見ると
  • 33:51 - 33:54
    画面を提示してくれます
  • 33:54 - 33:57
    オリジナルのファイルは左側
  • 33:57 - 34:00
    追加や変更後のものは右側です
  • 34:00 - 34:03
    この場合 いくつか
    追加しただけなので
  • 34:03 - 34:06
    新しい部分を緑のハイライトで
    示してくれています
  • 34:06 - 34:10
    何か削除されたものがある場合は
    赤で表示されるので
  • 34:10 - 34:12
    どこが削除されたかわかります
  • 34:12 - 34:14
    これによって
  • 34:14 - 34:15
    誰かがPull Requestを作成した場合
  • 34:15 - 34:19
    実際に何が変更されたかが
    わかるためとても便利です
  • 34:19 - 34:23
    コードレビューを行う
    より複雑なプロジェクトにも便利で
  • 34:23 - 34:26
    このようなものを...
  • 34:27 - 34:30
    コードを見て
  • 34:30 - 34:33
    何が変わったか知りたいと
    思うかもしれません
  • 34:33 - 34:35
    これを他のツールと
    統合することができます
  • 34:35 - 34:38
    continuous integration toolsという
    ツールがあり
  • 34:38 - 34:41
    Pull Requestを提出すると
  • 34:41 - 34:44
    自動的にコードをチェックして
  • 34:44 - 34:46
    正しいか確認してくれます
  • 34:46 - 34:48
    とてもいいツールです
  • 34:48 - 34:53
    これらについての詳細は
    github.com/integrationsでどうぞ
  • 34:56 - 34:59
    この場合では
  • 34:59 - 35:01
    もっと詳しい作り方が
    必要かもしれません
  • 35:01 - 35:04
    材料を生地に入れて焼いたら
  • 35:04 - 35:05
    終わりではなさそうです
  • 35:05 - 35:08
    ですから この行にメモを加えます
  • 35:08 - 35:12
    「材料を生地に入れる
    ここにもう少し説明が必要」
  • 35:13 - 35:15
    この行をクリックすることで
  • 35:15 - 35:17
    行コメントを挿入することができます
  • 35:17 - 35:21
    これもコードについて
    コメントをする場合にはとても便利です
  • 35:21 - 35:23
    ここでもMarkdownが
    サポートされています
  • 35:23 - 35:27
    このコメントに画像を
    付け加えることもできます
  • 35:27 - 35:30
    そしてCommentを
    クリックするだけです
  • 35:35 - 35:39
    この場合 もう少し作り方を
    加える必要があるので
  • 35:39 - 35:42
    ファイルに戻りましょう
  • 35:43 - 35:46
    (クリックする音)
  • 35:56 - 35:59
    オンライン・エディターを使って
  • 35:59 - 36:01
    再び変更を加えるオプションがあります
  • 36:01 - 36:06
    この場合は 材料を生地に入れて
    焼くのですが
  • 36:06 - 36:10
    メレンゲも作る必要があるでしょう
  • 36:10 - 36:12
    下に移動して
  • 36:12 - 36:16
    そこにトッピングのメレンゲを
    作るための指示も加えましょう
  • 36:25 - 36:26
    そして...
  • 36:30 - 36:32
    できました
    メレンゲを加えました
  • 36:34 - 36:37
    ここで今回聞かれるのは
  • 36:37 - 36:41
    「updateing-recipeのブランチに
    直接コミットしますか？」ということです
  • 36:41 - 36:45
    Pull Requestを通じて
    このファイルにたどり着いたので
  • 36:45 - 36:47
    メインのGitHub Pagesではなく
    このブランチを
  • 36:47 - 36:50
    更新しているのだと
    わかったのです
  • 36:50 - 36:53
    この場合は 「はい」
    そうするのがいいですね
  • 36:53 - 36:58
    ブランチを更新して
    変更をコミットします
  • 37:01 - 37:05
    さて2つの違いがわかるビューに
  • 37:05 - 37:07
    やってきました
  • 37:07 - 37:11
    メレンゲのトッピングを
    加えたことがわかります
  • 37:11 - 37:14
    なかなかいいですね
  • 37:14 - 37:17
    では会話に戻りましょう
  • 37:17 - 37:20
    ここで確認をして
  • 37:20 - 37:23
    お互いに更新してよいと
    考えていることを知らせるために
  • 37:23 - 37:26
    コメント欄に行きます
  • 37:26 - 37:27
    絵文字もよく使うので
  • 37:27 - 37:32
    小さな+1の絵文字を入力して
    サムズアップしたと伝えます
  • 37:35 - 37:36
    そしてCommentです
  • 37:38 - 37:41
    いいですね 次の段階に進めそうです
  • 37:42 - 37:46
    この例では トップに戻って
    見てみましょう
  • 37:46 - 37:48
    ほんの少しだけ戻って
  • 37:48 - 37:50
    レシピの全体行程を見ることができます
  • 37:50 - 37:56
    変更を加え始めてから
    レシピに起こったことがわかります
  • 37:56 - 38:00
    GitHub Teacherが
    作り方の説明を追加し
  • 38:00 - 38:03
    誰かがそれに対して
    「ここにもう少し説明が必要」という
  • 38:03 - 38:06
    コメントを追加して
  • 38:06 - 38:09
    これらの作り方を追加するための
    2回目のコミットが行われています
  • 38:09 - 38:12
    ここまではいいですね
  • 38:12 - 38:16
    先に進んで このPull Requestを
    マージしてみましょう
  • 38:16 - 38:19
    大きな緑のボタンをクリックします
  • 38:19 - 38:21
    このPull Requestをマージすることで
  • 38:21 - 38:23
    実際に行われるのは
    このレシピを―
  • 38:23 - 38:27
    メインのGitHub Pagesという
  • 38:27 - 38:29
    ブランチに戻すことで
  • 38:29 - 38:31
    公開し一般に見られるように
    するということです
  • 38:31 - 38:34
    今加えたばかりの変更を
    誰でも見られるようにするのです
  • 38:34 - 38:37
    別のとてもいい機能は
  • 38:37 - 38:40
    GitHubによって
    時間が節約できることです
  • 38:40 - 38:42
    オリジナルのIssueを参照すれば―
  • 38:42 - 38:44
    レモン・メレンゲ・パイに
    作り方を追加すべきだと
  • 38:44 - 38:49
    書かれたIssueを覚えていますね？
  • 38:49 - 38:53
    いくつかのキーワードが使え
    そのひとつはfixです
  • 38:53 - 38:56
    「これがfixする」とか
    「これがcloseする」と言うことができます
  • 38:58 - 39:01
    それからハッシュマークも使えます
  • 39:01 - 39:04
    そして開示されたあなたのIssueが
    引き寄せられたのがわかります
  • 39:04 - 39:07
    ですからPull Requestに
    関係しているIssueや
  • 39:07 - 39:09
    fixしようとしているIssueを
  • 39:09 - 39:10
    見つけることができ
  • 39:10 - 39:13
    リストがとても長い場合は
  • 39:13 - 39:15
    ここでやってみたように
    そのIssueに関する言葉を
  • 39:15 - 39:17
    タイプしてみればいいのです
  • 39:17 - 39:20
    レモン・アイスボックス・パイの
    作り方がありました
  • 39:20 - 39:23
    Issue 32です
    これをクリックして
  • 39:23 - 39:25
    マージすると確認します
  • 39:29 - 39:32
    Pull Requestが成功したとあるので
  • 39:32 - 39:33
    マージされ終了されました
  • 39:33 - 39:35
    このブランチはもう必要ないため
  • 39:35 - 39:37
    というのも もうからっぽですから―
  • 39:37 - 39:39
    これを削除できます
  • 39:41 - 39:44
    でもご心配なく
    オプションにあるように
  • 39:44 - 39:46
    いつでも回復できます
  • 39:46 - 39:49
    それではこのPull Requestに
    何が起こったかを見てみましょう
  • 39:49 - 39:52
    Pull Requestのトップへと
    スクロールすると
  • 39:52 - 39:55
    Pull Requestが
    マージされたとわかります
  • 39:55 - 39:56
    できました
  • 39:56 - 39:58
    でもあのIssueはどうなったのでしょう？
  • 39:58 - 40:01
    Issueに戻ってみてみましょう
  • 40:03 - 40:05
    ここではClosedを選びます
  • 40:05 - 40:06
    あのIssueがありますね
  • 40:06 - 40:09
    左手を見ればわかるように
  • 40:12 - 40:16
    このIssueはClosedに
    移動されました
  • 40:17 - 40:19
    変更を加える方法の
  • 40:19 - 40:21
    簡単な紹介でした
  • 40:21 - 40:24
    前に言った通り
    直観的に行えます
  • 40:24 - 40:27
    次に何をすればいいかを
    きちんと教えてくれますし
  • 40:27 - 40:31
    最初のステップを覚えたら
    その通りに従うだけです
  • 40:31 - 40:33
    ファイルを編集して
  • 40:33 - 40:35
    変更をコミットして
  • 40:35 - 40:37
    Pull Requestを作成して
  • 40:37 - 40:40
    変更がまとまったら
  • 40:40 - 40:44
    Pull Requestを
    メインブランチにマージします
  • 40:45 - 40:46
    それに関して...
  • 40:46 - 40:50
    プロジェクトを管理するのに
    いくつかお見せするものがあります
  • 40:50 - 40:53
    ここでアレンにバトンタッチして
  • 40:53 - 40:55
    彼にチーム・メンバーの追加方法と
  • 40:55 - 40:58
    チーム・メンバーの進捗を
    確認する方法を見せてもらいましょう
  • 40:59 - 41:01
    (アレン) わかりました
    ありがとう シンシア
  • 41:01 - 41:03
    それでは残りの時間で
  • 41:03 - 41:05
    プロジェクトに関わっている人材を
  • 41:05 - 41:07
    管理するために使えるツールを
  • 41:07 - 41:10
    いくつか紹介します
  • 41:10 - 41:14
    コード・リソースや
    それを用いるためのツールとは
  • 41:14 - 41:15
    対照的なものです
  • 41:16 - 41:19
    まずシンシアの言ったような
    さらなるコミュニケーションを
  • 41:19 - 41:23
    管理するのに使える1つ目の方法は
    チームを使うことです
  • 41:23 - 41:26
    この例では いくつかのことを
    前提としています
  • 41:26 - 41:28
    個人アカウントではなく
    企業アカウントを
  • 41:28 - 41:30
    持っていると仮定しています
  • 41:30 - 41:35
    レポジトリに戻って
  • 41:36 - 41:40
    右側にあるsettingsを
    クリックしましょう
  • 41:41 - 41:44
    そこにCollaboratorsの
    オプションがあります
  • 41:47 - 41:51
    パスワードをここに入力します
  • 41:56 - 41:58
    現在このレポジトリは
    1つのチームに結びつけられていると
  • 41:58 - 42:01
    わかりますね
  • 42:01 - 42:02
    これはオーナーのチームなので
  • 42:02 - 42:05
    この場合はオーナーが
    レポジトリのすべてを管理します
  • 42:05 - 42:07
    ですが人をまとめるような
  • 42:07 - 42:09
    チームを作ることにしましょう
  • 42:09 - 42:12
    そうすることでチームが
    活用できます
  • 42:12 - 42:15
    ここで言うチームは
  • 42:15 - 42:17
    Outlookのような配布グループと
  • 42:17 - 42:19
    Active Directoryのような
  • 42:19 - 42:22
    アクセス管理グループを
    折衷したようなものです
  • 42:22 - 42:25
    レポジトリへのアクセスを
    管理するために使えます
  • 42:25 - 42:28
    しかし実にすごいのは
    人をグループにまとめるので
  • 42:28 - 42:33
    複数の人が会話に一度に
    参加できるということです
  • 42:33 - 42:35
    ここでベジタリアンのグループを作ります
  • 42:35 - 42:38
    このレポジトリを
    閲覧することができるグループです
  • 42:38 - 42:42
    会話を進めたり 違う方向へ導くのに
  • 42:42 - 42:45
    どうやって使えるかを見ていきましょう
  • 42:45 - 42:49
    それではレポジトリに戻って
  • 42:52 - 42:54
    おっとすみません
    ここに飛でしまいました
  • 42:54 - 42:57
    チームに人を追加しましょう
  • 42:57 - 42:59
    それではsettingsと
  • 43:00 - 43:02
    Collaboratorsに戻って
  • 43:04 - 43:07
    既存のチームを選びます
  • 43:07 - 43:08
    ベジタリアンがここにあるので
  • 43:08 - 43:11
    Vegetarians そして
    add teamをクリックします
  • 43:12 - 43:14
    チームには1人いるようですが
  • 43:14 - 43:18
    このチームをレポジトリに追加します
  • 43:18 - 43:21
    レシピ集に戻ってもいいですし
  • 43:21 - 43:24
    もっと人を追加してもいいですね
    シンシアはどうでしょう
  • 43:24 - 43:26
    チームに入りますか？
  • 43:26 - 43:28
    それからGitHub Studentも
    追加しましょう
  • 43:37 - 43:40
    とても簡単です　GitHubが自動的に
    名前の続きを入力してくれるので
  • 43:40 - 43:43
    人を追加するのがすぐに終わります
  • 43:43 - 43:47
    それではプロジェクト・マネジメントの
    レシピ集に戻りましょう
  • 43:48 - 43:51
    Issueを見てみましょう
  • 43:52 - 43:57
    Issueを進めるのに
    チームを使う方法を見ていきます
  • 43:57 - 44:02
    このIssue 26に「野菜を使った副菜を
    追加する」とあります
  • 44:02 - 44:06
    シンシアがここに新しいレシピを
    提案してくれたようです
  • 44:06 - 44:09
    彼女は人参とインゲン豆と
    アーティチョークを使った
  • 44:09 - 44:11
    レシピはどうかと言っています
  • 44:11 - 44:13
    私はコメントを返して
  • 44:13 - 44:16
    「厳密に言ってアーティチョークが
    野菜なのかわからない」と言いました
  • 44:16 - 44:19
    プロジェクト・マネジャーとして
    とてもいいのは
  • 44:19 - 44:22
    ベジタリアンのチームを
    会話に加えて
  • 44:22 - 44:24
    「この件を考えてみてくれないか―
  • 44:24 - 44:28
    君たちの方が野菜について
    詳しいと思うんだが？」と言えることです
  • 44:30 - 44:36
    ベジタリアンの人たちを
    @を使ってメンションできます
  • 44:44 - 44:47
    そして「ベジタリアンの皆さん
    どう思いますか？」と言えます
  • 44:47 - 44:51
    コメントをすれば
    その配布グループにいる人全員に
  • 44:51 - 44:53
    チーム全体に通知が行きます
  • 44:53 - 44:57
    ベジタリアンにマウスのポインタを
    合わせみると 誰がいるかわかります
  • 44:58 - 45:00
    チームに誰がいるか
  • 45:00 - 45:03
    見られますし
    誰の注意を引いたか―
  • 45:04 - 45:06
    誰から返信が得られそうかが
    わかります
  • 45:11 - 45:15
    次にお話ししたいのは
    Graphsというツールです
  • 45:19 - 45:22
    このGraphsツールには
    様々ありますが―
  • 45:22 - 45:25
    今日お見せするのは
    Contributorsタブです
  • 45:27 - 45:30
    これはプロジェクト内で
    誰が何をやっているかを
  • 45:30 - 45:33
    知るためにはとてもいい方法です
  • 45:33 - 45:38
    graphをフィルターにかける方法が
    いくつかあります
  • 45:38 - 45:40
    今はcommitsで
    フィルターがかけられていますが
  • 45:40 - 45:42
    AdditionsやDeletionsを
    使うこともできます
  • 45:42 - 45:45
    Additionsについていうと
    レポジトリに
  • 45:45 - 45:48
    コードを追加した人たちです
  • 45:48 - 45:53
    Deletionsにすると 同じことで
    コードを削除した人たちです
  • 45:53 - 45:56
    Commitsでフィルターをかけると
  • 45:56 - 45:59
    additionsであろうと
    deletionsであろうと
  • 45:59 - 46:02
    変更を加えた人たちが表示されます
  • 46:02 - 46:05
    さてブラウザでタブを
    1つ開いていますが
  • 46:05 - 46:08
    これはこのレポジトリには
    そこまでデータがないからです
  • 46:08 - 46:10
    ここを見ると
  • 46:10 - 46:13
    GitHub Training Kitの
    Contributorsですが―
  • 46:13 - 46:16
    これはパブリック・トレーニング・キットの
    レポジトリなので
  • 46:16 - 46:18
    これらはオープンソースの資料で
  • 46:18 - 46:20
    もっと大きなタイムラインがあります
  • 46:20 - 46:24
    活動がどのように変動しているかが
    わかりますね
  • 46:24 - 46:26
    Contributorsのグループが
    ずっと大きいので
  • 46:27 - 46:30
    このレポジトリに誰がコードを
    pushしているかがわかります
  • 46:30 - 46:34
    今はジョーダン・マカラーが
    一番活発なようです
  • 46:34 - 46:42
    彼は236,237行ものコードを
    レポジトリに入力しています
  • 46:43 - 46:45
    このタイムラインはとても長いですが
  • 46:45 - 46:49
    2014年の活動だけを
    見たいとしましょう
  • 46:49 - 46:52
    例えば 2月から3月までとすると
  • 46:52 - 46:55
    graphをクリックして
    ドラッグすると
  • 46:55 - 47:00
    上にある緑のものを
    横へとドラッグすると
  • 47:01 - 47:03
    タイムラインと連動して
  • 47:03 - 47:08
    選択された特定の期間だけを
    拡大して見られます
  • 47:08 - 47:12
    これらの曲線をもう少し
    細かく見たいなら
  • 47:12 - 47:13
    横にドラッグすれば
  • 47:13 - 47:18
    GitHubが自動的にその期間を
    見せてくれます
  • 47:18 - 47:20
    どんな活動が行われているかを
    見るのに便利ですが
  • 47:20 - 47:23
    とりわけ誰が行っているかが見られます
  • 47:32 - 47:35
    最後にPulseタブを
    見ておきましょう
  • 47:36 - 47:39
    レポジトリの中を掘り下げて
  • 47:39 - 47:44
    IssuesやPull Requestsを
    管理する方法を
  • 47:44 - 47:46
    かなり詳細に見てきましたが
  • 47:46 - 47:48
    特にGraphsツールを通じて
  • 47:48 - 47:51
    どんな変更が行われ
    誰がコードを書いているかが
  • 47:51 - 47:53
    良く見えます
  • 47:53 - 47:56
    Pulseタブは一歩下がって
  • 47:56 - 47:58
    プロジェクトを
    ある種遠くから見るものですが
  • 47:58 - 48:01
    より高次から眺めるので
    どんな活動が行われているかが
  • 48:01 - 48:03
    よくわかります
  • 48:03 - 48:10
    GitHub プロジェクト・マネジメントの
    レシピ集のレポジトリに戻りましょう
  • 48:11 - 48:15
    ここにあるPulseタブを使い
  • 48:15 - 48:18
    もう少し活動が行われているからです
  • 48:19 - 48:24
    いくつPull RequestsやIssuesが
    開示されたか
  • 48:25 - 48:26
    また終了されたかがわかります
  • 48:26 - 48:29
    たくさん新しいIssuesが
    入ってくるものの
  • 48:29 - 48:32
    あまりIssuesが
    終了されていない時期に
  • 48:32 - 48:36
    より掘り下げて何が起こっているかを
    確認したいときに使うといいでしょう
  • 48:37 - 48:39
    下にはこの数値の内訳が
    書かれているので
  • 48:39 - 48:43
    上記の数値に
    どのPull Requestsや
  • 48:43 - 48:46
    Issuesが貢献しているかがわかります
  • 48:46 - 48:52
    例として開示されている
    Pull Requestsのひとつを見てみましょう
  • 48:53 - 48:56
    このツールを使って
    直面するかもしれない
  • 48:56 - 48:59
    ワークフローでの問題を
    掘り下げる方法を見ていきます
  • 48:59 - 49:02
    例えば Pull Requestのひとつは
  • 49:02 - 49:08
    レビューが必要な副菜のレシピです
  • 49:08 - 49:09
    4日間開示されていますが
  • 49:09 - 49:11
    あまり活動はされておらず
  • 49:11 - 49:13
    開示されてから終了されていません
  • 49:13 - 49:19
    このPull Requestにおける
    会話をチェックしてみましょう
  • 49:20 - 49:25
    誰かが副菜のアイディアを提出し
  • 49:25 - 49:27
    GitHub Teacherがコメントを返しています
  • 49:27 - 49:31
    「Crockpotというのは商標化された
    名前では？」と言っています
  • 49:31 - 49:34
    プロジェクト・マネジャーとして
    ここで行き詰っていることがわかるので
  • 49:34 - 49:36
    コメントを返すのもいいでしょうが
  • 49:36 - 49:39
    このレシピ集のレポジトリにある
  • 49:39 - 49:43
    法律関係のチームを引き入れて
  • 49:45 - 49:48
    彼らを@を使ってメンションします
  • 49:55 - 49:57
    このIssueを先に進めるために
  • 49:57 - 50:01
    考えてみて答えをくれるように
    頼むのです
  • 50:04 - 50:08
    コミュニケーションを増やすことを
    目的としているので
  • 50:08 - 50:11
    行き詰まりの原因かもしれない
    問題を見つけて
  • 50:11 - 50:14
    デベロッパーが仕事を
    終えられるように手助けするのです
  • 50:15 - 50:16
    そこでコメントを返してみました
  • 50:16 - 50:19
    「法律部門の人へ
    『Crockpot』は使えますか？」
  • 50:19 - 50:22
    法律部門が通知を受け取ってから
  • 50:22 - 50:24
    コメントを返してくれて
  • 50:24 - 50:26
    このissueを解決に導く
    手助けをしてくれるといいのですが
  • 50:26 - 50:30
    解決したらPull Requestを
    マージすることができます
  • 50:35 - 50:39
    ここで少し振り返りましょう
    時間がなくなってきました
  • 50:39 - 50:43
    色々なことをお話ししました
  • 50:43 - 50:46
    レポジトリの高次ビューや
  • 50:46 - 50:50
    レポジトリに何が含まれ
    ファイルをどうやって管理するかなど
  • 50:53 - 50:57
    入ってくる仕事量を管理するため
    Issuesを使う方法や
  • 50:57 - 51:00
    Issuesにフィルターをかけたり
    並べ替えたり
  • 51:00 - 51:05
    Labelを割り当てたり
    あるIssueを特定のスタッフに
  • 51:05 - 51:08
    割り当てる方法もです
  • 51:08 - 51:10
    Milestoneを使って一歩引いて
  • 51:10 - 51:13
    そのIssuesが何に貢献しているかを
    確認する方法も見ました
  • 51:16 - 51:18
    Pull Requestを使って
  • 51:18 - 51:20
    その方程式の反対側―
  • 51:20 - 51:22
    つまり入ってくる仕事の管理の後は
  • 51:22 - 51:23
    済んだ仕事の管理を
    しなければならないので
  • 51:25 - 51:27
    管理し レビューを行い
  • 51:27 - 51:29
    必要があれば承認もします
  • 51:29 - 51:32
    それから活動を報告するために
  • 51:32 - 51:34
    使えるツールもいくつか紹介しました
  • 51:34 - 51:37
    GitHubの言葉を借りて言えば
  • 51:37 - 51:40
    レポジトリで起こっていることや
  • 51:41 - 51:46
    その活動がどんなものかという
    脈動を知るためのツールです
  • 51:47 - 51:51
    これらを念頭に置いて
  • 51:51 - 51:57
    少しQ&Aを行うことにしましょう
  • 51:57 - 52:00
    質問があればどうぞ
    速すぎてわからなかったから―
  • 52:00 - 52:04
    くり返してほしいというのでも
    歓迎です
  • 52:04 - 52:08
    質問を質問ボックスに入力してください
  • 52:08 - 52:10
    時間の許す限り
    できるだけたくさん
  • 52:10 - 52:13
    お答えしたいと思います
  • 52:15 - 52:18
    (シンシア) 皆さんがサインオフする前に
  • 52:18 - 52:22
    このコースはGitHubでできることの
  • 52:22 - 52:24
    ほんの紹介です
  • 52:24 - 52:27
    月に一度―
  • 52:27 - 52:29
    公開コースも開講しています
  • 52:29 - 52:32
    オンラインですから
    仕事のある日にも受講できます
  • 52:32 - 52:37
    GitHubの使い方をもっと深く
    お教えします
  • 52:38 - 52:43
    あなたのワークフローや
    チームのワークフローの使い方―
  • 52:43 - 52:46
    効果的に協力的に
    仕事ができるようになります
  • 52:46 - 52:49
    ぜひ興味があれば
  • 52:49 - 52:52
    スケジュールをご覧になって
    クラスに登録してください
  • 52:52 - 52:54
    そのクラスでまたお会いしましょう
  • 52:54 - 52:57
    最後にひとつアンケートを出しますね
  • 52:57 - 52:59
    このクラスを行うのは初めてなので
  • 52:59 - 53:02
    今後改善できるように
    フィードバックをもらえると
  • 53:02 - 53:04
    ありがたいです
  • 53:04 - 53:07
    できれば 全般的な意見―
  • 53:07 - 53:10
    今日のクラスをどう思ったかを
    教えてください
  • 53:10 - 53:12
    もう少し私たちは残って―
  • 53:12 - 53:15
    質問タブに上がった質問に
    答えたいと思います
  • 53:15 - 53:16
    どうもありがとうございました
  • 53:16 - 53:18
    (アレン) シンシア
    それではここで
  • 53:18 - 53:21
    いくつか質問が来たようなので
  • 53:22 - 53:24
    答えてみましょうか
  • 53:24 - 53:25
    ある質問は―
  • 53:25 - 53:29
    「GitHubと他のサービスを
    統合する方法は？」です
  • 53:29 - 53:31
    端的に言えば できます
  • 53:31 - 53:33
    他のサービスと統合することは可能です
  • 53:33 - 53:38
    例えば GitHubを
    気に入っているCIツールと
  • 53:38 - 53:40
    統合したいとします
  • 53:40 - 53:43
    コードレビューとコードテスティングに
    continuous integrationを
  • 53:43 - 53:45
    使うなどします
  • 53:46 - 53:50
    GitHubは他の多くのプラットフォームと
    統合できますので
  • 53:50 - 53:53
    例えば...
    ここに私の画面を出しますね
  • 53:53 - 53:57
    github.com/integrations
  • 53:57 - 53:59
    あなたが気に入って使っているツールのうち
  • 53:59 - 54:01
    統合できるすべてが
  • 54:01 - 54:03
    書かれたサイトがあります
  • 54:03 - 54:05
    ここを見てみると
  • 54:05 - 54:08
    AsanaやPivotalTracker
    Zendeskなども可能だとわかります
  • 54:09 - 54:12
    Travis CIやCloudBeesや
    Circle CIなど
  • 54:12 - 54:17
    GitHubは多くのサービスと
    統合できます
  • 54:17 - 54:20
    より高いレベルでの答えとしては
  • 54:20 - 54:22
    他のサービスと統合でき
  • 54:22 - 54:24
    GitHub web hooksを使います
  • 54:25 - 54:30
    これは別のウェビナーの
    トピックなので
  • 54:31 - 54:36
    ちゃんと説明するには
    もう少し詳細な情報が必要です
  • 54:36 - 54:38
    一般的に言えば
    それがプロセスです
  • 54:38 - 54:43
    GitHub webhooksを使って
    他のサービスと統合します
  • 54:44 - 54:46
    次を見てみましょう
  • 54:56 - 54:59
    質問は「様々なファイルタイプを
  • 54:59 - 55:02
    複雑なレポジトリを入れるための
  • 55:02 - 55:06
    アイディアを得るには
    どこに行けばいいでしょうか？」
  • 55:07 - 55:14
    これは質問の意図がよくわかりません
  • 55:20 - 55:23
    質問を言い直してもらってもいいですか？
  • 55:26 - 55:31
    (シンシア) その質問への
    答えのひとつとしては
  • 55:31 - 55:35
    GitHubがすでに大きな
    オープンソース・コミュニティを
  • 55:35 - 55:40
    形成しているので
    話題のレポジトリを見れば
  • 55:40 - 55:42
    新しい情報が得られます
  • 55:42 - 55:46
    GitHubにあなたのユーザー名で
    サインインしたら
  • 55:47 - 55:49
    ちょっと行ってみますね
  • 55:51 - 55:54
    GitHub Teacherを見てみます
  • 56:21 - 56:23
    そうですね
  • 56:28 - 56:30
    アレン あなたの画面でやってみて
  • 56:30 - 56:32
    ちょっとここでは難しいので
  • 56:32 - 56:34
    - (アレン) いいよ
    - (シンシア) github.comに行って？
  • 56:34 - 56:36
    (アレン) もちろん
    すみませんね
  • 56:36 - 56:40
    テクノロジーは素晴らしいね？
    (シンシアの笑い声)
  • 56:40 - 56:43
    話題のレポジトリを見るということで
    いいのかな？
  • 56:43 - 56:44
    そうだね
  • 56:45 - 56:48
    (シンシア) ええ ありがとう
    ここでわかるのは
  • 56:48 - 56:51
    様々なタイプのレポジトリがあって
  • 56:51 - 56:54
    これらはたくさん活動が
    行われているものです
  • 56:54 - 56:58
    もっと複雑なファイルタイプのものを
    見つけるには
  • 56:58 - 57:00
    ここから始めるのがいいかもしれません
  • 57:00 - 57:04
    役に立ったでしょうか？
    もっと特別な例の話でしたか？
  • 57:08 - 57:10
    いいですね
  • 57:12 - 57:14
    (アレン) 素晴らしい
  • 57:16 - 57:20
    これでセッションを終わりにしたいと思います
    ちょうど時間切れです
  • 57:20 - 57:24
    画面に私たちの
    連絡先を表示させておきますね
  • 57:26 - 57:31
    シンシア・リッチとアレン・スミス―
  • 57:31 - 57:34
    私たちはGitHubの講師です
  • 57:34 - 57:38
    シンシアにGitHubで
    コンタクトを取るには@crichIDまで
  • 57:38 - 57:42
    彼女のメールアドレスは
    crichID@github.comです
  • 57:42 - 57:49
    私のハンドルネームは@loranallensmith
    メールはloranallensmith@github.com
  • 57:49 - 57:52
    質問があればメールで連絡をしてください
  • 57:52 - 57:55
    気軽に声をかけてくださいね
  • 57:55 - 57:58
    (シンシア) ほんの数分しかないので
    手短に言いますが
  • 57:58 - 58:02
    GitHub Enterpriseの持つ
    オプションについての良い質問が来ました
  • 58:02 - 58:05
    これは大きな問いです
  • 58:05 - 58:10
    GitHub.comと
    GitHub Enterpriseの機能が
  • 58:10 - 58:13
    対等であるようにしているので
  • 58:13 - 58:15
    今日ご覧になったほとんどは
  • 58:15 - 58:17
    Enterpriseでも利用できます
  • 58:17 - 58:20
    とは言うものの Enterpriseには
  • 58:20 - 58:23
    実質的な違いがあります
  • 58:23 - 58:26
    GitHub.comでは変更をいつでも
    送信できるのに対して
  • 58:26 - 58:30
    Enterpriseでは管理者によって
  • 58:30 - 58:33
    いつ最新のアップデートが
    ロードされるか管理されます
  • 58:33 - 58:37
    常に同じissuesが見られないのは
    そのためです
  • 58:37 - 58:42
    それでも .comの方で利用できるのは
  • 58:42 - 58:44
    Enterpriseでも使えるように
    努力しています
  • 58:44 - 58:47
    今日扱った中で特定の機能が
  • 58:47 - 58:49
    Enterpriseでも使えるか知りたければ
  • 58:49 - 58:52
    知らせてください
    お答えできます
  • 59:15 - 59:18
    (シンシア) さてちょうど1時間が経ちました
  • 59:18 - 59:21
    皆さん 参加してくださって
    ありがとうございました
  • 59:21 - 59:22
    質問もありがとう
  • 59:22 - 59:26
    アレンが言ったように
    質問がまだあれば
  • 59:26 - 59:28
    私たちのどちらかに
    直接ご連絡ください
  • 59:28 - 59:31
    今日の参加をありがとうございました
Title:
Webcast • Github for Project Management
Description:
more » « less
Video Language:
English
Team:
GitHub
Project:
Webcasts
Duration:
59:32
There has been no activity on this language so far.

Japanese subtitles

Revisions Compare revisions

Our website uses cookies for analysis purposes.