GitHubについて
Gitは単体で使うのではなく、リポジトリホスティングサービスと併用することで真価を発揮します。今回はそのうちの一つであるGitHubを紹介します。
GitHubには、Gitをチームで使うにあたって便利な機能が数多くあり、機能追加・改修も盛んに行われています。基本機能はリポジトリのトップページのタブでまとめられています。これらについてそれぞれ解説していきます。
事前準備
アカウント作成
実際に手元でタブをクリックしたりしながら確認するとわかりやすいので、必要に応じてGitHubのアカウントを作成してください。すでにGitHubを使ったことがある方は読み飛ばしていただいて構いません。
まずはGitHubのアカウントを作成するために、こちらからサインアップしてください。2要素認証の設定もしておくのがおすすめです。
アカウントが作成できたら、まずこちらのドキュメントに従って、SSHキーを登録してください。ローカルからリモートリポジトリであるGitHubに接続するために必要な設定です。
GitHubリポジトリの作成
アカウントが作成できたら、GitHubで新しいリポジトリを作成します。サインイン後のページで上図のようなタブがあるので、Repositories
を選択し、New
ボタンから新しいリポジトリを作成してください。リポジトリ名を適当に決めて作成ボタンを押します(ここではgit-tutorial
とします)。それ以外の項目は分からなければ一旦デフォルト設定のままでも大丈夫です。
すでにローカルにポジトリがある場合は、それを今作成したリモートリポジトリにpush
します。
# リモートリポジトリ登録してない人はもう一度こちら(例) $ git remote add origin git@github.com:アカウント名/git-tutorial.git # リモートリポジトリにmainブランチをpush $ git push origin main
ローカルリポジトリがない人は、逆にリモートリポジトリのものをclone
してくることでローカルと同期できます。
$ git clone git@github.com:アカウント名/git-tutorial.git $ cd git-tutorial # ローカルで適当にコミットを積んで、リモートリポジトリにpushしてみてください $ git push origin main
GitHubでリポジトリができたら、実際にいろいろと機能を触ってみてください。
ここからは主な機能を説明していきます。
Code
こちらはリポジトリのトップページにあたり、push
されているコードを閲覧できるタブです。ブランチを切り替え、特定のコミットハッシュにチェックアウトして、ブラウザ上で確認することができます。
また、README.md
というファイル名でMarkdown形式のファイルをリポジトリのルートに置いておくと、そちらを表示してくれる機能もあります。リポジトリを訪れた人に最初に説明しておきたい事柄などを書いておくと良いです。
他にも、被スター数、被fork数、リリース履歴、パッケージングに関する履歴など、さまざまな情報を見ることができます。
Issues
こちらはリポジトリに関して気になったことを何でも、Markdown形式で書いておくところです。Issuesタブをクリックし、New issue
ボタンを押すと、以下の画面に遷移して書き込めます。
実際は、開発チームによって使われ方はさまざまですが、リポジトリに関する質問や相談、議論の土台のために作成したり、タスクを記載して、後述するProjects機能と併用してタスク管理に使われたりなどの運用があります。issueに用意されている主な機能を以下にまとめます。
- issueについてコメントを書き込める
- マイルストーンをつけて、いつまでに対応すべきか明確にできる
- ラベルをつけて、種類別に管理できる
- Pull requestsに紐づけることができる
- issueを誰かにAssignできる
Pull requests
Pull requestsは、GitHubの機能の中でも重要な機能です。この機能のおかげで、独立並行したチーム開発を円滑に進めることができます。
Pull requestsは、作業ブランチを分岐元のブランチにマージする際に作成し、コードのレビューや議論をするために使われます。OSSでは、fork元のリポジトリにマージをお願いするときにも使われます(元々はこちらの背景で、fork元のリポジトリにお願いする機能なので、"Pull Requests"と呼ばれています)。
レビューする側は、取り込む差分をよく吟味し、大丈夫そうならmerge
して差分を取り込みます。問題点があればそれを指摘して修正してもらうようにします。実際のPull requestsの画面は以下です。
Files changedタブをクリックすることで、このPRの差分を確認することができます。
コメントや差分を見て、レビューを行っていきます。
Pull requests(PR)を出す側の注意点
すでにfeatureブランチや、トランクベース開発の解説でも述べた通り、PRはできるだけ細かい単位で出すように心がけるのが大事です。
理由としては、すでに上記で解説したように「差分が大きくなるとコンフリクトが発生しやすくなるため」という点もありますが、他にもレビュワーの立場に立って考える必要があります。例えば、巨大なPRを確認することは大変なので、後回しにされがちになり、バグも混入しやすくなってしまうと思います。コードのみで説明も不十分だと、思わぬ見落とし(レビュー漏れ)もあるかもしれません。
このように、PRでの確認はあくまで人間同士のやりとりになるので、正確性や効率を上げるために、小さく、分かりやすいPRを作ることを心がけてください。
Pull requests(PR)を見る側の注意点
コードレビューの仕組みがあるとはいえ、マージされるコードについて人間が全てを確認し、全ての責任を負うのは、特に大規模開発の場面では非現実的です。
ここで大事なのは、機械的にチェックできる部分は 自動テスト・CI などの仕組みに任せ、人間がチェックする部分をできるだけ限定的にすることです。例えば、仕様、設計面や、セキュリティ・法的な観点などは、人間が目でチェックしなければならない部分です。逆にソフトウェアのバグは人間の目ではなかなか見つからないものです。
その他、問題点があった場合の指摘の仕方にも注意が必要です。単に「このコードは良くない」という指摘ではなく、理由や修正例を書いてあげると議論もしやすくなります。Team Geekで語られているHRTの原則「謙虚(Humility)、尊敬(Respect)、信頼(Trust)」を心がけましょう!
※なお、より発展的には、コード品質を定量化する指標(LCOMなど)もあったりするので、そういった指標を組み合わせるとより良いレビューができると思います。
Actions
ActionsはGitHubが提供しているソフトウェア開発ワークフローの自動化プラットフォームで、CI/CD環境として広く利用されています。
GitHubにおけるActions登場以前のCI/CDは、GitHubリポジトリをJenkinsやCircleCIなど他のツールやサービスと連携させて行うしかありませんでしたが、Actions登場後はGitHub内だけで完結できるようになりました。Actionsはパブリックリポジトリであれば無料で利用できます。ワークフローの処理は、自分で書くこともできますし、汎用的な処理は GitHub やサードパーティが公開しているActionを利用することもできます。公開Actionが多いことも利点の一つです。
Actionsを使いたい場合は、hookしたいイベントとワークフローを書いた yamlファイル をリポジトリの.github/workflows/
に配置すると、自動的に起動してくれるようになります。例えば、単体テスト、Dockerイメージのビルドやプッシュ、サービスのデプロイなどをワークフローの中で行います。具体的な書き方は公式ドキュメントを読んでください。
Projects
カンバンスタイルのタスク管理ツールです。issueやPRを付箋のように扱い、タブを移動させて進捗状況を可視化できます。
カンバンは、アジャイル・スクラム開発でよく使われるタスク管理の方法です。GitHubでタスク管理までできるとなると便利ですよね。
あくまで現状では、velocityやburndown chartのような開発速度のトラッキング機能がないなど、他のタスク管理特化のツールに比べたら劣る部分もありますが、GitHub自体どんどん便利になっているので、Projectsに関しても今後の機能追加に期待したいところです。
Wiki
GitHubリポジトリごとに用意された、いわゆる Wiki そのものです。チームメンバーが自由に記事を追加・編集・削除するために使われます。ドキュメントツールとして運用することもできます。ただし、機能はそこまで充実しているわけではないので、あくまで利用場面は限定されると思います。
特に最近では、GitHub Pagesという機能もリリースされたので、ドキュメントを書く際はそちらを使うことが多くなっていると思います。
Security
主に以下の3つの機能があります。
-
Security Policy
- 脆弱性報告の手順を記しておくための場所
-
Security Advisories
- 脆弱性対応用に使われる非公開issueのようなもの
- 対応パッチがリリースされると、その議論を公開状態にできる
-
Dependabot
- コードから依存パッケージのバージョンを解析し、脆弱性がある場合にアラートを通知してくれる
Dependabotは基本的に設定しておくことがおすすめです。Dependabot以外は基本的にはOSSで使われる機能になると思います。
Insights
Insightsはリポジトリの活発度など、さまざまな指標を確認するための機能です。コミット数や差分の量などがグラフ化されています。
自分のリポジトリであまり活用できるシーンは少ないかもしれませんが、OSSから新しいライブラリやツールの導入を検討している際などは、このタブを見れば、どれくらいメンテナンスされているのかを把握することもできるので、ぜひ活用して見てください。
Settings
リポジトリに関するさまざまな設定をするための場所です。よく使われるものを例として挙げておきます。
- デフォルトブランチの変更
-
リポジトリ公開範囲の設定
- OSS化しない場合は基本privateにしておくのが安全です
- privateからpublicへ変更する際は注意してください
-
Branch protection rules
- branchごとに、PRを経ない直接のpushやforce pushを禁止して保護できます
-
Secretsの登録
- 主にActionsで使う秘密鍵などをここで登録したりします
- Pagesの設定
- リポジトリの削除
まとめ
本記事では、GitやGitHubを使ったチーム開発の方法について解説しました。第1回、第2回の内容を読んだ方は、実際の開発でGitを使っていくイメージを持っていただけたら幸いです。実践することでより理解が深まる点もあると思うので、ぜひ使ってみてください!
次回は発展的な内容になりますが、Gitの内部構造について解説します。Gitを使ったことがあっても、内部実装を知らない方は少なくありません。よりGitに詳しくなりたい方、Gitの自作に興味がある方は第3回の記事を楽しみにお待ちください!
※各ブランチモデル図はこちらより引用。