コミットポリシーはありますか?

Question

私の上司は昨日、リポジトリへのチェックインに関する新しいコミット ポリシーを発表しました。このポリシーは、ヘッド/トランクおよびブランチへのコミットに有効です。
コミット メッセージには次の項目が含まれている必要があります。

• 理由 (バグ ID、プロジェクト ID、または機能以外の変更)
• 査読者の名前

コミット後、CMS に変更ブログ エントリを作成する必要もあります。

私はこのコミット ポリシーの大ファンではありません。なぜなら、非生産的なブランチで新しいことや実験的なことをしているときは、通常、レビュー担当者は必要ないからです。

従う必要があるコミットポリシーはありますか?

バグレポートのためにのみ生産ブランチを変更するのは良い考えだと思いますが、開発ブランチへのコミットはそれほど制限的ではないはずです。

Answer 1

早期にコミットし、頻繁にコミットする。

実際には、/ trunkを開発およびタグとして使用して、異なるリリースを分岐します。 / branchesには、構造的な侵入的な変更のみが含まれます。

生産リリースと承認リリースにタグを積極的に使用しているため、簡単に時間を遡ることができます。トランクでコミットされたものには、コミットが変更または追加された内容を簡単に説明するメッセージのみが含まれている必要があります。

メッセージスペースを使用してバグIDにリンクすることはあまり好きではありません。IDを検索する必要があります。その場合は、バグ追跡ソフトウェアで検索して閉じて、ほぼ同じ努力です。

svn統合が好きではないと言ってはいけません： -自動化されたnantスクリプトの優れた機能を使用して、/ tagsで分岐するリリースを作成します -svn propsは実際にバージョン番号を保存します：p。 -電子メール通知およびメッセージロギング用のフックスクリプト（リリースノートのコピーの貼り付けに最適）。

Answer 2

多数のポリシーがあり、それらはVisual Studioへの社内プラグインを介して適用されます。コードがコンパイルされ、ユニットテストが正常に実行されたことを確認します。現時点では、コードカバレッジも確認し、十分なテストがないコードに対して警告を発行します。また、さまざまな一貫性チェックを行い、すべての変更のトレーサビリティを提供するために、変更管理システムに適切なタスクが存在することを確認します。

ポリシーを尊重するのは実際には人次第ではないため、ツールサポートの利点は大きいですが、明らかにこれらのチェックの実行には時間がかかるだけでなく、欠点もあります。ただし、多くの開発者では、適切なツールサポートなしに標準を実施することは困難です。

Answer 3

レビュアーは、他の人がすべてをレビューする必要があるわけではないので、あなたが言及した理由で無意味に思えます。

過去に私が持っていた唯一のコミットポリシー（私が働いていた場所）は、変更内容と理由を示すコメントを含めることでしたが、それは他の何よりも常識です。

Answer 4

一般的なコミットポリシーは、正当な理由としてトランクへのコミットにバグIDを関連付けることです。時々、バージョン管理とバグ追跡システムがこのポリシーを実施するように設定されます。

Answer 5

コミットポリシーはあなたのものに少し似ていますが、タスクブランチ（実験用の開発者のサンドボックスのようなタスクブランチ）には適用しません。

コミットコメントには、変更管理ID（新機能、機能強化）または問題ID（バグ修正）を含める必要があります。また、この変更を行ったなぜに関する簡単な説明も含める必要があります。バージョン管理は、誰が、何を、いつ、どこで追跡します。

Answer 6

コミットメッセージには、クラスで実装または変更した内容の簡単な説明が含まれています。

新しいコードの上のコメントに記載されているバグ番号と追加の説明。タグ付きブランチに変更をマージするときに配置するコミットメッセージ内のID。

毎晩、自動ビルドがさまざまな機能をチェックし、製品もコードベースが安定していることを確認します。

しかし、最終的には、新しいクラスまたは変更されたクラスについてあまり多くの記述をすることはできませんが、コミットする前に行う必要があるポリシーが多すぎると思います。レビュー担当者の名前は、コミットメッセージに含めないものです。

2年前に実装したコードを理解する必要がある場合があると考えてください。そして、「デバッグ後に更新する」のようなものではないコミットメッセージに満足しています。

Answer 7

現在もアクティブにサポートされているソフトウェアのリリース済みメジャー バージョンごとにブランチがあります。これらのブランチのいずれかにチェックインするにはバグ ID が必要です。これは、によって強制されます。 スクムバグ, これは、コメントの先頭にバグ ID が付いているかどうかをチェックするだけでなく、このバグをバグ データベースで検索し、それがコミッターに割り当てられていることを確認し、場合によっては他の基準 (例:「ブランチ内の修正」フィールドがコミットされているブランチであることを確認してください)。

製品の 1 つは恥ずかしい方法で失敗する可能性が高く、これをチェックインするにはバグ ID だけでなくコード レビューも必要です。ただし、コード レビューの基準はバグ データベースで処理されます。これにはカスタム フィールドがあり、レビューされるまでバグを受け入れて閉じることはできません。私にとって、これは概念的なレベルで機能します。おそらく、問題が解決するまでコミットを保留するのではなく、リポジトリに機能すると思われるコードをレビューせずにチェックし、必要に応じてバグを再度開いて変更する方が良いでしょう。 もちろん リリースの準備ができています。

それ以外には、トランクに対する明示的なポリシーはありません (もちろん、ビルドを中断せずに頻繁にチェックインするという一般的な原則 (適切な説明的なコミット メッセージを含む)、作業単位でのアトミックなチェックは引き続き適用されます)。