非機能的な変更はどのようにコミットする必要がありますか？

私は中小規模のレガシーコードベースで作業しており、チケットで作業しているときに、クリーンアップが必要なコードや、アプリケーションのフォローを理解するためだけにクリーンアップが必要なコードに遭遇します。

実際の例は次のとおりです。

if( !a && b ){
     doSomething1();
     doSomething2();
     doSomething3();
     doSomething4();
     doSomething5();
}else if( a ){
     doSomething1();
     doSomething2();
     doSomething3();
     doSomething4();
     doSomething5();
}else if( !b && ( a || c )  ){
     doSomething1();
     doSomething2();
     doSomething3();
     doSomething4();
     doSomething5();
}

もう1つは、数十のソースファイルにわたってコメントとドキュメントのタイプミスとエングリッシュを修正することです。

しかし、多くの場合、このクリーンアップは主な問題とは無関係になり、クリーンアップをコミットするのがどのように最善かと思います。私の見方では、3つのオプションがあります。

1. 修正前：これは発生順になっているため、年代順に機能しますが、何かが壊れると修正が複雑になり、修正を本番環境と比較することが難しくなります。また、ノイズである追加のコミットが導入されます。
2. 修正あり：しかし、これにより、欠陥のあるコードをfindGeoragphyが正しいファイルで実際に置き換えることができなくなりfindGeographyます。
3. 修正後：これには、コードを理解し、修正を再テストし、修正をコミットしてから、元に戻ってクリーンアップをやり直すために行った削除とクリーンアップが必要です。これにより、欠陥のあるコードとの最も明確な相違が可能になりますが、作業が重複し、偽のコミットにつながる可能性もあります。

tl; dr：では、クリーンアップコードをコミットする最良の方法は何ですか？

コンテキスト：ユニットテストはありません。変更を実行し、それらを目立たせ、壁を越えてQAに送信し、手動の回帰修正によって検証することにより、開発を進めます。また、フォームのクリーンアップを行わないと、コードがわかりにくくなります。これは理想からかけ離れていることは知っていますが、これは私の選択ではなく、私の食卓に食物を載せる実際のエンタープライズ開発者です。

私はカールの答えと同様のプロセスに従います。いくつかの理由により、機能を変更する前に、クリーンアップ/リファクタリングを個別にコミットすることを好みます。

• 2つのコミットを分離することで、プロセスを説明し、ログを見る他の人によく考えることができます。
• コードのレビュー時に役立つ一連の変更を提供します。
• つまり、機能の変更をロールバックする場合でも、クリーンアップ/リファクタリングを維持します。
• クリーンアップの変更は、機能の更新前に個別にテストできます。

修正前の追加のコミットを好みます。これにより、実行している2つのタスクが明確に分離され、他の人がクリーンアップとバグ修正の違いを確認できます。また、クリーンアップは（少なくとも私にとっては）通常ははるかに高速であるため、クリーンアップ修正をコミットする場合、私が長い間作業しているときにマージが難しい変更を行うことについてそれほど心配する必要はありません。仕事。

私は、コミットごとに変更要求IDを必要とするポリシーのある場所で「修正を伴うコミット」アプローチを使用しており、開発者がクリーンアップコードのためだけに新しい変更要求を作成することを許可していません。はい、そのようなポリシーは非生産的ですが、そのような職場は存在します。

修正プログラムを既存のリリースにパッチする必要がある場合は、まず修正プログラムをチェックインし、その後でクリーンアップするか、修正プログラムを適用する必要がある人を（少なくともしばらくの間）作成する必要があります。何が変更されたかを理解するため、または実際の修正にパッチを適用する前に表面的な変更にパッチを適用するために、必要以上に熱心に作業する欠陥を修正するための最小限の変更は、何か悪いものをリリースするリスクを高める可能性があります）。

はい、これは余分な作業です。はい、それは苦痛です。しかし、はい、それは物事を行うための正しい方法です。私の通常のワークフローは、1つのサンドボックスですべてを実行し（クリーンアップと欠陥修正）、新しいサンドボックスを作成し、そこから最小限の欠陥修正の変更のみを適用し、この変更を元のサンドボックスでチェックアウトして、クリーンアップをチェックインします-アップコード。私の経験では、それほど多くの作業は必要ありません。