Gitリポジトリ統合と分離を経て、Fix #[0-9]+ の意味は失われた

コミットメッセージ、書いてますか？

私のところは2度ほど、コミットメッセージの Fix #[0-9]+ の意味を失いました。
そして再びの喪失を迎えんとしています。

どういうことか。
リポジトリがホスティングサービス上の居場所を失ったのです。

コミットグラフに積み上げられた Fix #[0-9]+は存在しないリソースの場所を示し、かつて開発の原動力であった情報資源を失いました。不具合の記録・機能開発に至った課題の熱量・調査の記録。 Fix #[0-9]+と簡素に示された解決のマークは、何を解決したかすらわからないただの文字列と化してしまいました。

コミットメッセージ、がっつり書いてますか？

くどいですね。まぁざっくり以下な感じです。

意味の喪失とは

コミットメッセージの Fix #[0-9]+ が指し示す issue だか pull request だかが、ホスティングサービス上の存在しない番号を示している。ないしは、コミットの内容とは全く関係のない番号を示している。

意味を喪失するとき

• Git ホスティングサービスを変更したとき
  • たとえば、BitBucketからGitHubへ引っ越ししたときに（特に解決済みの）issue, pull requestを移行しなかったことで、情報を失った
• リポジトリを統合したとき
• リポジトリを分離したとき

意味の喪失にどう抗うか

基本的には、コミットメッセージに Fix #[0-9]+ を書かないことに終止する。

• Fix #[0-9]+ で隠蔽されるものを書ききる
  • 不具合の内容・調査の結果等々
  • コミットがissueに書かれた内容のうち何を解決するのかを書く
• Fix #[0-9]+ を書くのは、Pull Request のコメントでのみとする（主にGitHubでの話）
  • Pull Requestマージのタイミングでissueを自動的に閉じられる
  • 「これで終いや！」と Fix #[0-9]+ をつけてコミットすると、大概あとから修正箇所が出てくるので、そもそもコミットメッセージに書かないほうがいいと思う
• もしissueへの参照を記入したければ、URLを完全に記入する
  • これは妥協なので、過去の情報資源をアーカイブしておく必要がある（さもなければ失う）

根本的な対処法はないだろうか

• Git リポジトリ中にすべてのコミュニケーションを含める？
  • 情報資源を喪失することは少なくなるだろうが、ソースコードを管理するという責務以外のことがリポジトリに混ざってしまうのは忌避感がある
• issue, pull requestなど、ホスティングサービス上の情報資源をアーカイブしておく？
  • やはり力技に思える