Zenn
🚀

個人的なGitの運用ルール

2023/10/26に公開
Git
GitHub
tech

はじめに

個人的な Git の運用ルールをまとめる。
個人ホームページ（ポートフォリオ）や小規模なサイトでの運用が前提。
※基本はチームの運用に基づく

ブランチモデル

代表的なもので「Git-flow」と「GitHub Flow」の 2 つがあるが、小規模で複雑な機能追加もないので「GitHub Flow」で運用。

例えば、機能追加やバグの修正があった場合は、

  1. main ブランチから作業ブランチを切り作業する。

  2. 作業が終わったらプルリクエストを作成

  3. コードレビュー

  4. main ブランチへマージする。

  5. ビルド&デプロイ

  6. リモートとローカルの作業ブランチを削除

※Git-flow と GitHub Flow の違いはこちら ▼
https://supersoftware.jp/tech/20221021/17928/

Issue を立てる

機能追加やバグ、UI 等の改善時は Issue を立てる。
Issue を立てると固有 ID が発行されるので、ブランチ名、コミットメッセージに固有 ID を含めて Issue と関連づけ、トラッキングしやすくする。

ブランチ名

基本は下記２つで運用して、難しい場合は適宜考える。（Issue 番号をいれて関連づける）

  • feature（新機能開発）

    例：feature/#8_add_menu

  • hotfix（バグ修正）

    例：hotfix/#21_fix_bug

コミットメッセージ

Prefix（接頭辞）をつける

コミットメッセージには Prefix をつける。
Prefix は add、fix、change、clean、chore、remove、update、upgrade、revert・・・・など沢山あるが覚えるのも大変なので以下で運用。（Emoji はつけない）

  • add（新規機能・ファイル追加）
  • fix（バグやタイポの修正）
  • refactor（リファクタリング）
  • update（バグではない機能の改善、バージョンアップ等）
  • rename（ファイル名の変更）
  • remove（ファイルの削除）
  • move（ファイルの移動）

理由を書く

変更した理由や目的を書いてレビューしやすくする。理由が書きにくいものもあるので、場合によっては書かなくても OK（基本は書く）

例：update: ◯◯ なため、△△ を追加する
例：add: 認証機能を実装する

Issue 番号を末尾につける

コミットメッセージの末尾に固有 ID を含めて Issue と関連づけておく。
例：update: ◯◯ なため、△△ を追加する #3

プルリクエスト

実施タスク（Issue 番号）、実施内容、レビューしてほしいこと、備考を入れる。
テンプレートを作成しておくと楽。

テンプレートの作成手順

  1. ルートディレクトリに.github フォルダを作成
  2. .github フォルダに PULL_REQUEST_TEMPLATE.md ファイルを作成
  3. 作成したファイルにテンプレートの内容を記述
/.github/PULL_REQUEST_TEMPLATE.md
## 実施タスク

例：issue #2

## 実施内容

- 例：ヘッダーの作成を行いました。
- 例：メインコンテンツの余白を調整しました。

## レビューしてほしいこと

- 例：デザイン通りに表示されること
- 例：PC・SP サイズで表示崩れがないこと
- 例：リンクの確認

## 備考

- 例：ハンバーガーメニュー開閉時のアニメーションについては、別 PR で実装します。
GitHubで編集を提案

Discussion