ソロ開発者としてコミットメッセージを作成しますか？

私と他のプログラマとの間でリポジトリが共有される私のプロジェクトでは、私が主な開発者であっても、常にコミットメッセージを書き込みます。

しかし、私がプロジェクトに取り組んでいるソロ開発者であり、リポジトリが私のラップトップでホストされており、クライアントによってさえホストされていないプロジェクトでは、私以外の誰もコミットを見ることができませんメッセージ？

これまで私はそれらを書いてきましたが、私は決して戻ってコミットメッセージを見たことがないことに気付きました。メッセージを書き留めるために開発に時間をかけますが、それでも私には二度と見られません。

単独の開発者としてコミットメッセージを書く正当な理由はありますか、それともスキップして開発に専念することをお勧めしますか？

ここに理由があります：過去数百のコミットで何かが壊れていることに突然気付いた場合（マイナーな編集ごとにコミットする可能性があり、私のように「安定した」スナップショットのみをコミットする場合は実行不可能です）、より簡単にできます「バグ修正」ではなく、明確なコミットメッセージを書いた場合は、バグを挿入した場所を見つけます。（同僚のお気に入りの文字列、私は信じています）。確かに、あなたが行くことができるsvn logか、使用しているものは何でもSCM、それがなければならない他の方法で回避やすくなります。

また、コミットメッセージを使用すると、変更として何を行ったのかを正確に考える必要があり、プロジェクトを改善し続けることがどのように最適であるかを頭の中でまとめていると思います。

私はいつもしようとします。「この変更を加えたとき、私は何をしていましたか」と振り返って考えます。私はいつもやります。30秒のメッセージを書くことで、覚えようとする20分分の作業を節約できます。

正直に言って、普通の英語で約40〜80文字を入力するオーバーヘッドがコミットの大きなオーバーヘッドであると信じていますか、それとも怠laな言い訳を探していますか？

おそらくあなたが問題を抱えているのは、変更を行った理由を英語で表現することです。その場合、変更の目的を確認する必要があるかもしれません。

私のアドバイスは、単独で飛行しているので、規則を破ることができるとは思わないことです。常にプロフェッショナルであり、意味のあるコミットメッセージを追加します。他の応答者が指摘したように、いつかあなたはそれに感謝するでしょう。

• 常にソロ開発者になるとは限りません。

• 最終的にコードベースを破壊し、それを復元しようとします。適切なコミットメッセージは時間を節約します。

• 3週間前に何をしていたのか思い出せませんね。

• コミットメッセージは非常に明確である必要があります。そうでない場合は、タスクの作業を終了していないか、1つのタスクが2つ以上のタスクに広がっています。

または、分岐やマージなどの機能を使用するのがはるかに難しくなります。そして、たとえソロ開発者であっても、それらを使用したいと思うでしょう。

考えられる理由の1つは、たった今行った変更についてより抽象的に考え、変更を構造化することを強制します。

それが無意味だと感じた場合、おそらく奇妙な振る舞いのソースを探している場合に備えて、大きな変更、または既存の機能を変更する変更をコメントしてください。

私はTXRプロジェクトの唯一のコミッターであり、プロジェクトのかなり早い段階から詳細なChangeLogを保管しています。これは11,000行近くで、成長しています：http : //www.kylheku.com/cgit/txr/tree/ChangeLog

（レポジトリのコミットメッセージは、ChangeLogに記録される内容の単なるコピーです。）

[2016年の編集：2015年半ばの時点で、ChangeLogファイルを管理しなくなりました。ただし、コミットメッセージは、GitとChangeLogの規則に同時に準拠する形式で書き込まれます。マージの問題を引き起こさないように、同じレベルの詳細がそこにあります。ChangeLogファイルは、これらのコメントから機械的に再構築できます。]

はい、何かを壊した変更に関連する古いコミットメッセージに何度も戻りました（の助けを借りて発見されましたgit bisect）。このメッセージは、私がやっていることを理解するのに役立ちました。

ChangeLogでは、関数、型、マクロ、またはグローバル変数が最初に導入されたときと、その後に変更が加えられたときを確認できます。

しかし、自分で作業しているときにこのような詳細なコミットメッセージを書く主な理由は次のとおりです。これを行うとバグが見つかります。

詳細なコミットメッセージを書くことは、他の誰かによるコミットのコードレビューと同様の利点があります。コミットレビューの価値は、誰かがあなたのコードをチェックするほどではありませんが、変更を別の開発者に説明する必要があります。

物事を説明しようとすると、時には意味が分からないことがあります。

別の理由：役に立たない変更を加えることができます。詳細なコミットコメントを書くことで、自分がやっていることの高レベルのビューをキャプチャし、その後、それが良い変更ではないという事実に直面することがあります。

変更ログエントリを書いている最中に、これがgit reset --hard（これらの役に立たない変更を破棄する）であることに気付いたとき、時々変更を加えましたgit commit -a。

コミットメッセージを表示する必要性にまだ出会っていませんが、将来それらに感謝するかもしれません。あなた自身のためにそれらを書き続ける必要があります。後で役立つ可能性がある多くの理由があります（機能を追加する理由を忘れたり、不足しているファイルを見つけるなど）。

コミットメッセージの目的に関する関連する質問を次に示します。コミットメッセージを作成する理由

私は常に変更に関する意味のあるメッセージでコミットしますが、増分変更を頻繁に行います。

これは常に最も有用なものですか？いいえ、そうすることで問題はありません。進行中の前の段階に戻す必要がある場合は、メッセージを使用して、自分がどこにいて何をしたかを知ることができます。また、プロジェクトの進行状況を追跡するためにも使用できます。時間の浪費と見なされているので、文章を書き留めるのに30秒かかるのは本当にその結果ですか？

チームで働いているかどうかに関係なく、コミットメッセージに関する違いは見当たりません。あちこちでやったことを限られた時間だけ覚えて、その後は他の誰かが書いたのと同じです。ですから、他の人たちと同じくらい良いメッセージを書くべきです。