web-dev-qa-db-ja.com

機能ブランチで作業しながらコードの品質を向上させるべきか

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

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

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

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

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

逆に言えば、ファイル内にいるときに実行しなかった場合、ブランチをマージする数日後に実行することを忘れてしまいます。

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

refactoringcode-qualitybranching
11
T. Kiley

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

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

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

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

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

なぜ：

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

私はランダムにコードベースの他の部分にぶつかって、これを「より良くする」ことはしません：

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

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

例外は、ここで行うのは、コードブランチの機能ブランチで正確に触れた部分にローカルな改善があり、それらに「新機能」とは異なるライフサイクルを与えることは意味がないということです。

5
Doc Brown

branchタイプの目的は、それらを処理するための意図を提供することです。 GitFlowスタイルの分岐を使用している場合は、feature、hotfix、releaseなどのタイプが存在する可能性があります。機能ブランチの場合は、 intentionは、この機能が何であるか、マージを担当する開発者を示す別のブランチ（つまりdevelop）へのマージをカプセル化することです。クリーンアップするコードがその機能の一部ではない場合は、変更しないでください。

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

これは、さまざまな戦略のかなり良い説明です： https://www.atlassian.com/git/tutorials/comparing-workflows/

3
TomSchober

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

プロジェクトのテンポやコードの「醜さ」などによっては、「醜いコード」を一目で修正しても問題ないかもしれませんが、機能ブランチ自体ではこれを行わないようにしてください。

  • 機能ブランチが完全にローカルである場合は、保存されていない変更を隠しておくかコミットするだけです。開発ブランチをチェックアウトして変更を加えてから、機能ブランチに戻って、開発のベースを変更します。
  • 開発をリベースできない場合（たとえば、機能ブランチがパブリックサーバー上にある場合）、必要に応じて、または後で競合を回避したい場合は、開発をオフにすることができます。
  • ファイルを編集していて、really修正を今すぐ醜いコードにコミットする必要があり、reallyが開発に切り替えられない場合は、修正を行うことができ、git add -pを使用できます修正を行うには、その変更をコミットしますonlyで、マージ/プッシュする前に（実際、できれば次のコミットの後で）、インタラクティブなリベースを使用して、そのコミットをブランチの最も早いポイントに移動します。おそらく、あなたの歴史にもよりますが、開発にチェリーピックすることさえできます。

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

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