私は自分や他の人のコードを常にリファクタリングしています。トランクではなくブランチで作業している場合、特に定期的にトランクにマージしない場合は、非常に面倒なマージが発生することがあります（ブランチのコードはトランクからゆっくりとシフトし、人々がトランクを変更するとIこれをブランチに適用する方法を手動で理解する必要があります）。
私が知っている解決策はどちらかです
職業はなんですか？
大規模なリファクタリングは、開発タイムラインの適切なタイミングで実行する必要があります。リリースの近くで大量のリファクタリングを行うと、変更を最小限に抑える必要があるときに面倒なマージを導入するため、自分自身を傷つけることになります。リファクタリングが混乱するほど、開発サイクルの早い段階で発生するはずです（また、影響を受けるファイルの編集を一定期間停止するなど、より特別なプロセスが必要になります）。
トランクとの間で絶えずマージすることは、一般的に良い習慣です。
その場合、なぜブランチで働くのですか？より詳細に制御できるため（たとえば、開発ブランチへのチェックインを停止せずに、トランクへのマージを停止して、リリースのためにトランクを安定させることができます）。開発ブランチへのチェックイン速度に大きな影響を与えることなく、トランクへのマージとトランクからのマージの周りに高レベルの検証を配置できるためです。
私は1を使用し、可能な場合は小さな変更を加えて頻繁にチェックインします。そうしないと、マージが面倒になります。別のブランチを使用すると、同時に他の作業を行う必要がある場合や、リファクタリングに当初考えていたよりも時間がかかる場合に、作業が簡単になります。もう1つの利点は、複数の人がリファクタリングに参加しやすくなり、ブランチに何度でもチェックインできることです。
リリース間の時間枠が少なくとも 2 か月あるシナリオでは、次の戦略をお勧めします。
リリースが近づき始めたら、リリース ブランチを作成します。リリース ブランチは、ここではリファクタリングなしとして扱われるべきであり、私は (ほぼ) 機能が完全なブランチです。この時点で、リリース ブランチでのリリースの安定化に注力する必要があります。必要に応じて、リリース ブランチからトランクに不具合修正をマージします。その間、トランクはリファクタリングのために永久に開いているものとして扱われます。また、可能であれば、メジャー リリースに近づくにつれてリファクタリングを減らし、その直後に加速するようにしてください。
継続的なリリース戦略 (つまり、1 ～ 2 週間ごとのリリース) に従っている場合は、大規模な外科的機能強化を行う場合を除き、リファクタリングとコーディングを別々のブランチに分けるべきではありません。このような外科的強化の状況 (それぞれ 3 か月以上の間隔をあける必要があります) では、マージを実行する予定があるときはいつでも事前にスケジュールからリリースを削除し、リリースのマージとテストの増加にサイクルの 1 つを使用し、指を交差させて離します。
変更は迅速に行う必要があります(そのため、あまり多くの変更を加えないでください) か、ローカルで行う必要があります (したがって、少数の場所での変更のみを気にする必要があります)。
そうしないと、マージはリファクタリングと同じくらいの作業になる可能性があります。アルゴリズムとして、楽観的ロックは、あまりにも多くのトランザクションが失敗し、再起動する必要がある場合には機能しません。
基本的に、企業内の 20 人のプログラマー全員がコード ベースのメソッドの 50% の名前を毎日変更するような状況は許されません。さらに言えば、複数の人が常に同じ場所で同時にリファクタリングしている場合、とにかくお互いの作業を元に戻すだけです。
プログラマーが手動でマージを監視するのに多くの時間を費やしている場合は、タスクの定義と割り当ての方法を変更して生産性を向上させる機会をマネージャーに提示してください。
また、「どこでも工場を使用するようにシステム全体をリファクタリングする」ことはタスクではありません。「ファクトリを使用するために、この 1 つのインターフェイスとその実装をリファクタリングする」ことがタスクです。
早期にコミットし、頻繁にコミットします。
または、この場合... 早めにマージし、頻繁にマージします。
これは、優れた分散型 VCS が優れているところです。しかし、あなたはすでに SVN に取り組んでいると思います。
個人的には、競合地獄を避けるために、リファクタリングを行ってからできるだけ早くマージするだけです。これは最も生産的な方法ではありませんが、エラーが発生しにくい方法です。
機能が「保留」され、マージが不可能だったため、約 3 週間休眠していたブランチがありました。特定の部分の参照として古いブランチを使用して、新しいブランチで機能をやり直しました。
明らかであるというリスクを冒して、分岐を完全に避けるようにしてください。これが引き起こすオーバーヘッドの量を過小評価してはなりません。これ以上延期できないと考えている場合でも (本番環境でシステムの 1 つをリリースし、2 つをリリースし、1 つをリリースするように要求を変更します)、別の方法を見つけようとします: 分岐せずに機能を分離する方法は本当にありませんか? (たとえば、「共通」プロジェクトといくつかのサブプロジェクトを分割します)? すべてのコードを統合する方法は本当にないのでしょうか (たとえば、相違点を組み込んだ Strategy クラスを作成したり、新しい機能をオンまたはオフにするスイッチを作成したりします)。
どうしても分岐する必要がある場合は、オプション 1 を使用します。可能な限り小さな変更をマージし、頻繁に行うようにしてください。
継続的インテグレーションが鍵です... 一度に 1 つの小さなバッチの変更...