心を失わずにブランチでリファクタリングするにはどうすればよいでしょうか?

Question

自分と他の人のコードをリファクタリングする いつも。トランクではなくブランチで作業している場合、特に定期的にトランクにマージし直さない場合には、非常に苦痛なマージが発生することがあります (ブランチのコードは徐々にトランクから離れていき、人々がトランクを変更すると、これをブランチに適用する方法を手動で理解する必要があります)。

私が知っている解決策は次のいずれかです

1. トランクとの間で常にマージを行う - 面倒なマージが軽減されますが、そもそもなぜブランチで作業する必要があるのでしょうか?
2. 何かをリファクタリングする必要があるときは、トランクに切り替えて、そこでリファクタリングを実行してブランチにマージします。リファクタリングごとに環境を切り替える実際のコストは膨大であるため、これはあまり現実的ではないと思います。

職業はなんですか？

Answer 1

大規模なリファクタリングは、開発タイムラインの適切なタイミングで実行する必要があります。リリース間近に大量のリファクタリングを行うと、変更を最小限に抑えるべきときに苦痛を伴うマージを導入することになるため、最終的には自分自身を傷つけることになります。リファクタリングがより破壊的であればあるほど、それは開発サイクルの早い段階で実行されるべきです（そして、そのためのより特別なプロセスが必要です。影響を受けるファイルへの編集を一定期間できるだけ停止します)。

通常、トランクとの間で常にマージを行うことは良い習慣です。

それならなぜ支店で働く必要があるのでしょうか?より詳細な制御ができるからです (たとえば、開発ブランチへのチェックインを停止せずに、リリースに向けてトランクを安定させるためにトランクへのマージを停止できます)。開発ブランチへのチェックイン速度に大きな影響を与えることなく、トランクとのマージに高レベルの検証を配置できるためです。

Answer 2

私は 1 を選択し、可能であれば小さな変更を加え、頻繁にチェックインします。そうしないと、マージが困難になります。別のブランチがあると、他の作業を同時に行う必要がある場合や、リファクタリングに当初の予想より時間がかかる場合に作業が容易になります。もう 1 つの利点は、複数人がリファクタリングに参加しやすくなり、好きなだけブランチにチェックインできることです。

Answer 3

リリース間の期間が少なくとも 2 か月あるシナリオには、次の戦略をお勧めします。

リリースが近づき始めたら、リリース ブランチを作成します。リリースブランチは次のように扱う必要があります。 ここではリファクタリングはしないでください そして 機能は（ほぼ）完成しました 支店。この時点で、リリースの安定化に注力し始める必要があります。 リリースブランチ上で. 。必要に応じて、リリース ブランチからトランクに欠陥修正をマージバックします。一方、トランクは次のように扱われます。 リファクタリングのために永久にオープン. 。また、可能であれば、メジャー リリースに近づくにつれてリファクタリングを減らし、リリース直後の数日間はリファクタリングを加速するようにしてください。

継続的なリリース戦略に従っている場合 (例:リリースは 1 ～ 2 週間ごと)、大規模な外科的機能強化を行う場合を除き、リファクタリングとコーディングを別のブランチに分離すべきではありません。このような外科的強化の状況 (それぞれ 3 か月以上の間隔を空ける必要がある) では、マージを実行する予定がある場合は常に事前にスケジュールからリリースを削除し、リリース マージとテストの増加にいずれかのサイクルを使用し、指を交差させてから放します。

Answer 4

変更は次のいずれかである必要があります 素早い （つまり、あなたの下ではそれほど大きな変化はありません）またはそうでない場合 地元 (したがって、少数の場所の変更のみを考慮する必要があります)。

それ以外の場合、マージはリファクタリングと同じくらい多くの作業が必要になる可能性があります。アルゴリズムとしては、あまりにも多くのトランザクションが失敗し、再起動する必要がある場合、オプティミスティック ロックは機能しません。

基本的に、社内の 20 人のプログラマ全員がコード ベース内のメソッドの 50% の名前を毎日変更するという状況は許されません。さらに言えば、複数の人が常に同じ場所で同時にリファクタリングを行っている場合、いずれにしてもお互いの作業を取り消しているだけです。

プログラマーが手動でマージを監視することに多くの時間を費やしている場合は、タスクの定義と割り当ての方法を変更して生産性を向上させる機会をマネージャーに提示してください。

また、「どこでもファクトリーを使用できるようにシステム全体をリファクタリングする」ことはタスクではありません。「この 1 つのインターフェイスとその実装をファクトリを使用するようにリファクタリングする」というタスクです。

Answer 5

これは、優れた分散型 VCS が優れている点です。しかし、あなたはすでに SVN に取り組んでいると思います。

個人的には、競合地獄を避けるために、リファクタリングを行ってからできるだけ早くマージします。これは最も生産性の高い方法ではありませんが、最もエラーが発生しにくい方法です。

以前、機能が「保留」されてマージできなかったために、ブランチが約 3 週間休止状態になっていたことがありました。特定の部分については古いブランチを参照として使用し、新しいブランチで機能を再度開始しました。

Answer 6

明らかになる危険を承知で、分岐を完全に避けるようにしてください。これによって生じるオーバーヘッドの量を過小評価してはなりません。これ以上延期できないと思った場合でも (運用中のシステムの 1 つをリリースし、2 つを構築中だが、1 つをリリースするようにリクエストを変更する)、別の方法を探してみてください。分岐せずに機能を分離する方法は本当にないのでしょうか (例:「共通」プロジェクトといくつかのサブプロジェクトを分割しますか？すべてのコードをヘッドに統合する方法は本当にないのでしょうか (例:違いを組み込んだ Strategy クラスを作成するか、新しい機能をオンまたはオフにするスイッチを作成しますか)。

どうしても分岐する必要がある場合は、オプション 1 を選択します。できるだけ小さな変更をマージし、頻繁にマージするようにしてください。

Answer 7

早めにコミットし、頻繁にコミットします。

それともこの場合...マージは早めに、頻繁に行ってください。

Answer 8

継続的インテグレーションが鍵です...一度に 1 つの小さなバッチの変更...