🧭

個人開発用Git運用ルールを考えてみた

に公開
Git
GitHub
個人開発
ポートフォリオ
idea

はじめに

個人開発のWebアプリをポートフォリオとして公開するにあたり、個人開発用のGit運用ルールを決めることにしました。

今回は自分の個人開発用に作成したGit運用ルールをまとめます。

なぜGit運用ルールを決めたか？

今までGitの運用ルールが明確に決まっている案件に参画する機会があまりなく、個人開発でも特にルールを決めずに開発してきました。

ですがポートフォリオとしてリポジトリを公開するとなるとブランチやコミット履歴も見られるので、他人が見てもわかりやすく、自分も管理しやすい運用ルールが必要ではないかと感じたことがきっかけです。

運用ルール

以下、具体的にどのような運用ルールにしたのかをまとめました。

ブランチ

ブランチは以下のような構成にします。

  • main: 公開用ブランチとして常に動作する状態を保つ
  • feature/*: 機能追加用にブランチを切る
    • 例: feature/login-page
  • fix/*: バグ修正用のブランチ
    • 例: fix/api-endpoint
  • docs/*: ドキュメント修正用のブランチ
    • 例: docs/update-readme

GitHub が提唱している運用ルールである GitHub Flow を参考にしました。

他にも Vincent Driessen が提唱した Git Flow という運用ルールもありますが、こちらは長期運用の大規模プロジェクトで使われることが多いようです。

コミットメッセージ

コミットメッセージは Conventional Commits に従い、英語で書きます。

メッセージフォーマット

<type>: <短い説明>

type 一覧

  • feat : 新機能追加
  • fix : バグ修正
  • docs : ドキュメントのみの変更
  • style : フォーマット修正（動作に影響なし）
  • refactor : リファクタリング
  • chore : 設定や依存関係の変更

例

  • feat: add weather API integration
  • fix: correct date formatting issue
  • docs: add system architecture diagram to README
  • style: apply prettier formatting
  • refactor: extract API call into separate module
  • chore: update dependencies

コミットタイミング

以下のタイミングでコミットします。

初回コミット：
「最初のフォルダ構成」や「依存関係（package.json など）」ができた段階で git init & 最初のコミット

2回目のコミット：
ある程度アプリが形になった段階で2回目回のコミット

それ以降：
機能単位やタスク単位で都度コミット

初回コミットから2回目のコミットまで間が空きそうですが、序盤は仕様や構成などを試行錯誤しながら進めることが多く、それらの履歴がたくさん残っていると開発過程がわかりにくいと思い、このような形にしました。

まとめ

個人開発用リポジトリでは以下の方針で運用することにしました。

  • ブランチ運用は GitHub Flow ベース
  • コミットメッセージは Conventional Commits + 英語
  • コミットタイミングは以下の通り
    • 初回コミット：環境構築ができた段階
    • 2回目：ある程度形になった段階
    • それ以降：タスク単位で都度コミット

まずは今後このルールで運用してみて、適宜ルールを追加・変更していこうと思います。

おすすめの運用ルールがあればぜひ教えてください。

Discussion