GitHub は CLI バージョン 1.0 をリリースし、コマンドラインからリポジトリを操作および制御できるようになりました。
ホストされているリポジトリはgitをベースにしており、git自体はコマンドラインツールです。また、GitHub用のCLIを提供するhubというプロジェクトもあります。分かりにくいですか？
GitだけではGitHubの完全なエクスペリエンスを得るには不十分です。Gitは単なるリポジトリに過ぎないからです。例えば、GitHub Issuesの使用はGitの機能ではありません。HubはGitをラップすることですべてのGitコマンドをサポートしますが、これらのコマンドを拡張し、Issuesなどの管理に役立つGitHub固有の新しいコマンドを追加しています。
Hubがあるのに、なぜGitHub CLIが必要なのでしょうか？公式ドキュメントには次のように説明されています。「Hubをベースに開発を続け、公式GitHubプロジェクトとして採用するかどうか、私たちは苦慮しました。様々な可能性を検討した結果、Hubに組み込まれた10年間の設計上の制約や、Hubをgitに安全にエイリアスできるという前提にとらわれず、新たなスタートを切ることにしました。」
「私たちはGitHubのワークフローにもっとこだわりたいと思っていましたが、ハブでこれを行うと、既存のツールを愛用し、慣れ親しんだ方法で動作することを期待している多くのハブユーザーを遠ざけてしまうリスクがありました。」
GitHub CLIは公式ツールですが、hubは「GitHubの社員がメンテナーを務めるプロジェクト」とのことです。新しいツールは完全に代替するものではないため、hubは引き続き利用されます。
GitHub CLI を使用してプロジェクトの問題を一覧表示する
GitHub CLIは2月のベータ版から拡張されました。大きな変更点の一つは、GitHubのセルフホスト版であるGitHub Enterprise Serverのサポートです。リポジトリのクローン、作成、フォーク、HTTPSではなくSSHの使用、デフォルトエディターの設定、課題とプルリクエストの完全な管理（差分の確認やマージの実行を含む）などの新機能も追加されています。また、エイリアスを設定して、1つまたは複数のコマンドのショートカットを作成することもできます。
ダウンロードしたインストーラーを使用してWindowsにGitHub CLIをインストールしましたが、問題の1つで指摘されているように、64ビットアプリケーションであるにもかかわらず、Program Files (x86) に誤ってインストールされてしまいます。GitHub CLIはmacOS、Linux、Windowsで利用可能です。macOSユーザーはHomebrewとMacPorts、Linuxユーザーはリポジトリを追加してaptを使用する必要があります。一方、Windowsの場合、公式ドキュメントでは開発者にscoopまたはChocolateyパッケージマネージャーを勧めています。興味深いことに、GitHub CLI 1.0が既にMicrosoftの公式Windowsパッケージマネージャー（Winget）で利用可能であるにもかかわらず、ドキュメントでは現在Wingetが推奨されていません。これはWingetがまだプレビュー段階であるためか、GitHubが依然としてその所有者であるMicrosoftからある程度独立して運営されていることを示しているのかもしれません。
ツール自体は、かなりの数のバグが報告されたにもかかわらず、私たちにとってはうまく機能しました。開発者にとってのメリットは、GitHubを使ってスクリプトを書けるだけでなく、GitHubのウェブサイトにアクセスする必要性が減ることです。例えば、望ましくない設計上の決定を避けることができます。®
ブートノート
ハブの開発者がこれについて実際にどう感じているかについては、実際のところわかりません...
