（以下、id:eel3:20160105:1451997199 の副音声を大音量でお楽しみください）
- （論理的に一塊である）小さな作業ごとにコミットしろ
- コミットログを残せ
- コメントで残すな、コミットログで残せ
- コメントアウトして残すな、履歴間の差分を残せ
- 不要なファイルは消せ
- ソースコードは現状を示せ、歴史的経緯はVSCに委任しろ
（論理的に一塊である）小さな作業ごとにコミットしろ
実際には、この方針に合致する作業ばかりではない。
例えば、1つの作業の論理的なまとまりがどうしても大きくなるが、実装時には何らかのフェーズごと（例えば1日ごと）にコミットしておきたいとか。
例えば、作業を1つずつコミットして記録を残しておきたいが、リポジトリへの反映は複数まとめて一度に行いたいとか。
こういうとき、自由度の高いGitは便利だが……学習コストが高めなのがネック。自分だけでなく、チームの他のメンバーや、新人とか、教育をどうするか？ 悩みは尽きない。
コミットログを残せ
コミットログの内容に無頓着な人は、意外と多い。なんで皆、後で誰かが困るようなことを平気でやるのだろう？
不要な部分を削って簡潔に、しかし重要な部分は残して分かりやすく――簡潔で分かりやすいコミットログを書くのは、たしかに簡単なことではない。しかし、これをしっかりやっておかないと、問題発生時に過去に遡って調査するときに困るのだ。
そうそう、アレもコレも詰め込んだコミットは、コミットログを書く時に困る。だから前項の「（論理的に一塊である）小さな作業ごとにコミットしろ」に従ったほうがよいのだ。
コメントで残すな、コミットログで残せ
コミットログの内容に無頓着なのに、ソース中のコメントで「○○のため××に変更」とこまめに書く人のメンタリティを知り……たくはないな。
不要なファイルは消せ
百歩譲って変更前のファイルを取っておくにしても、次のような感じなら、まだ分かる。
foo.js <-- 最新版 foo.js.old <-- 使ってない foo.js.old2 <-- 使ってない
しかし、次のような感じとなると、全く理解できない。
foo.js <-- 使ってない foo2.js <-- 使ってない foo3.js <-- 最新版
なぜ、わざわざファイル名を変えて、VCSで差分を確認するのに妙に手間がかかる方法を採用するのか？
ソースコードは現状を示せ、歴史的経緯はVSCに委任しろ
これ、頭では分かっていても、実際の行動は残念だったりする。これを書いている私だって、きっと陰では皆に(ry
