上司は昨日、リポジトリへのチェックインに関する新しいコミットポリシーを発表しました。このポリシーは、ヘッド/トランクおよびブランチへのコミットに有効です。
コミットメッセージには、次の項目が含まれている必要があります。
コミット後、CMSに変更ブログエントリも作成する必要があります。
私はこのコミットポリシーの大ファンではありません。非生産的なブランチで新しいことや実験的なことをしているときは、通常、レビュー担当者は必要ないからです。
従わなければならないコミットポリシーはありますか？
バグレポートのためだけに生産ブランチを変更するのは良い考えだと思いますが、開発ブランチへのコミットはそれほど制限されるべきではありません。
早期にコミットし、頻繁にコミットします。
実際には、開発として/ trunkを使用し、さまざまなリリースを分岐するためのタグを使用しています。/branchsには構造的な侵入的な変更のみが含まれます。
制作リリースと承認リリースにはタグを積極的に使用しているため、簡単に過去にさかのぼることができます。トランクでコミットされたものには、コミットが変更または追加された内容を簡単に説明するメッセージのみが含まれている必要があります。
私はメッセージスペースを使用してバグIDとリンクするのが好きではありませんが、それでもIDを検索する必要があります。その場合は、バグ追跡ソフトウェアで検索して閉じることもできます。同じ努力。
言うまでもなく、私はsvn統合が好きではありません：-自動化されたnantスクリプトの優れた機能を使用して、それらを/ tagsで分岐するリリースを作成します-svnpropsは実際にバージョン番号を格納します：p。-電子メール通知とメッセージログ用のフックスクリプト（リリースノートのコピー貼り付けに最適）。
Visual Studio への社内プラグインを介して適用される多数のポリシーがあります。コードがコンパイルされ、単体テストが正常に実行されたことを確認します。現時点では、コード カバレッジもチェックし、十分なテストがないコードに対しては警告を発します。また、さまざまな一貫性チェックを行い、すべての変更のトレーサビリティを提供するために、変更管理システムに適切なタスクが存在することを確認します。
ポリシーを尊重するかどうかは実際には人次第ではないため、ツール サポートの利点は大きいですが、これらのチェックの実行に時間がかかるという欠点があることは明らかです。ただし、多くの開発者にとって、適切なツールのサポートなしに標準を適用することは困難です。
すべてが他の人によってレビューされる必要はないので、あなたが言及した理由のためにレビューアは無意味に思えます。
以前、私たちが持っていた唯一のコミットポリシー（私が以前働いていた場所）は、あなたが何を変更したのか、そしてその理由を示すコメントを含めることでしたが、それは他の何よりも常識です。
私たちのコミット ポリシーはあなたのものに少し似ていますが、タスク ブランチには適用しません (タスク ブランチは、実験のための開発者のサンドボックスのようなものです)。
コミット コメントには、変更管理 ID (新機能、機能強化) または課題 ID (バグ修正) のいずれかを含める必要があります。この変更を行った理由についての簡単な説明も含める必要があります。バージョン管理は、誰が、何を、いつ、どこで追跡します。
一般的なコミット ポリシーは、正当な理由として、バグ ID をトランクへのコミットに関連付けることです。場合によっては、バージョン管理およびバグ追跡システムがこのポリシーを適用するように構成されています。
現在もアクティブにサポートされているソフトウェアのリリース済みメジャー バージョンごとにブランチがあります。これらのブランチのいずれかをチェックインするには、バグ ID が必要です。これはscmbugによって強制されます。これは、コメントにバグ ID がプレフィックスとして付けられていることを確認するだけでなく、バグ データベースでこのバグを検索し、それが割り当てられていることを確認します。コミッター、および潜在的に他の基準をチェックします（たとえば、「ブランチで修正」フィールドがコミットされているブランチであるなど）。
製品の 1 つは、厄介な方法で失敗する可能性が高く、これをチェックインするには、バグ ID だけでなくコード レビューも必要です。ただし、コード レビューの基準はバグ データベースで処理されます。これにはカスタム フィールドがあり、レビューが完了するまでバグを受け入れてクローズすることはできません。私にとって、これは概念レベルから機能します。準備ができていることを確認するまでコミットを保留するよりも、レビューされていないリポジトリで機能すると思われるコードをチェックしてから、バグを再度開いて必要に応じて変更する方がよいでしょう。リリース用。
それ以外には、トランクの明示的なポリシーはありません (もちろん、ビルドを壊さずに頻繁にチェックインするという一般的な原則、適切な説明的なコミット メッセージ、アトミックな作業単位のチェックインなどは引き続き適用されます)。
私のコミットメッセージには、クラスで実装または変更した内容の簡単な説明が含まれています。
バグ番号と追加の説明は、新しいコードの上のコメントに記載されています。タグ付けされたブランチに変更をマージするときに入れたコミット メッセージ内の ID。
毎晩、自動ビルドがさまざまな機能や製品をチェックし、コード ベースが安定していることを確認します。
しかし、最終的には、新しいクラスや変更されたクラスの説明が多すぎるのではなく、コミット前に実行する必要があるポリシーが多すぎると思います。レビュアーの名前は、私がコミット メッセージに入れないものです。
2 年前に実装したコードを理解する必要がある場合があることを考えてみてください。そして、「デバッグ後に更新」のようなコミットメッセージに満足しています。