Gitリポジトリ運用規約 - 変愚蛮怒 Wiki - 変愚蛮怒

Gitリポジトリ運用規約

コミット規約

コミット時メッセージについて

• コミットの際は以下のヘッダ最低1つを付ける
  • 大文字小文字はこれまでも混同してしまっているので問わない検索の際もそのつもりで行ってくれて構わない
  • 種別として曖昧であったり双方を兼ねるようなコミットがある場合は複数ABと配置してもらって構わない
  • 各Gitクライアントのマージ処理などにより自動で生成されたものはそのまま利用してもらって構わない
  • 種別としては以下の通り
    • [Add] ... 新しい要素、取り分けてファイルやフォルダの追加がある場合に加える。
    • [Refactor] ... リファクタリング、既存のソースコードを同じ機能を維持したまま整理したもの。
    • [Fix] ... バグ修正、本来求められていた仕様と実際とが異なる場合の食い違い
    • [Implement] ... 新規機能の実装
    • [Feature] ... 既存仕様の変更
    • [Version] ... 新しいバージョンの節目としての更新
    • [MISC] ... その他、あまり推奨できないがどれともつかないもの、些細に過ぎるものについてはこれでもよい。その代わりコミット文章で詳細は述べること。
• コミットには原則 #XXXXX とOSDNの対応するチケットを一つ定めること。
  • あまりにも些細すぎてどうしようもないものについては（特に前述の[MISC]級のもの）は一応許可。ただし理由等はコミット文章で明確に述べること。
• コミット本文は一行目で簡潔な用途と定めた上、2行目を空行として1行開け、3行目以降で可能限り詳細な内容を述べるべきである。
  • 特に[Fix]系統については煩雑な処理の流れの結果要する修正に対し、修正内容が1か所のみなど、意味する所が大きすぎるのでなおさら文章で補完したい https://osdn.net/projects/hengband/scm/git/hengband/commits/087d845fd24e3e3d3e37ecf58c39a9a302e226dd などを参考に。

ブランチ作成規約(仮作成中)

• 本筋は無論masterであり、原則一切の成果は最終的にmasterへマージされる。
• 新しいバージョン開発を行うごとに"develop"ブランチ(/以降の記述なし)を作成し、正式なリリースが行われるごとに"master"へのマージを行い、システム上のバージョン表記更新、及びタグ付加をmasterで行う。
• 各チケット案件は"develop"からさらに派生するブランチをもって行う。フォーマットは[add/fix/feature/refactorの等種別]/[分かりやすい目的の簡略名]とする。
• Habuさんより https://qiita.com/y-okudera/items/0b57830d2f56d1d51692 を参考に方針見直す提案があったのでさらに組みなおし予定。
  • 上記リンク先のCase3: master&develop&featureブランチにならった方針で行く予定。
  • masterを最新にmergeする時に -no-ff フラグを付けること。