コミットメッセージを書く必要があるのはなぜですか？

コミットメッセージを書く必要があるのはなぜですか？私はしたくないし、私は毎回その愚かだと思う。

名前のないGUIフロントエンドを使用すると、強制的に実行されます。コマンドラインでVCSを使用している場合でも、他の人が毎回それをしていると聞きます。

1日に数回コミットし、機能を終了していない場合、何を書いていますか？私は何度もコミットした後にメッセージを書くだけで、ミニタグの時か、実際のタグを行う時だと感じています。

私は正しいですか、何かが欠けていますか？また、私は分散システムを使用しています

「役に立つ、よく考えられたメッセージがあり、機能が100％完了し、ユニットテストがある場合にのみコミットする」と言っているすべての人に、私は言います：あなたはまだSVNの考え方にいます。

gitを使用している場合、これは私がスマートワークフローと呼ぶものです。

1. 好きなだけコミットします。そこに古いクイックメッセージを書き込みます。とにかく誰もそれを見ません。
2. 10件のコミットを行った後、作業していた機能が終了しました。次に、テストを作成し、それらのテストをコミットします。またはあなたが望む他のもの。TDDが好きなら、最初にテストを書いてください。Gitも気にしません。
3. git rebase -i追加した最初の「乱雑な」コミットから、最近の履歴を削除、編集、省略、またはクリーンアップしてローカルメッセージの履歴を整理し、きれいなメッセージを含む論理的でクリーンなコミットにします。
4. クリーンアップ後、誰かにあなたから引き抜いてもらう。
5. すすぎ、繰り返します。

ステップ3は、あなたが望んでいたすばらしいコミットに終わったときであり、SVNを使用すると、最初の2つのステップを完了するまでコミットを控えなければならないことに注意してください。これは他の答えのほとんどが示唆しています。IOW、あなたは他の人にテストされていない半分書かれたコードを与えたくないので、あなたの機能が完了するまで1週間コミットしません。バージョン管理を最大限に活用していません。

また、ステップ1と3の間のどこでもgit push、ラップトップHDDが死んだ場合に無料のバックアップを取得するために、サーバー上の自分のプライベートリポジトリミラーに変更を加えることができます。

貧弱なメンテナーがバグを探していて、それがrevに追加されたことを見つけたとき。xyz、彼はどの回転数を知りたいでしょう。xyzが行うことになっていた。

ソースコードにコメントしますよね？

あなたは非常に最高のコメントを書きます。コードがどう言っているのか、理由を言うものですか？

コミットメッセージはそのようなコメントであり、したがって、それは非常に重要であり、あなたがそれを正しくすることにもっと考えれば考えるほど、それはソフトウェアの将来のメンテナーにとってより有用です。

アクティブなソフトウェアの場合、この特定のコメントは次のように表示されます

（http://longair.net/blog/2009/04/25/a-few-git-tips/にあります）。これにより、いつ、誰がソフトウェアに取り組んだか、誰が何をしたかを鳥瞰することができます。

これがコミットコメントの最終的な目標であることに注意してください。つまり、あなたの将来の自分や同僚に「何」と言うようなリストに表示することです。

コミットメッセージがあなたにとって愚かに見えるなら、あなたは間違ったコミットを使用しているように聞こえます。

コミットは正当な理由で行う必要があります-作業中の機能のために分解したタスクに関連する必要があります。これらのタスクが正式なものであれ、頭の中にあるものであれ、コミットする各変更はタスクをほぼ完了する必要があるため、何らかの方法で機能する必要があります。

次に、コミットメッセージの方がはるかに優れた目的を果たします。終了したタスクと、それがどこか他の場所で追跡されていない場合、そのタスクが必要な理由、またはその目的を説明してください。

• カプセル化を改善するためにユーザークラスをリファクタリングしました
• インターフェイスをコントローラークラスで使用できるようにAPIスタブを作成しました
• 模擬データベースをテストケースで使用できるように、データベースクラスを抽象クラスに変換しました

その後、あなたまたは他の開発者はリポジトリまたはファイルの履歴を閲覧して、特定の進化がどこで起こったのか、そしてその理由をかなり簡単に見ることができます。または、特定のリビジョンがバグであると判明した場合、コミットメッセージはその行が挿入された理由についての手がかりを提供します。修正され、代わりに正しい方法で修正できます。

コメントをコミットしてもすべてが解決するわけではありません。特に開発者がそれらを入力しなければならないことに怒っている場合、彼らは彼らが助ける限り誤解を招く可能性が常にあります。これを試してください。森の中のパンくずリスト、登山ウェイポイント、トレーサーの弾丸のように考えてください。うまく行けば、他の方法ではわかりにくいパスを概説できます。

それらから大したことをしないでください。正直に言うと：

• 「機能Xを処理するために編集された空間インデックスエンティティ、Daos、およびUI」
• 「機能リクエスト＃1234およびバグ＃5678のインクリメンタルチェックイン」
• 「最後のビルドを壊しました。これらは私が見逃したファイルです。」

短くして「全体像」を保ちます。可能であれば、機能/バグシステムの問題番号を参照してください。一部のバージョン管理UIには、この種のフィールドが含まれています。

WTF /分の数を減らします;）

より幸せなチーム（あなたを嫌わない）に変換し、潜在的に低コストでより良いチームの出力

したがって、チームの他のメンバーは、プロジェクトツリーへの変更をチェックインしているWTFを知っています。

ちゃんとしたコミットメッセージを入力する練習をしなければ、次のようなメッセージを入力する私の同僚のようになってしまうからです。

no changes

または

testing

100以上の変更されたファイルを使用したコミット（冗談はありません!!）。

そのような開発者になれば、メッセージを入力するだけでどんなに愚かだと思っても、世界の他の人の目には愚かに見えるでしょう。

変更に意味がない場合、なぜコミットするのですか？

意味のある変更をコミットするだけです。例えば、私は他の週にかなり大規模なリファクタリングを行い、約3日かかりました。その間に大量のコミットがありました。若干の変更（「新しい責任を反映するためにクラスXからYに名前を変更」または「クラスQにメソッドZ（）を移動」）と、他のものは非常に大きな変更でした。機能/リファクタリングが完了したら、いくつかのコミットがつぶれる可能性があるかどうかを確認します（少なくともgitはそれをサポートしますが、他のツールについては知りません）。

行の編集の途中でコミットしないと思うので、意味があるはずです。最後のコミット以降に何をしたかを説明してください。

いくつかの変更を行ってシステムを壊したときの状態を想像し、チームによるいくつかのコミットの後にこれを実現します。変更が何であったかは覚えていませんが、機能Xを拡張したり、モジュールYからファイルを削除したりすると、何かがおかしくなる可能性があることを覚えています。

しかし、残念ながらリビジョン番号はXまたはYを変更したときに通知されません。したがって、この選択は過去N日間にコミットされたすべてのコードを読むか、または書いた詳細なコミットメッセージを読むだけです（コードよりもはるかに読みやすい）。

したがって、コミットメッセージに同じ、退屈な、役に立たない、無関係なテキストを書くと、コミットメッセージを持つよりも有害です。バグの根本を見つけるのではなく、間違ったメッセージがあなたを誤解させるからです。

したがって、コミットするたびに意味のあるコミットメッセージを作成してみてください。これはあなたとメンテナーにも役立ちます。

他の人と一緒に作業している場合、コミットメッセージは他の人が何をしたかを実際に確認するために非常に重要です：各人の差分を検索することはより多くの作業であり、誰かがそれをした理由を取得できないことがあります あなたが他の人と仕事をし、誰か（おそらくあなたではない）が実際に振り返らなければならない場合、例えば、予期しない方法で以前のバージョンからどのように振る舞いが変わったかを追跡するために...メッセージ。

単独で作業している場合...ほとんどが「そのまま」コード化されているプロジェクト（たとえば、単一の単純なWebサイトまたはスクリプト）で、私は多かれ少なかれあなたがどこから来たのかを見ることができます。私がそのようなものに取り組んでいる場合、何かに取り組んでいるときに日付/時刻または最新の変更のみを気にします（復元するポイントがありますが、それは実装後ではなく開発中にのみ重要です）。バージョン管理は、いくつかのプラスを使用してバックアップを作成する方法にすぎません-システムを完全に使用していないことに完全に同意します-しかし、一部の小規模プロジェクトでは、それは必要ないかもしれません。

バージョンコントロールが2つの分割された方法で使用される前に、私は思いつきました。1つはプロジェクトの変更を文書化する方法、もう1つは開発者への手伝いとして... コミットメッセージは、ある意味では非常に重要ですが、他の意味ではほとんど役に立たない場合があります。

あなたは何かが欠けています。コミットを実行する理由があるに違いありません。そうしないと、コミットしません。

コメントで行う必要があるのは、理由が言葉だけであっても、理由を言葉にするだけです wip: adding new state objects

他の多くの人と同様に、私は暇なときに少しコーディングを行い、リビジョン管理システムを使用して開発と変更の両方を追跡します。空き時間は、週ごと、月ごとに大きく異なります。多くの場合、何週間も何ヶ月もプロジェクトをコーディングする時間がなく、通常10分（通常は1日）から40分（良い日）の範囲でした。それらは確かに素晴らしい状態ではありません-特に問題をデバッグするために。

紛失せず、簡単に取得できるメモを保持することが不可欠でした。各セッションの終了時に、セッションの作業は詳細なメッセージとともにコミットされます。その後、コミット履歴を調べて、進行状況と思考プロセスを追跡できました。これにより、先週、または先月の貴重な時間の損失を最小限に抑えながら、自分がどこにいるかを確認できました。

私が説明しようとしているポイントは、良いコミットメッセージがあなた（そしてあなたの後を追う他の人）が何が起こったのか、何が起こっているのか、何が起こっているのか、何よりも何故なのかを理解するのに役立つということです。

論理的に考えてみてください。コミットしているときは、何かが行われたことを意味します。メッセージを残さなかった場合、他の人は何が行われたかをどのように知るでしょうか？

コミットにコメントしないと、ソースの変更にコメントしたくなるかもしれません。やがて、それはソースを混乱させる可能性があります。

コミットメッセージは、チェックインの内容をすばやく知る方法であり、チームの他の開発者がコードのどの側面がどのリビジョンで変更されたかを知りたい場合に役立ちます（理由があります）。

関連するメモでは、コミットメッセージでバグトラッカーのケース番号（使用していることを望みます）を指定することをお勧めします。これにより、今後の追跡が容易になります。

そのコードのメンテナーが1年後に、その凶悪なコードを誰が追い詰めるべきかを知るように。:)