はじめに
GitHubは、多くの開発者やプロジェクトチームにとって欠かせないツールです。
ですが、私自身、過去のrepoを見返してみると煩雑で汚いものが数多くあります。
今回の記事では、綺麗なリポジトリを運用するための方法をいくつかまとめてみましたので、是非参考にしてみてください。
リポジトリの構造を整理する
フォルダ構造の最適化
プロジェクトのフォルダ構造は、直感的でわかりやすいものにしましょう。
例えば、こんな感じ。
/fugahoge-project
├── src
├── docs
├── tests
├── scripts
├── .git
├── README.md
└── .gitignore
特に、Vueなどではコンポーネントが肥大化していくので、ロジックをうまく分割してあげると保守性の向上に繋がります。
不要ファイルの除去
不要なファイルやディレクトリは、.gitignoreを使ってリポジトリから除外します。
これにより、リポジトリが邪魔なもののない整理された状態を保つことができます。
テスト用の.envとかそういうのですね。
READMEの充実化
プロジェクトの概要を記載
READMEには、プロジェクトの目的や概要を明確に記載します。
新しいユーザーや開発者がプロジェクトを理解しやすくなります。
しかし、ここにあまり詳細に書きすぎるのもよくないので、概要と目次別にDocsへのリンクだけを乗せるくらいがちょうどいいのではないでしょうか。
インストール方法と使用方法
具体的なインストール手順や使用方法を記載することで、他の開発者が簡単にプロジェクトを利用できるようになります。
貢献方法
プロジェクトに貢献する方法やルールを明示しましょう。
個人開発の場合、コントリビューターが増えるとしあわせになれるかもしれません。
GitHubの場合、以下のページに詳細な定義方法が記載されています。
IssueとPull Requestの管理
テンプレートの使用
IssueやPull Requestのテンプレートを設定することで、情報が整理され、やり取りがスムーズになります。
テンプレートには、必要な情報を漏れなく記載できるようにしましょう。
ラベルの活用
IssueやPull Requestにはラベルを付けて管理します。
バグ、機能追加、質問など、種類ごとにラベルを設定しておくと、管理が楽になります。
(私はこれをあまり使えていません)
ブランチの運用
ブランチモデルの採用
GitFlowやGitHub Flowなどのブランチモデルを採用することで、開発フローが整理され、作業が効率化されます。
しかし、例外として少人数での小規模な開発であれば、ルールでガチガチに縛り付けるよりもある程度の定義だけをやっておいて柔軟な運用をしたほうがいいかと思います。
ブランチの命名規則
ブランチ名には、作業内容がわかるような命名規則を設けましょう。
例えば、feat/[機能名]やfix/[修正内容]みたいな感じ。
コミットメッセージのルール化
一貫したフォーマット
コミットメッセージには一貫したフォーマットを採用します。
例えばこんな感じ
prefix: 説明
prefix
コミットメッセージの先頭につけるprefixをいくつか用意しておきます。
例えば、feat(新機能)、fix(バグ修正)、docs(ドキュメント)、refactor(リファクタリング)などです。
私は、僕が考える最強のコミットメッセージの書き方を参考にしています。
分かりやすいので是非参考にしてみてください。
自動化ツールの導入
GitHub Actionsの活用
GitHub Actionsを使って、CI/CDパイプラインを構築しましょう。
自動テストやデプロイを設定することで、作業の自動化が進みもれなくしあわせになれます。
これ一つでDockerイメージのビルドからコンテナレジストラへの登録まで全部完結するので便利です。
Dependabotの設定
Dependabotを設定することで、依存関係の更新を自動で行い、セキュリティリスクを軽減します。
取り敢えず使っておきましょう。
おわりに
この記事ではリポジトリの運用術について書いてきましたが、実際に綺麗で完璧な状態のまま運用するのにはなかなか厳しいものがあります。
ですが、これまで紹介したいろいろを使うと、リポジトリを心做しかちょっとだけ綺麗に運用することができます。
リポジトリが整理されていると、作業効率が上がり、しあわせになれるでしょう。
是非、使ってみてください。
それでは。