- 違う理由の変更を持つ複数のファイルをひとつコミットに入れない。
- 同じ理由の変更なら複数のファイルをひとつコミットに入れても問題ない。
- 変更点を説明するコミットメッセージが、コミット全体に対して適切であるか？ が目安。
- ファイナル数が問題ではなくて、変更内容とその動機や事情が問題。
- Hunkの操作もできる。Hunk単位のコミットもあり。
- バイナリファイルは扱わない（今回は）。
- 今回は、（ホスティングサービスの）イシュー管理、タスク管理は使わない。
- 抽象的・一般的な文言のコミットメッセージは書かない。具体的に、必要十分に書く。
- 適宜タグを付ける。一時的マーカーなら軽量タグでよい。
コミットメッセージは次に従う。
- https://www.conventionalcommits.org/ja/v1.0.0/
- https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional
Conventional Commits は Structured Commit Messages が妥当な名前。小さな構造化構文でメッセージ〈コメント〉を書く。コミットに型（つうかロール）を導入する。次の型を使う。
- feat: new feature
- fix: bug fix
- refactor: refactoring
- build: build scrit/system
- docs: documents
- test: test code/data/system
上記の仕様にはないが、
- exp: experiment : 実験のためのコード／データ
- desig: visual design ： HTML、CSS、画像の生成・変更は
とか。
型〈ロール〉を持つコミットには、メッセージ接頭辞で型を指定する。型と共に、ソフトウェア／システムのどの部分／どの範囲を修正したかでスコープを付けることができる。
- 例： feat(api): ???
- 例： refactor(ui): ???
手順：
- mainから作業ブランチを作成。
- コードを修正し、コミットする。
- 何らかのミスで動かなくなった場合は、そのファイルをリセットしてコミット前に差し戻す。
- 既にコミットしている場合など最悪の場合、ブランチを破棄して1からやり直せる。
- ひと通り修正して各ファイルのコミットが終了し、そこで問題がなければ作業ブランチをmainにマージする。
- 作業ブランチを削除する。 マージが終わったら作業ブランチは消す。
- 以上の繰り返し。
