Subversion：正しいコミットのチェックリスト

読者は次のことを前提としています。a）チームで働いている。 およびb）バージョン管理システムで正しく動作する必要性を認識したか、少なくともバージョン管理システムを使用する必要性に直面しました。



例ではSubversionが使用されますが、すべての推奨事項は他のバージョン管理システムにも完全に適用できます。



プロジェクト開発の段階を、デビュー、ミドルゲーム、エンドゲームの3つに大まかに分けます。



デビューでは、新しいコードは巨大なチャンクで記述され、多くの場合、システムのチャンク全体が場所から場所へ転送されます。 リリースは遠く、システムの一般的な状態に関する特別な要件はありません。 システムを特定の制限まで壊すことさえ許されます。



ミドルゲームでは、システム全体が安定しており、製品のリリースが近づいています。 リファクタリングはより明確ですが、時には非常に広範囲に及ぶことがあります。 この段階では、システム全体が動作していることがすでに予想されています-少なくとも壊れたリポジトリは非難されています。



最後に、システムはリリースの直前と直後にエンドゲームに入ります。 Webアプリケーションでは、比較的小さな新しい機能が絶えず追加されており、最初に大きな変更がブランチでテストされます。 逆に、従来のアプリケーションでは、メンテナンスリリース用にブランチが作成され、次の大きなバージョンの開発がトランク上で継続されます。







コミットは、デビューでは比較的まれです。 たとえば、新しいクラスや新しい関係を作成したり、十分な大きさのコードの予備バージョンを作成したりすることは、良いコミットポイントになります。 一部のプログラマー、特に高性能のプログラマーにとっては、1日2回から3回の時間制限のあるコミットが便利な場合もあります。 リポジトリは、抽出されたコードが単にコンパイルされないという点まで、かなり「解析された」状態になります。



ミドルゲームでは、コミットフローはより構造化されています。 コミットはより頻繁に行われ、構造的な変更のみに結び付けられます。 コミットは基本的に平均に過ぎません。 コミットの良い点は、トラッカーのタスクまたはバグを閉じる、別の機能をリファクタリング、追加、または修正することです。 リポジトリはほぼ常に効率的な状態にあり、壊れたリポジトリは非難されます（そして、壊れたという事実はカルマの打撃を引き起こします）。



最後に、最終段階では、コミットは何らかの形で厳密に制御されます。 一般的に、このフェーズでプロジェクトに取り組んでいるという事実には正当性が必要です。これは通常、バグまたはリリースのために転送された重要な機能です。 このフェーズでのコミットはすぐに実稼働に移行するため、次のようになります。バグトラッカーに明確に関連付けられています。 比較的小さい。 十分に文書化されています。 十分にテストされ、考え抜かれました-この段階で追加のバグを導入すると、深刻なカルマの打撃を与えます）。



かなり大規模なソフトウェアシステムの開発、サポート、およびレビューにおける長年の経験に基づいて、一連の重要な推奨事項をまとめました。 彼らは、第一に、プロジェクトに取り組むときの認識の深さを増やすために呼ばれます。 第二に、コードレビュアーの作業を促進するため-バグや欠陥を検出する確率。 第三に、将来のある時点でプロジェクトの歴史を理解することを余儀なくされる人の運命を促進するため（現在のコミットの著者もそのような人になることが多い）。



一般的に、私たちの意見では、彼が取り組んでいるプロジェクトのプログラマーによる理解の深さは、彼が仕事の過程で行うコミットの質と強く相関しています。



コミットは論理的でなければなりません。 コミットは、1つの構造単位に対応する必要があります-新しいファイル、新しいブロック、新しいインクルーダー、新しいクラス、新しい関係、新しい機能、クローズドバグ、単一のリファクタリング、ドキュメントのヘッド、ドキュメントの修正など。



この要件の意味は、未来のために遊ぶことです。 それを観察することで、ストリーム内の1つまたは別のコミットが安全である（たとえば、ドキュメントを修正する）か、または1つの論理変更がロールバックされたという確信を持って自由にポンプアウトできます。 これは、バイナリエラー検索の貴重な機能です。 さらに、論理的な変更はコードレビュープロセスでレビューする方がはるかに簡単であることは明らかです。



コミットをテストする必要があります（デビューフェーズを除く）。 変更が一般に単体テストでテストされる場合に理想的です。 極端な場合、コミットを少なくとも1回チェックする必要があります。最も無害な修正でさえ、カルマに悲惨な結果をもたらす可能性があります。 もちろん、コミットは構文的に有効でなければなりません-修正の修正はイメージに当たります。



コミットは十分に文書化する必要があります。 空のジャーナルメッセージについては黙っています。これは一般に最悪の事態です。 これは、プログラミングから完全に遠い従業員（デザイナーなど）に対してのみ許可されます。従業員は、このテーマにまったく同意しません。 そして、そのような人々でさえ文化レベルで取り組むことは理にかなっています！ 「Fix」または「Fixed」の説明を含むコミットは、diffに2行または3行を超えない場合にのみ許可されます。 それ以上の場合-もっと詳しく書く必要があります。



それとは別に、いくつかの無関係な項目で構成されるジャーナルメッセージの問題を考慮する必要があります。 このようなメッセージが本当の問題の症状であることは明らかです。つまり、コミットは相互に接続されていない複数の部分で構成されています。 この場合の最善の解決策は、コミットの試行をキャンセルし、それをいくつかの部分に分割することです。



ゲーム終了フェーズでは、文書化が不十分なコミットは厳密に非難されなければなりません。 また、コミットがバグクローズである場合、ジャーナルメッセージにバグ番号を記載する必要があります。 同じTracはSubversionと統合し、ジャーナルメッセージのチケット番号を決定し、それらを対応するリンクに自動的に変換します。



コミットする前に、差分を表示し、リポジトリに追加されていない新しいファイルを監視して追加する必要があります。 TortoiseSVNを使用する場合、「変更の確認」という特別なメニュー項目があります。 コマンドラインクライアントでは、svn st（ルーズファイル用）およびsvn diff | 詳細（コミットする前に変更を確認するため）。



誤って何か間違ったことをしないように、このルールを順守する必要があります。 たとえば、エラーを主観的に修正するプロセスでは、「多くの作業があった」ようです。 ただし、差分を表示すると、1行または2行が実際に修正されたことがわかります。 また、表示により、コミットからゴミを削除することができます-たとえば、一時的なデバッグステートメントや空の変更（スペースの追加と削除）。 特定のファイルには空白の変更のみが残っていることがよくあります。元の状態にロールバックする必要があります（svn revert）。 ゲーム終了フェーズでは、コミットする前に変更を確認することが厳密に必要です。



別途、ファイル内の配置とスペースの修正について言及する必要があります。 そのような操作（非常に必要な場合）は、独立してコミットする必要があります。 ゲーム終了フェーズでは、重大な変更とともに空白の変更をコミットすることを許可しないでください。



また、より小さいルール：



-ファイルの名前を変更して変更するときは、名前の変更を個別にコミットし、個別に変更する必要があります。



-サードパーティコンポーネント（Railsプラグイン、prototype.jsファイル）をプロジェクトコードに追加する場合、それらは個別にコミットする必要があります。



-コードのコメント行を残さないでください-古いバージョンを保存するために、当然、バージョン管理システムがあります（場合によっては、このルールに1行または2行の修正が違反することがあります）。



質問、希望、提案はありますか？



PS空室がたくさんあります： undev.ru