4

COMMENTINGコミットのベスト プラクティスは何ですか?

少し背景。

  • すべてのプロジェクトでバージョン管理 (Subversion / SVN / Git) を使用しており、
  • それらのほとんどは、2 人以上の開発者が触れています。
  • Springloops を使用してバージョン管理をホストしています。これは、「ただ機能する」だけでなく、内部の開発者が管理するよりも安価であるためです。
  • 非常に多くのクライアントが特別なセットアップを行っており、複数のユーザー向けにこれらの環境をセットアップする作業が行われているため、ローカルの開発環境に煩わされることはほとんどありません。ほとんどのクライアントは、クラウド内に開発の場所を持ち、次にライブの場所を持っています。Springloops は、すべてのコミットを開発サーバーに自動的にプッシュするように構成されており、開発者はライブの場所に手動でプッシュする必要があります。

私たちのポリシーは、あなたがコミットしたことすべてにコメントすることですが、最近、私たちの何人かがその考えに反抗しました.

すべてにコメントすることの問題点は 2 つあります。それは、より多くの作業が必要であり、役に立たないということです。私たちが見る問題は次のとおりです。

  1. これは、すでにバージョン管理されていることをカバーするコメントを作成することを人々に奨励します (つまり、42 行目を何とかするように変更しました)。比較するだけで同じ情報が得られます！

  2. または、コメントを検索したい場合に非常に苦労する、役に立たないコメントでコメント ストリームがいっぱいになります。

    • IE8 のマージンの問題
    • IE8 のマージンに対する別の修正
    • その最後の修正を元に戻し、IE8で余裕を持って何か他のことを試す

これらのことはどちらも、多くの時間を追加するだけで、何の価値も追加しません。コメントは、すべてをスキャンできるほど具体的でまれである場合にのみ役立ちます。

Git は Subversion よりもスマートな方法でこれを処理すると言われており、変更に対してオープンであり、明らかにローカル開発環境を持ち、変更のバッチのみをコミットすることも役立ちますが、ユースケースに基づいて、おそらく効率の面での純損失。

コミットにコメントするためのベスト プラクティスをぜひお聞かせください。フィードバックをお寄せいただきありがとうございます。

4

4 に答える 4

9

Gitは問題を解決しません。この「単純な」質問に答える必要があります。コメントの価値をどのように高めることができますか？

いくつかのガイドライン：

  1. コミット自体から明らかなコメントには何も言及しないでください（どの行が変更されたかなど）。最新のツールでは、コミットメッセージとコミットが画面に並べて表示されます。作業を複製する意味はありません。

  2. 代わりに、変更を加えた理由を説明してください。これは通常、明らかではありません。バグレポートでしたか？バグのIDを含めます。それはあなたが見つけたものでしたか？

  3. 1回のコミットで複数の修正をコミットする必要がある状況に頻繁に遭遇する場合は、集中することを学ぶ必要があります。コードを変更するときは、気まぐれに従わないでください。一つのことをして、それを終えて、それをコミットしてください。次に、次のことを行います。

    途中で何かにつまずいた場合は、メモを取ります（紙の上、または画面の隅にホバリングし続ける追加のテキストエディタで）。常に作業を中断しないでください。マルチタスク/再帰的なコード編集は、品質とストレスレベルに深刻な影響を及ぼします。

「固定IE8マージン」コミットの長いリストは引き続き表示されますが、それ自体は問題ではありません。「コメントを検索したい」と言うときは、コメントに役立つ情報を入れて、合理的に検索できるようにする方法を考え出す必要があります。たとえば、バグIDには常に同じ形式を使用します。プレーンテキストは検索、特に簡潔なメッセージのコミットには適していません。

コメントを省略するだけでは解決策ではありません。怠惰であるか、ソシオパス（「他の誰かが問題を抱えているかどうかを気にする人」）または悪いトレーニング（「何を書くべきかわからない」）であることの兆候です。

最初と最後はトレーニングで解決できます。2つ目は、リスクを取り除くことです（つまり、男を解雇します）。

世界でバージョン管理ツールはあなたを助けることができません。

于 2012-08-17T13:53:38.373 に答える
2

私の大まかなルールは、コミットの変更を2文未満で要約できない場合、最後のコミットから長すぎるということです。

そして、その文に何を書くかについては、その情報がコミットに埋め込まれているので、行固有またはファイル固有のことは決して言いません。私は通常、プロジェクトに参加していない人に説明するように、平易な英語で特定の変更について言及します。

私でも他の誰かでも、プロジェクトがどのように開発されたかのストーリーのようにコミットログを読み取ることができるため、これは非常にうまく機能します。コミットログをコピーして貼り付けるだけのブログ投稿も行いました。

于 2012-08-17T13:52:44.530 に答える
2

私の哲学は次のとおりです。

  1. できるだけ早くコミットする
  2. コミット前の更新とビルド
  3. コミット前の差分
  4. ビルドを壊さないでください: コミット後に更新し、ビルドをテストします

これはすべて、すべてのチームメンバーが従うべき個人的な規律の問題です. ビルド マネージャーは、ビルドが壊れた場合、真夜中に人々を起こすことを「推奨」されています。

于 2012-08-17T13:41:35.537 に答える
1

すべてのチェックインにはコメントを付ける必要がありますが、変更自体を模倣するべきではありません。コメントは、変更自体に記載されている変更の実装の詳細ではなく、何が変更されたかについての簡単な一般的なコメントである必要があります。

于 2012-08-17T13:43:03.683 に答える