51

約 500,000 行のコードを含むプロジェクトがあり、git で管理されており、その多くは数年前のものです。命名規則、例外処理、インデントなどに関して、開発者コミュニティの現在の標準とベスト プラクティスに古いコードを準拠させるために、一連の変更を加えようとしています。

きれいな印刷と低レベル/機械的リファクタリングの間の何かと考えることができます。

このプロセスは、コード ベース内のコードのほぼすべての行 (~85%) に影響を与える可能性があり、一部の行は 5 つもの変更を受ける可能性があります。すべての変更は、意味的にニュートラルであることを意図しています。

  • 1 か月後にコードを見ると、インデントや大文字化が変更されたコミットではなく、ロジックが導入されたコミットが表示されるように、変更を git Blame などに対して透過的にする方法はありますか?
  • このプロセスを経ていないフォークからマージをプルする最良の方法は何ですか? 私の現在の計画は、フォークされたレポをスクリプトで複製し、自動化されたプロセスをそれとそのベースに適用し、それらを比較してから、比較を適用することです。しかし、私はより明確な答えが欲しいです。
  • 私が見ていないこの種の問題は他にありますか? もしそうなら、それらを軽減するために何ができますか? 私は、git bisect などは問題ないと考えています。git log などは、気をつけていないと大きな分断を横切るのは面倒ですし、git diff は絶望的です。痛点。

    • 4

    4 に答える 4

    27

    あなたが説明しているより侵襲的な変更のいくつかに対処する最善の方法はわかりませんが...

    、 、およびその他への-wオプションにより、 git は空白の変更を無視するため、実際の違いをより簡単に確認できます。git blamegit diff

    于 2009-12-01T06:57:52.863 に答える
    13

    これらの進化を、中央の Git リポジトリ (「他のすべてのリポジトリが従うための公開参照」のように中央) で、一度に 1 ステップずつ行うことをお勧めします。

    • インデント
    • メソッドの並べ替え
    • その後、名前を変更します
    • それから ...

    しかし、「インデント-並べ替え-名前変更-...-1 つの巨大なコミット」ではありません。

    そうすれば、リファクタリングの変更全体で変更を追跡する妥当な機会を Git に与えることができます。

    さらに、コードをプッシュする前に同じリファクタリングを適用していない新しいマージ (他のリポジトリからプルされたもの) は受け入れません。
    フォーマット プロセスを適用すると、取得したコードが変更される場合は、それを拒否して、最初にリモート リポジトリが新しい標準に準拠するように要求できます (少なくとも、プッシュを行う前にリポジトリからプルすることによって)。

    于 2009-12-01T07:14:45.340 に答える
    10

    空白を積極的に無視できるマージツールも必要です。p4merge はこれを行い、自由にダウンロードできます。

    于 2009-12-01T09:34:13.380 に答える