この記事ではGitHubの新しいリポジトリの作り方を初心者に向けて軽く解説します。

前提

GitHubを使い始める前に上記の知識・設定を行っておくと良いです。

Gitシリーズ記事まとめ

Git とは

小規模から大規模開発まで、あらゆるプロジェクトで利用される無料のオープンソース分散バージョン管理システムです。

GitHub とは

Git(ソースコード)をホスティングしてくれるサービスです。
複数人の開発者と協働してコードをレビューしたり、課題管理しながら開発できます。

GitHubの主な機能

いくつかのタブメニューなどご紹介していきます。

プルリクエスト(Pull Request)

元のブランチから新しくブランチを作り、差分を反映(マージ)したい場合にプルリクエストを作成できます。
プルリクエストでは、変更されたコードに対してレビュー(ディスカッション)が行えます。

レビューする人のことを「レビュアー(reviewer)」
レビューしてもらう人のことを「レビューイ(reviewee)」と呼びます。

レビュアーはプルリクエストに対して3種類のアクションが行えます。

Approve(承認する)
Request changes(否認する)
Comment(承認も否認もしない。質問やディスカッションのコメント)

Approveされたらプルリクエストをマージできます。

https://docs.github.com/ja/github/collaborating-with-issues-and-pull-requests/about-pull-requests

イシュー(Issue)

GitHubでは新機能やタスク、バグ等の管理にIssueを使って課題管理できます。
ラベルを用いて、カテゴライズできたり、担当者をアサインできたりとGitHubだけでも優秀な課題機能があります。

#1 などIssueやPullRequestの番号やコミットのハッシュ値を入力して簡単に紐付けできます。
また、プロジェクトボードというカンバン機能もあります。

Issue, PullRequestテンプレート

Issue, Pull Requestのテンプレート機能があります。

.github/ISSUE_TEMPLATE.md - Issueを作成するときのテンプレート
.github/PULL_REQUEST_TEMPLATE.md - PullRequestを作成するときのテンプレート

と配置するだけです。

ブランチ保護(Protected Branches)

GitHubは直接コミット禁止によるブランチの保護機能が提供されています。
Pull Requestを介して、レビューや自動テストによるチェックが通過しないとマージできないといった制約を付けてブランチを保護できます。

https://docs.github.com/ja/github/administering-a-repository/about-protected-branches

GitHub Actions(ワークフロー)

GitHub ActionsとはGitHubが提供するCI/CD(継続的インテグレーション/継続的デリバリー)サービスです。

.github/workflows/*.yml ワークフローはYAMLで定義します。

私のリポジトリではこんな感じで使ってるので雰囲気だけ知ってもらえればと思います。

GitHub Actionsについては公開リポジトリであれば無料で利用できます。
非公開リポジトリは無料枠＋従量課金となります。

無料プランでも2000分/月利用できるので小規模な開発であれば問題ないでしょう。
プロジェクトによってCI/CDする内容が大きく変わるので深くは説明しません...(できません)

fork(フォーク)

forkとは、他の人のリポジトリを自分のリポジトリへコピーすることです。
リポジトリをフォークすることにより、オリジナルのリポジトリに影響を与えることなく自由に変更できます。
また、変更した内容をオリジナルのリポジトリへプルリクエスト(提案)して貢献できます。

リポジトリをフォークする

Wiki(ウィキ)

WikiはWikiです。
プロジェクトに関するドキュメントなどをまとめるところです。

GitHubリポジトリの作り方

本題です。

新規リポジトリの作成

Repository template: テンプレートリポジトリを選択できます。
Owner: リポジトリ所有者を選択できます。
Repository name: リポジトリの名称です。優れたリポジトリ名は短く覚えやすいものです。良い名前を付けましょう。GitHubがランダムなリポジトリ名を考えてくれます(笑)
Description: リポジトリの概要です(任意)
Public/Private: リポジトリの公開/非公開設定です。この設定をミスるとこうなります
Initialize this repository with: 予めGitHubがテンプレファイルを用意してくれます。(任意)

ちなみにリポジトリの名前はあとからでも変更できます。

Gitのセットアップ

リポジトリの新規作成ページでREADMEやLICENCEの選択などを行った場合は不要です。

こんな感じにGitHubにファイルがpushされていればセットアップ完了です。

設定ファイル

.gitignore
- https://www.toptal.com/developers/gitignore
.editorconfig
- https://editorconfig.org
README.md
- プロジェクト、ツールの使い方、インストール方法などをまとめておく
- わかりやすいREADME.mdを書く
SECURITY.md
- セキュリティポリシーについて

コラボレータの追加

コラボレータ(Collaborator)とはリポジトリのコアな開発者です。
リポジトリに対して、pushやmergeといった権限が与えられます。

非公開リポジトリの場合はコラボレータに追加されないとリポジトリの参照も行えません。

また、公開リポジトリではあればコントリビューター(Contributor)として外部から貢献できます。
直接pushやmergeはできないので、リポジトリをforkしてPull Requestを送るといった手順を踏む必要があります。

Settings > Manage access > Invite a collaborator

招待メールが送られるので、相手が招待リンクを承認したらコラボレータへ追加されます。

リポジトリオプション設定

Settings > Options > Settings

リポジトリ名の変更が行えます。
テンプレートリポジトリの設定ができます。
SNS等でリポジトリのリンクを共有した際の画像を設定できます。
(未設定の場合はリポジトリオーナーのアイコン画像になります)

GitHubのTemplate Repository機能のすゝめ

Settings > Options > Features

GitHubの機能の有効化/無効化が行えます。
IssueやWikiなど外部のツールを使う場合は無効化しておくと良いでしょう。

Wikis
Restrict editing to collaborators only
Issues
Sponsorships
Projects
Preserve this repository
Discussions

Settings > Options > Merge button

プルリクエストをマージする場合、マージコミット、スカッシュ、リベースの任意の組み合わせでマージできます。

いずれか一つのボタンのみを有効化させておくと混乱しないので良いです。
(プロジェクト内で相談して決めてください)

Allow merge commits (デフォルト)
- マージコミットが作成されます。
Allow squash merging
- そのプルリクエストのコミットは１つのコミットにsquashされます。
Allow rebase merging
- トピックブランチのすべてのコミットが、マージコミットなしに個別にベースブランチに追加されます。

個人的には Allow squash merging が好きです。

GitHub上のマージ方法について

自動マージを許可する設定です。
必要なレビューとステータスチェックに合格するとプルリクエストを自動的にマージする設定です。
有効化しておくと良いです。

プルリクエストがマージされた後、リモートリポジトリのブランチが自動的に削除されます。
マージ済みのブランチを残しておく必要はないので有効化しておきましょう。
(削除したブランチもあとから復元できます)

Settings > Branches > Branch protection rules

ブランチの保護ルールの設定をします。
保護ルールをどのくらい強めに設定するかはプロジェクト内で相談して決めてください。

Branch name parttern: ブランチ名を指定します。(パターンマッチも利用可能)

https://docs.github.com/en/github/administering-a-repository/managing-a-branch-protection-rule

Require pull request reviews before merging: マージする前にプルリクエストのレビューを要求します。
必要な数の承認レビューがないとマージできなくなります。
Dismiss stale pull request approvals when new commits are pushed: 新しいコミットが追加されるとレビュー承認は却下されます。
Require review from Code Owners: オーナーの承認が必ず必要になります。

これ全部チェックすると相当マージするハードルが高くなります。
開発速度にも影響出るので、最低レビュー1個必要と設定すればとりあえず良いでしょう。
必要に応じてレベルをあげてください。

Require status checks to pass before merging

Require status checks to pass before merging: マージする前にステータスチェックに合格する必要があります。
CIが通ってないのにマージされるとブランチを保護する意味がなくなるので、必ず有効化しましょう。

Require branches to be up to date before merging

Require branches to be up to date before merging: マージする前にブランチを最新にする必要があります。
この設定を行うことで最新のコードでテストされていることが保証されます。必ず有効化しましょう。

開発速度の速いリポジトリだと他のPRがマージされる度にマージが必要になるので、ケースバイケースかもです。

Require signed commits: 署名付きコミットが必要

署名済みコミットを必須にする設定
署名がないとマージすることができなくなります。(いるかな？)

コミットに署名する

Require linear history: 線形履歴が必要

マージボタンの設定で Allow merge commits 以外のAllow squash mergingやAllow rebase mergingを採用する場合は有効化しましょう。

Include administrators: 管理者を含める

管理者もこのブランチ保護の制限の対象に含めるか
チェックを入れると管理者も同様にマージできなくなります。
通常は有効化して、緊急時のみ無効化する感じがいいかも？

Allow force pushes: 強制プッシュを許可する。(絶対に有効化しないでください)
Allow deletions: ブランチ削除を許可する。(絶対に有効化しないでください)

管理者を含むすべての人に適用されるルールです。
これを設定してしまうとブランチを保護する意味がなくなるので必ず無効化しましょう。

Settings > Secrets > Actions secrets

シークレットキーの設定です。
アクセスキーやシークレットキー、APIキー等、コミットに含めたくないものを登録します。
GitHub Actions等でデプロイする際にシークレットで登録したキーを参照する時に使います。

さいごに

GitHubのリポジトリを作成する際の最低限の内容をまとめました。
より詳しく知りたい方は公式ドキュメントを参照してください。

https://docs.github.com/ja