第三章 - 百家争鳴のセルビチウム

たとえばラボメンと共同で何か作業する場合、作業状況を共有するためにGitリポジトリは必要です。しかしそのためにサーバーを用意してGitを設定してという手順をするのは面倒です。 GitHubがあれば簡単にリポジトリを作れます。きっとダルあたりが「Gitリポジトリを一から設定するのなんて面倒くさいだろ常考」とか言いながらGitHub上に作業用のリポジトリを作ってくれることでしょう。

このようにGitHubはGitリポジトリを作り保持できるGitリポジトリのホスティングサービスです。 GitHubはリポジトリを作って保持してくれるだけではなくチーム開発の役に立つさまざまな機能を持っています。それぞれの機能について見ていきましょう。

Issue

Issueは現在のリポジトリにある問題点や改善点をみんなで議論できます。 未来ガジェット研究所でおこなわれている円卓会議をインターネット上でおこなえるものと考えれば問題ありません。

実際のIssueの例を見てみましょう。このSteins;Gitを書き始めた当初に作った、対象の読者を決めるためのIssue1 です。

GitHub上で対象の読者について話している様子

まずこのようにしたいという提起があり、それに対してこうしたほうが良いのではないかという返信があることを確認できます。 その結果「ネタバレは気にせずしていく」「シュタゲのアニメを全話見た人か、ゲームを第11章までクリアした人」「Gitを全く触ったことがない、もしくは触り始めたばかりの人」と方針を決めました。 このようにIssueはお互いに議論しつつ、最終的にどういった方向性にするかという結論を出すのに使えます。

今回の例では関わる人数が少ない状態で議論していることからコメントの数は少ないですが、数十人やそれ以上が関わるリポジトリだと数十のコメントがある場合もあります。

Pull Request

Pull Requestは他のリポジトリに対して、問題点や改善したい点の修正をしたときに、その修正を取り込んでもらうよう依頼するときに使います。 例として自分がvivliostyle-uiというリポジトリに対して送ったPull Request2 を見てみます。 これはもともとJavaScriptで書かれたコードをTypeScriptに変換するPull Requestです。

vivliostyle-uiに対して送ったJavaScriptで書かれたコードをTypeScriptへ変換するPull Request

このようにPull Requestの概要欄にこれはどのようなPull Requestで、どういったきっかけでやることにしたのか、またやったことの詳細などが書かれています。

つまりPull RequestはラボメンがDメールやDラインを送る場合に岡部倫太郎へ文言を見せたあとDメールやDラインを送る行為です。 たとえば桐生萌郁が「携帯の機種変に失敗したので前の携帯を使い続ける」旨のDメールを送ろうとしたとき、岡部倫太郎に見せてからDメールを送りました。 これと同じことをGitHub上でもPull Requestという形でおこなえます。

コードを見る人は見た結果をPull Requestを送った人に対して伝えられます。 これをコードレビューと言います。自分のリポジトリでない限りは送ったPull Requestに対してコードレビューがあります。

ただコメントするだけか、Pull Requestを承認または一旦拒否するかを選べる

Steins;Gateで桐生萌郁がDメールを送る直前に文言を差し替えたことは、変更が問題ないと承認されてから変更を加えたことになります。 承認されていない変更なのでバグが起きる可能性もあります。実際にSteins;Gateでは世界線変動が起きて岡部倫太郎の主観からは桐生萌郁が消えたように見えました。 そのため承認された後は何も変更を加えないようにするのが良いと言えます。 実際にGitHub上にはコードレビューをした後にあらためてコードレビューをおこなわないとマージをおこなえなくする設定があります。

Project

ProjectはIssueやPull Requestなどを特定のまとまりにできます。

Projectはオペレーションと言えます。 β世界線の岡部倫太郎を奮い立たせるべく過去へ行き、そして戻れなくなった椎名まゆりと阿万音鈴羽を、岡部倫太郎が迎えに行くオペレーションがあります。 そのオペレーションに対して岡部倫太郎は「オペレーション・アルタイル」と名付けました。 この「オペレーション・アルタイル」というのが一つのプロジェクトと言えます。GitHub上のProjectにオペレーション・アルタイルがあった場合、次のようなIssueなどが登録されていることでしょう。

  • タイムマシンを作る
  • C203型タイムマシンを追跡するためのレーダーを作る
  • タイムマシンを発射する

脆弱性検知

脆弱性とはJIS Q 27000:20193 の3.77によると次の意味になります。

一つ以上の脅威（3.74）によって付け込まれる可能性のある，資産又は管理策（3.14）の弱点。

同じくJISの3.74の脅威を見てみると次の意味が書かれています。

システム又は組織（3.50）に損害を与える可能性がある，望ましくないインシデントの潜在的な原因。

椎名かがりには牧瀬紅莉栖の記憶が移植されていました。また特定の音楽に反応し自分の意志とは関係なく行動をするように仕向けられていました。 移植の目的として牧瀬紅莉栖しか知りえない情報を椎名かがりを通して聞き出すことにあることが挙げられました。 これらはCAPECで定義されているRemote Code Inclusionと言われる脆弱性4でしょう。

GitHubにはこういった脆弱性を検知する仕組みが備わっています。 依存しているパッケージに脆弱性がある場合、次の画像のように脆弱性があることをGitHubのリポジトリページ上で表示してくれます。

依存しているパッケージに脆弱性があることを知らせる表示

チームの管理

GitHubではチームに関するさまざまな設定をおこなえます。 チームに所属させるにはGitHubのorganizationという複数プロジェクトを一元管理するためのアカウントで招待します。

ここまでは未来ガジェット研究所において、岡部倫太郎がラボメンバッジを配る行為と同じです。

ただGitHubのorganizationはただメンバーを属させるだけでなく、個々のリポジトリへのアクセス権を細かく設定できます。 岡部倫太郎が桐生萌郁に対してDメールに関する情報を渡しがらなかったり、比屋定真帆がレスキネン教授とレイエス教授の企みを盗み聞きしたりといった出来事が起こっていましたが、GitHubでアクセス権の管理をすればこういったことが起こらなくなります。

1. https://github.com/o2project/steins-git/issues/18 ↩
2. https://github.com/vivliostyle/vivliostyle-ui/pull/79 ↩
3. https://kikakurui.com/q/Q27000-2019-01.html ↩
4. https://capec.mitre.org/data/definitions/253.html ↩