Git コミットのフォーマットに関するガイドライン

GROMACS 向けのコードレビュー用の新しいコミットを提出する方法について、厳密な正解はありませんが、以下のガイドラインに従うことで、レビュープロセスを円滑に進めることができます。

新規に提出されたコードに関する一般的なルール

新しいコードは、提出する前に、上記で示されている他の `:ref:``スタイルガイド<style-guidelines>`に従う必要があります。これにより、変更がスタイルに準拠していないために拒否される可能性が低くなります。 既存のコードを変更し、それがまだスタイルに準拠していない場合、変更前のコードを修正するプレバッチを作成することをお勧めします。 機能を追加または変更する際に、徐々に品質を向上させていくことを好みます。

Git コミットメッセージのガイドライン

コミットメッセージには、変更内容または変更の目的に関する簡単な説明（動詞形）を含める必要があります。利用可能な場合、メッセージの最後の部分（ChangeIdの前に）には、変更を関連する可能性のある以前に投稿されたissueにリンクするための短いセクション（例：Fixes #issue-id）または、現在のパッチがその作業に関連しているものの、問題を完全に修正しない場合に、Refs #issue-id を含めることができます。

コードコメントに関する

新しいコードは、他の人がコードの目的を理解できるように、十分にコメントされている必要があります。コードの具体的な動作ではなく、変数名やコード構造が仕組みを明確にし、コメントは、アルゴリズムの選択や、コードの他の部分との整合性を保つというような、より上位の概念にのみ言及する必要があります。

たとえば、次のコメントだけでは、(架空の例) 相互作用のリストを反復処理することの説明としては不十分です。

/* Code takes each item and iterates over them in a loop
 * to store them.
 */

より良い例としては、なぜイテレーションが行われるのかを説明することです。

/* We iterate over the items in the list to get
 * the specific interaction type for all of them
 * and store them in the new data type for future
 * use in function foo
 */

「上記の例から、デバッグ作業を行う人が、foo で発生したエラーが、前の代入によって引き起こされたものであるかどうかをより正確に判断できる可能性があります。」