機能ブランチの作業中にコード品質を改善する必要があります

あなたが見つけたよりも良い状態にコード/キャンプサイトを残すことについてのこの記事が本当に好きです -コードの清潔さを維持するための現実の現実的なアプローチのようです。

また、機能を単独で開発する方法として機能ブランチが本当に好きなので、気に入らない場合は簡単にマージできないなどです。

ただし、機能ブランチで作業しているときにifいコードを見つけた場合、修正する必要がありますか？

それを修正するには多くの欠点があるように感じます：

• ブランチをマージして戻すと、diffが乱雑になり、変数名の変更や関数の抽出が乱雑になります
• 機能が放棄された場合、クリーンアップコミットをチェリーピック（近くのコードが変更されて乱雑なマージが行われた方法に応じて機能する場合と機能しない場合があります）、再実行、または単に放棄する必要があります。

反対に、ファイルにいるときに実行しないと、ブランチをマージする数日後に実行するのを忘れることになります。

私はこれが意見に基づいていると警告されました（タイトルに含まれている事実から外れていると思いますshould）が、答えがあると感じています（確かに人々は両方のアプローチを使用しているので答えが必要です）。また、についての質問development methodologiesは話題になっており、ある程度の意見が必要だと思います。

機能の一部としてコードの一部を変更する場合は、機能ブランチのコードを「修正」するだけです。

例えば。「ウサギの印刷」機能に取り組んでいますが、プリンターコードを見つけました

Public class Printer(string type)
{
    If(type=="bunnies")
    {
        //print a bunny
    }
.....
}

私はそれを次のように変更します：

Public class Printer(string type)
{
     PrintFunctionDictionary[type].Print();
}

なぜ：

• 私はコードに取り組んでいます、
• 機能を追加するには変更する必要がありますが、
• 追加された機能は、問題に取り組むためのリファクタリングされた方法を示唆しています。

コードベースの他の部分をランダムにヒットして、これを改善することはできません。

• 他の機能に取り組んでいる人々と衝突します。
• 機能の開発に割り当てる時間を使用します。
• 機能が終了していない場合、メイン製品にマージされない可能性があるブランチに任意のコードを追加します。同様に、機能をロールバックすると、リファクタリングが失われます。

現在の機能ブランチからリファクタリングを「独立して」実行したい場合は、そこで変更を加えないでください。代わりに、メインの開発ブランチでリファクタリングを実行します（または、開発ブランチに直接変更を適用しないことがチームで一般的な場合は「リファクタリングブランチ」）。そのため、チームの誰も（あなたを含む）、変更を作業中のアクティブな機能ブランチにマージできます。ただし、最初に同僚に許可を求めることなく、「コードベースの半分」全体にグローバルリファクタリングを適用しないように注意してください。

ここでの例外は、あなたが行う改善が、その機能ブランチで正確に触れるコードベースの部分に限定されている場合であり、「新しい機能」とは異なるライフサイクルを与えることは意味がありません。

branch型の目的は、型を処理する意図を提供することです。タイプが好きなあなたは分岐のGitFlowスタイルを以下している場合、あなたはおそらく持っているfeature、hotfix、release、など。機能ブランチの場合には、その意図は別のブランチ（すなわちへのマージをカプセル化することであるdevelop）のためにすることを示している開発者責任マージ、この機能は何ですか。クリーンアップするコードがその機能の一部でない場合は、変更しないでください。

代わりに、いコードがdevelop存在する可能性が最も低いブランチを見つけ（おそらく）、そこからブランチします。コードを変更し、機能としてマージすることを提案します。作業中にそのコードが必要で、特にマージの競合を避けたい場合は、そのブランチをYOURブランチにマージします。

さまざまな戦略のかなり良い説明があります：https : //www.atlassian.com/git/tutorials/comparing-workflows/

機能ブランチで作業していて、andいコードを見つけた場合、修正する必要がありますか？

プロジェクトのテンポ、コードの「ugさ」などに応じて、「見苦しいコード」を一目で修正することはおそらく問題ありませんが、機能ブランチ自体ではこれを行わないようにしてください。

• 機能ブランチが完全にローカルである場合、未保存の変更をスタッシュまたはコミットするだけで、開発ブランチをチェックアウトし、変更を加えてから機能ブランチに戻り、developをリベースします。
• 開発版をリベースできない場合（たとえば、機能ブランチがパブリックサーバー上にある場合）、必要に応じて、または後で競合を回避したい場合は、開発機をコミットすることができます。
• ファイルを編集していて、実際に修正をtheいコードにコミットする必要があり、実際に開発に切り替えることができない場合は、修正を行い、修正に使用git add -pし、その変更のみをコミットし、マージ/プッシュ（実際には、できれば次のコミット後）、対話型リベースを使用して、コミットをブランチ内の可能な限り早期のポイントに移動するか、履歴に応じて開発にチェリーピックします。

また、開発ブランチを「修正」している他のすべてのものでこれを行います（「修正」とは、コードが標準に準拠していることを確認するためにあなたや他の開発者が目にする変更のことです）。これは役立ちます...

• ログを読みやすくするために、修正と機能のコミットを異なるグループに保持するため、
• 開発を可能な限りいつでもリリース可能な状態に近づけること
• 作業の重複を避けるため（複数の人が同じ問題を異なるブランチで微妙に異なる方法で修正する）。