歴史を美しく保つBest practices

commitの粒度

• commitは独立で意味のある大きさにする

• ただし、開発中はこまめにcommitし、後で整理するのが安全

• x: "add test" → "fix test" → "implement method" → "fix typo" → "add doc" → "move module"

  • 前のコミットのfixはfixupする
  • 最低モジュール単位でsquashがよい

• x: "Release of TheHugeProduct"

  • commitから情報が失われ、特にgit blameの情報量・・

• o: "Add foo library" → "Rename module to hoge" → "Add wonderful feature"

  • リファクタの差分と、機能追加の差分は必ず分ける
    • 特にファイル移動は分ける(ファイル名変更追跡機能)
    • 機能追加差分そのものをrefactorした場合はsquashでも
  • ライブラリの追加や変更は分ける
    • コミットの意味が大きくなる
    • 残りの差分が不要になった時にcherry-pickできる
  • 細かい話はポリシーや文化による

※github上でのレビュー修正があまりに多い場合はpull-reqをやり直すのも

commit message

• 1行目はタイトル、なるべくコードを見ずに意味や参照がわかるように書く
  • x: fix
  • o: fix NullPointerException on FeedDetailActivity start
• (2行名は空行、これは仕様)
• 3行目以降は説明欄、コードを見ても現れない情報を書く
  • x: Check if intent.getExtra() is null to keep from NPE
  • o: MixiFeedDetailActivity is also intended to be launched without feed entity, caused NPE.
• (最低でもタイトルは) 英語で書きましょう！
  • 文字コードの混在や検索bilityの観点から