開発ルール（Git） - tamkiti132/Basta GitHub Wiki

【ブランチの運用方法】

GitHub Flow

6つのルール

GitHub Flowには以下の6つのルールがあります。【ルール1】が最も重要で、それ以外のルールは【ルール1】を実現するために存在します。

【ルール1】mainブランチは常にデプロイ可能である
【ルール2】作業用ブランチをmainから作成する
【ルール3】作業用ブランチを定期的にプッシュする
【ルール4】プルリクエストを活用する
【ルール5】プルリクエストが承認されたらmainへマージする
【ルール6】mainへのマージが完了したら直ちにデプロイを行う

開発フロー

【手順1】mainブランチから作業用ブランチに切り替える
【手順2】切り替えたブランチで作業を行う
【手順3】作業内容をadd→commitする
【手順4】ローカルでcommitした作業内容をリモートにpushする
【手順5】プルリクエストを作成する
【手順6】プルリクエストをレビューする
【手順7】修正がある場合はローカルで修正し、変更内容をリモートに反映する
【手順8】作業完了後、リモート上のブランチをmainにmergeし、作業ブランチを破棄する
【手順9】ローカルのmainブランチをリモートの最新と一致させる。
【手順10】デプロイする

参考
https://qiita.com/satohiro/items/7d5abde24222e6026d3d

https://atmarkit.itmedia.co.jp/ait/articles/1708/01/news015.html#02


【ブランチ名の命名規約】

<型>/<概要>

例) fix/tab-switch-not-working-in-mypage

型：

概要：

  • 単語をハイフンで繋げる
  • 必要に応じて、対象のファイルやページ名を含める

【コミットメッセージの規約】

Conventional Commitsを元にカスタマイズしたもの

今回のプロジェクトでは、Conventional Commitsの主な特徴のうち、
・破壊的変更であることを示す ! や BREAKING CHANGE
・スコープ
・フッター
は利用しなかったため、これらに関しては詳しく言及していません。

フォーマット

<型>(任意 スコープ): <タイトル>
（空行）
[任意 本文]
（空行）
[任意 フッター]

簡単な例)

fix: メモ作成時の文字数制限エラーを修正

多くの要素を使った例)

feat(auth): ユーザーログイン時の認証方式を変更

従来のセッション認証では複数デバイス対応が困難なため、
JWT認証に変更してモバイルアプリとの連携を可能にする。
この変更により、ユーザーは複数デバイスで同時ログインできるようになる。

BREAKING CHANGE: 既存のセッション認証が無効になるため、
全ユーザーの再ログインが必要。また、従来のauth middlewareは
JWTMiddlewareに変更する必要がある。

型：

型 説明 例
feat 新しい機能を追加した場合 新機能、クラス、関数、変数、UI、APIエンドポイントなどの追加
fix バグを修正した場合 -
build ビルドシステムまたは外部依存関係、ライブラリに影響する変更 gulp、composer、npmなどに関する操作
ci CI / CD Travis、Circle、GitHub Actions
docs ドキュメントのみの追加・修正 READMEを更新
chore 雑事（カテゴライズできないもの） 画面上に表示されるテキストを変更
style コードの意味に影響を与えない変更 空白、インデント、フォーマット、セミコロンの欠落などの修正
refactor リファクタリング
『リファクタリング　既存のコードを安全に改善する（第二版）』の、【リファクタリングリスト】に載っているもの、またはそのうち、意味を拡張しても問題ないと判断したもの		 ・実際に使用しているコードの再設計（ファイル名や変数名を適切にするなども）
・不要・未使用のファイル、コード、コメントの削除
perf パフォーマンスを向上させるコード変更 クエリの最適化
revert コミット取り消し（git revert） -
test テストの追加や修正 -

ポイント：

  • テストのみの追加・修正は『test』に分類。
  • 機能の追加・修正の際はそれに関するテストをコミットに含める。

任意：

  • 記述しなくてもいい部分

タイトル：

  • 命令形・現在形の動詞から始める
  • 50文字以内

    Githubでは以下の仕様となっている。

    • 50文字を超える場合：警告が表示される
    • 72文字を超える場合：72文字に切り捨てられる よって、できれば50文字、少なくとも72文字に収める。

スコープ：

  • 型 には追加のコンテキスト情報を表すスコープを含むことが出来る。
    スコープ は型の後に括弧付きで表し、lowerCaseで表記する。

本文：

  • タイトルに加え、詳細情報が必要な場合、ここに書く
  • 方法よりも目的を書く

    まずはコミットの目的を明らかにする。そして以下の３点を意識することが大切。

    • 変更前の動作
    • 変更後の動作
    • なぜその方法で解決しようとしたのか

    方法はコードを見れば自明だし、必要があればソースにコメントを書くことで補足する。 コミットメッセージにおいては、HowよりもWhatやWhyが大切。

フッター：

  • Breaking Changes についての情報や、このコミットがクローズしたGitHubの課題を参照する場所でもある。
  • Breaking Changes は、最初に BREAKING CHANGE: という単語で始まり、スペースか改行で始まる。
    破壊的な変更は全て footer の BREAKING CHANGE ブロックとして記載しなければならない。
    BREAKING CHANGE ブロックには、変更の説明、変更理由、移行の注意事項などを記載する。

参考
https://github.com/conventional-commits/conventionalcommits.org/blob/master/content/v1.0.0/index.ja.md

https://gist.github.com/minop1205/5fc4f6ef0ec89fb1738833ba25ae00a0

https://qiita.com/mi2__user/items/21b29928d7d206387c85

https://qiita.com/siida36/items/ed3103e27e0f6ac531f2


【PRのdescriptionの規約】

## やったこと

* このプルリクで何をしたのか？

## やらないこと

* このプルリクでやらないことは何か？（あれば。無いなら「無し」でOK）（やらない場合は、いつやるのかを明記する。）

## できるようになること（ユーザ目線）

* 何ができるようになるのか？（あれば。無いなら「無し」でOK）

## できなくなること（ユーザ目線）

* 何ができなくなるのか？（あれば。無いなら「無し」でOK）

## 動作確認

* どのような動作確認を行ったのか？　結果はどうか？

## その他

* レビュワーへの参考情報（実装上の懸念点や注意点などあれば記載）

参考
https://dev.classmethod.jp/articles/pull-request-template/

⚠️ **GitHub.com Fallback** ⚠️