Prologue

こんにちは、@dz_ こと、岩永かづみです。

この記事は、Qiita x Code Polaris共催！女性ITエンジニアが作るアドベントカレンダー Advent Calendar 2022 の25日目の投稿です🎄🎁

さて、日々エンジニアをたしなんでいる皆さまは、GitHub がなくてはならない存在になってますよね。「GitHub がダウンしているので仕事は終わり」なんてツイートも見かけます。

直接利用していなくても、利用しているフレームワークやライブラリが GitHub でホストされていたり、利用しているソフトウェアの配布に GitHub が利用されているようなケースもあるでしょう。

そんな GitHub は今や単なる開発のための「Git のリポジトリ」だけに留まらず、コラボレーションのための機能が日に日に拡充されています。機能は多岐にわたり、リリースの速度は目を見張るものがあります。まだ把握されていない機能もあるのではないでしょうか？あなたのプロジェクトでお困りのことも、GitHub を利用すれば効率的に解決できるかもしれません。今一度、GitHub の機能をおさらいしてみましょう🎄

なお、ここで全てを網羅することはできないので、注目していきたいポイントを厳選してご紹介します。全部を知りたい方は GitHub Docs を眺めるのがおすすめです🔍

これから GitHub を使い始める方へ

GitHub と Git

最初にこれだけはしっかり把握しましょう！

まず、Git とは、分散バージョン管理システムです。
そして、GitHub とは、Git を用いた開発・コラボレーションのためのプラットフォームです。

この二つを混同すると話がかみ合わなくなってしまうので、今一度お確かめくださいね😉

Git

Git は、前述のとおり分散バージョン管理システムであり、git コマンドを用いてファイルのバージョン（履歴）を管理していきます。

Git では、「リポジトリ」という単位でバージョンを管理します。リポジトリは、ローカルマシン上に作成することもできるし、GitHub などの共有部に用意してローカルと接続することで、他のメンバーとコードを共有して開発を進めることができます。

このリポジトリの中では、「ブランチ」としてバージョン（履歴）の連なりを分岐させることができ、この仕組みを利用することで各々の作業を分離した状態で開発することができるようになります。一般的な作業フローについては、後述の「GitHub フローによる開発」をご参考ください。

Git についてもう少し知る

バージョン管理システム自体は古くからあり、中央集権型のもの（Subversion など）が主流でしたが、必ずサーバーが必要で融通が利きにくい側面がありました。そこで、分散型として git や Mercurial が登場し、デメリットであったサーバーを必要とせず、ローカルでバージョンを管理でき、またそのバージョンを相互に統合する仕組みが柔軟で使いやすく普及しました。

実際の Git の操作は、まずバージョン管理の "本線" から「ブランチ」を分けて変更を加えていきます。その変更は、2段階コミットという形式で、"ステージングに追加" してから、"コミット" していきます。ステージングは「この変更をバージョン管理下に置きますよ」と宣言するようなもので、ステージングにあげていない変更はバージョン管理には含まれません。この辺り、最初は慣れないかもしれませんが、詳しく解説している記事もたくさんありますし、もしプロジェクトで一括でトレーニングを行いたい場合は私が講師を務めるトレーニングプログラムがありますので、ぜひお声がけください😉

また、git コマンドは覚えると便利ですが、今は使いやすい GUI クライアントも複数あり、エディタや IDE（統合開発環境）でも連携していることが多いため、とっつきやすいところから始めるとよいでしょう。以下にいくつかご紹介します。

リポジトリが持つ機能

GitHub の中心となる「リポジトリ」だけでも、開発のための機能がたくさん用意されています。

Issues（イシュー）

タスクやバグの管理に利用します。後述の GitHub Projects と組み合わせることで、計画的に実装につなげていくことができるでしょう。

Issues や後述の Pull requests では、Markdown という記法を用いて、章立てや太字、コードの強調などを表現することができます。他の記法に比べて、Markdown の書き方はフォーマット前の素のテキストの状態でも見やすいことが特徴です。詳しくは、GitHub 上での執筆とフォーマットについて - GitHub Docs で確認してみてください。

また、Issues の書き方が煩雑になってしまう場合は、Issue テンプレートを用意しておくことで、必要な項目の入力を促したりフォーマットを揃えることができます。詳しくは、テンプレートを使用して便利な Issue やプルリクエストを推進する - GitHub Docs をご参考ください。

Pull requests（プルリクエスト）

プルリクエスト、略してプルリク、PRと呼ばれることも多いです。

Git における作業ブランチ上の変更を "本線" に統合（マージ）する前に、レビューを行うための仕組みです。

Git 単体ではレビューの実施が "運用（ルール）でカバー" になってしまうのですが、GitHub のプルリクエストを利用すれば、明示的にレビューを組み込むことができ、また issues と紐づけておくことで開発における経緯を把握しやすくなります。これなしでは開発できないくらい常用する機能です。

しっかり仕組みとしてプルリクエストを利用するには、Branch protection rule と組み合わせることを強くお勧めします。例えば、「マージ前にプルリクエストを必ず作成すること」「承認（approve）を必ず得ること」などのルールを指定することができます。詳しくは、保護されたブランチについて - GitHub Docs をご確認ください。

また、プルリクエストもテンプレートを用意することができます。詳しくは、テンプレートを使用して便利な Issue やプルリクエストを推進する - GitHub Docs をご参考ください。

GitHub フローによる開発

「GitHub フロー」という作業の形式が、導入しやすく広く利用されています。

GitHub フローでは、個々の作業（機能開発やバグ修正など）ごとにブランチを作成して作業します。作業を始めるときはまず、"本線"（※）から 1つのブランチを作成し、そのブランチ上で変更を行い、前述のプルリクエストを用いてレビューを行った後に、"本線" に統合（マージ）します。別の作業をするときは新たにブランチを作成します。

※ ここでは便宜的に "本線" として表現しておりますが、大抵の場合 main という名前のブランチを用います。

よくあるケースとしては、"本線" に他の変更が追加されたときも、作業中のブランチにその変更を取り入れることで、最新の状態を保ちながら自分の作業を進めることができ、最終的に "本線" に統合（マージ）するときもコンフリクト（変更箇所の衝突）を抑えることができます。

このように GitHub フローに従うことで、他者やほかの作業と分離して作業を進めることができ、また履歴も追いやすい形で構成していくことができます。

詳しくは、GitHub の下記ドキュメントをご参考ください。

GitHub を使い慣れている方へ

ここからは、GitHub をすでにお使いの方向けに、より便利にリポジトリを利用したり、リポジトリ以外にも使える機能があることをご紹介していきます。

Dependabot

まず、絶対有効にしてもらいたい機能 No.1 をご紹介します。

リポジトリ（デフォルトブランチ）に含まれるパッケージの依存関係を解析し、脆弱性の検出や修正の提案を行ってくれる機能群です。

脆弱性の情報を日々追い切れている開発者の方は、ほとんどいらっしゃらないかと思います。検出は GitHub に任せ、検出されたときはすぐに確認・対応ができるよう、特に Dependabot alerts および security updates を有効にしておくことを強くお勧めします！ 🚓🚨

機能	説明
Dependabot alerts	依存関係にあるパッケージに脆弱性が検出された場合にアラートを通知する
Dependabot security updates	Dependabot alerts で検出された脆弱性に対して、コードの修正案をプルリクエストとして提案してくれる
Dependabot version updates	依存関係にあるパッケージのバージョンにアップデートがある場合に、更新をプルリクエストとして提案してくれる

脆弱性の情報は、GitHub Advisory Database が参照されます。

リポジトリ個別に設定するのは面倒なので、個人や Organization の設定で、自動的に適用されるよう設定しておくと便利です。

なお、私のようにサンプルコードのリポジトリを大量に持っている人はたくさんアラートが上がってきます(笑) そんなときは、アラートを無効にするのではなく、リポジトリをアーカイブして明示的にメンテナンスの停止を示しておきましょう。

こちらでも取り上げているのでご参考ください。

また、この脆弱性の検出を GitHub Actions のワークフローで行いたい場合は、 Dependency review をご参考ください。便利です♪（パブリックリポジトリ、または GitHub Enterprise の Advanced security ライセンスを適用したプライベートリポジトリ）

GitHub Projects

これまでは、カンバンボードとして使えるカラム型のタスク管理だけができた GitHub Projcets ですが、新しく改良され、イテレーション管理ができるようになったり、カラムやビューのカスタマイズができるようになりました！

イテレーションの使い方については、こちらで雑談がてらご紹介しています。

https://youtu.be/t5DTPFm1PtE

また、11月に行われた GitHub Universe では、Roadmap（ガントチャートのような表示） のリリースも発表されました。現在は private beta 利用の申請が必要で、興味ある方はチェックしてみてください🔍

GitHub Discussions

これまで、機能や設計などについてのディスカッションは、issues で行われることも多かったのですが、それではタスクとごちゃごちゃになってしまい不便があったとのことで、新しく追加されたのがこの GitHub Discussions です。

掲示板のような使い方や、ヤ〇ー知恵袋のように質問と回答の形式で使うこともできるので、ワークショップでの質問受付けなどにも利用できます。Discussions での投稿は insights に反映されたりして、コミュニティのコミュニケーション活性化の助けにもなりそうです。

また、個人的に、使い方はディスカッションだけにとどまらないと考えており、私は調査などのメモを書き加えていくなどの使い方で利用しています。（Zenn のスクラップのような使い方ができます）

GitHub Actions

GitHub でコードを管理しているなら、CI/CD の構築は GitHub Actions が断然おすすめです。アクセス管理を GitHub で統合できますし、なにより、GitHub のプルリクエストとシームレスに連携できるので、プルリクエストごとのテストやステージング環境へのデプロイなども容易に導入でき、GitHub フローとの相性がとても良いです。

また、リポジトリのコードだけでなく、これまでボットの用意が必要だった issues のトリアージなども、GitHub Actions で簡単に記述することができるようになります。

無料利用枠も割と多く、安心して使うことができます。

1年ほど前ですが、このような記事も投稿したので、ご参考ください。

また、他のCIプラットフォームからワークフローを移行するための GitHub Acitons Importer のリリースも発表されています。サポートされる対象は、現時点では Azure DevOps、CircleCI、GitLab、Jenkins、Travis CI です。興味ある方はぜひ public preview を利用申請してみてください。

Secret scanning

GitHub 上のリポジトリにおける全てのブランチと履歴に対しスキャンを行い、"シークレット" の混入を検出してくれる機能です。

シークレットとして扱われる文字列は、提携しているパートナープロバイダによって指定されたパターンと一致したものが検出されます。パートナープロバイダの提携は現在 66プロバイダで、続々と増えています。

なお、パブリックリポジトリでは、問答無用で有効です。

プライベートリポジトリについては、GitHub Enterprise の Advanced security ライセンスを適用しているリポジトリで利用できます。こちらは、上記パートナーによるシークレットパターンに加え、独自のパターン定義を検出させることができます。

Code scanning

GitHub リポジトリ上のコードに対する脆弱性を検出・管理できる機能です。

検出には、GitHub からは CodeQL が提供されており、GitHub Actions のワークフローで github/codeql-action アクションとして導入することができます。CodeQL は、各種言語に応じた汎用的なクエリが用意されており、カスタマイズも可能です。

また、他の静的解析ツールでも SARIF形式のレポートの出力があれば、それを GitHub にアップロードすることで一括して管理することができます。

パブリックリポジトリでは利用可能で、プライベートリポジトリについては、GitHub Enterprise の Advanced security ライセンスを適用しているリポジトリで利用できます。

GitHub Packages

以前からある機能ですが、あまり知られていない気がするので紹介します。

GitHub Packages は、各種言語のパッケージ、またはコンテナイメージを格納できるレジストリです。

サポートしている言語は、JavaScript、Ruby、Java、.NET です。

そして、Docker および OCI 仕様のコンテナイメージの格納にも対応しています。なお、以前は Docker registry という名称で docker.pkg.github.com という名前空間で提供されていましたが、現在は Container registry として ghcr.io という名前空間で提供されています。

Npm, nuget や Docker hub など公式のレジストリに公開にするほどではないが、共有して使いたいパッケージ/コンテナイメージを置くのに適しています。認証を GitHub で統一できる点も便利です。

GitHub Pages

こちらも以前からある機能で、静的サイトをさっと公開したい場合に重宝します。公開用 URL はリポジトリや Organization に紐づいた URL で生成されるので、デモアプリやドキュメントサイトなどの公開にもよく利用されています。カスタムドメインも利用できます。

https://docs.github.com/ja/pages

ポイントは、これまでは変更をコミットしてから反映までのデプロイの処理が裏側で行われていてカスタマイズがしにくかったのですが、去年末から GitHub Actions で処理が構成されるようになり、ビルド時のカスタマイズをしやすくなりました！詳しくは下記のリリースブログをご参考ください。

GitHub Codespaces

今年の一押しと来年の一押しはこれです！！！🚀🌟

GitHub Codespaces は、開発環境を GitHub 上で立ち上げることができ、いつでもどこでもアクセスして開発ができる画期的な機能です！

開発環境は、dev containers の仕組みで構成することができ、ベースとなるコンテナイメージの指定や、主要な言語やCLIのインストールを簡単に行うことができます。Dockerfile を指定することもでき、さらに深いカスタマイズも可能です。

この Zenn の記事も Codespaces のインスタンス上で書いています。変更は GitHub 上に保持されているので、作業を中断してもいつでも再開でき、出先で別のマシンから作業を継続することもできます。

なお、無用な課金を避けるために、タイムアウトや自動的削除の期間が設定されていますので、確認しておきましょう。 タイムアウトまたは明示的にインスタンスを停止する場合は変更は保持され再開できますが、インスタンスの自動削除が実行されるまたは明示的に削除した場合はそのインスタンス上の変更は失われます。そのため、長期間放置する場合は変更をリポジトリにコミットしておいた方が無難でしょう。（前提として、プロジェクトで他の変更とのコンフリクトを避けるためにも、長期間の放置は禁物ですね）

GitHub Codespaces の一般公開を記念して記事を書いたので、ぜひご覧ください🍩

また、これは宣伝ですが、来年1,2月に GitHub Codespaces を取り上げたセッションを担当しますので、ぜひ聞いてくださるとうれしいです！

2023年1月21日(土) VS Code Conference Japan 2022-2023
「GitHub Codespaces が拡げる開発環境、いつでもどこでも Visual Studio Code で！」

2023年1月25日(水) 開発を加速するGitHub x Azure 最新開発ベストプラクティス
「GitHub Codespaces と Azure でつくる、エンタープライズレベルの開発環境」

2023年2月9日(木) Developers Summit 2023
「もう悩まされない開発環境、プロジェクトで統一した環境をいつでもどこでも」

GitHub Copilot

もうひとつの注目の機能は、なんといっても GitHub Copilot ですね！

preview の頃から使っていますが、コードに応じた補完候補を提案してくれるのでとても便利です。もちろん、Copilot が提案してくれるコードや文章はあくまで提案であり、それが本当に適しているかどうか、人間による確認は必要ですが、単なる自動補完よりも適切な案を提示してくれることも多く、軽快にコードを書くことができます。

特に私が重宝しているのは、README や手順書を書いているときで、細かく説明を書くのは骨が折れますが、Copilot がいい感じに提案してくれるので手を動かす量が圧倒的に減るのです。

また、GitHub の実験的な検証について公開されている GitHub Next では、この Copilot のように AI を利用した機能がいくつか公開されています。ぜひチェックしてみてください🚀

GitHub Sponsors

こちらは 2019年ごろにリリースされた機能で、寄付の受入れ口をリポジトリやプロフィールに設けることができます。

オープンソースのソフトウェアやライブラリは、そのライセンスに従うことで無料で利用できますが、その開発に携わる方の労力はタダではありません。よく使うソフトウェアやライブラリ、応援したいメンテナさんが Sponsors を設置している場合はラッキーです。寄付することで、健全なエコシステムを支えることができます🎁

https://github.com/sponsors

お楽しみ🎁

お腹いっぱいの量になってしまいましたが、最後にお口直しを😉

GitHub のマスコットキャラクター Octocat

GitHub のマスコットとして登場する Octocat は、ねこの頭とたこの胴体をもつ生き物です。そして実は、この Octocat という名前はこのマスコットの「種別」の名称で、名前は Mona Lisa というんですよ😉

このネーミングは、なんと社員の娘さんの空想のストーリーから付けられたそうです。

ちなみに、いろいろな格好をした Octocat のステッカーを見たことがある人も多いと思います。こちらのサイトで自分の好みに自由にカスタマイズした Octocat を作れますよ♪ ぜひ遊んでみてください💎

https://myoctocat.com/

Epilogue

最後まで目を通してくださってありがとうございます！
軽く紹介するつもりが、今年の集大成ともいえるボリュームになってしまいました。

一記事にまとめるには厳選がとても難しいほどの GitHub、来年も注目ですね！

さいごに、筆者は今年、特に GitHub にお世話になりました。GitHub公認トレーナーとして、Git と GitHub を用いた開発の基礎を学ぶハンズオンや、Enterprise における管理を集中的に把握いただくトレーニングで講師を務めたり、GitHub をテーマにいくつもセッションでお伝えすることができました。

次々にリリースされる GitHub の新機能はどれも魅力的で、キャッチアップしてはお伝えしてと、エンジニア冥利に尽きる一年でした。

来年ももっと奥の奥まで GitHub を理解して、開発へどう活かしていけるかをお伝えできるよう、努めてまいります！🎍