4 に答える
機能ブランチは確かにリファクタリングをはるかに難しくします。また、テスト済みのビルドが必要な並列開発ストリームの数が急増しているため、継続的インテグレーションやデプロイなどが困難になります。また、「継続的インテグレーション」の中心的な信条を取り除きます。つまり、全員が同じコードベースで作業し、変更をチームの他の変更と「継続的に」統合します。通常、機能ブランチが使用されている場合、機能ブランチは継続的にビルドまたはテストされないため、「機能ブランチ」コードが本番ビルド/テスト/デプロイプロセスで初めて実行されるのは、「完了」してマージされたときです。トランクに。これにより、開発プロセスの後半の重要な段階で多くの問題が発生する可能性があります。
私は、（ほぼ）すべてのコストで機能ブランチを避けるべきであるという物議を醸す意見を持っています。マージのコストは非常に高く、（おそらくもっと重要なことですが）共有コードベースへの「継続的インテグレーション」に失敗する機会費用はさらに高くなります。
あなたのシナリオでは、クライアントの機能ごとに個別の機能ブランチが必要ですか？代わりに、トランクでこれらの機能を開発し、準備ができるまで無効のままにしておくことはできますか？一般に、この方法で「機能」を開発する方が良いと思います。本番環境に対応していない場合でもトランクにチェックインし、準備が整うまでアプリケーションから除外します。この方法では、コンポーネントを適切にファクタリングし、適切に設計されたインターフェイスの背後でシールドすることも推奨されます。「機能ブランチ」アプローチは、新しい機能を実装するためにコードベース全体で抜本的な変更を加えるための言い訳を提供します。
私はこの挑発的な論文（「リファクタリングをあきらめる」）が好きです。なぜなら、それは議論を豊かにするからです:)
並列コードラインが多数ある場合は、リファクタリングを大きくする場合は十分に注意する必要があることに同意します。競合により、統合作業が大幅に増加し、マージ中にリグレッションバグが発生する可能性があるためです。
これにはリファクタリングと機能ブランチの問題があるため、多くのトレードオフがあります。したがって、私はケースバイケースで決定します：
- 機能ブランチでは、機能を実装しやすくする準備ができている場合にのみリファクタリングを行います。私は常に機能だけに焦点を合わせようとします。ブランチは、少なくともトランク/メインラインとは異なる必要があります。
- 逆にすると、リファクタリングブランチがあり、より大きなリファクタリングを行うこともあります（複数のステップを元に戻すのは非常に簡単で、トランクの同僚の気を散らすことはありません）。もちろん、私はこのリファクタリングを行っていることをチームに伝え、クリーンアップ開発サイクル中にそれを行うことを計画しようとしています（必要に応じてスプリントと呼びます）。
- あなたが言及した政治が重要であるならば、私はリファクタリングの努力を内部的にカプセル化し、それを見積もりに追加します。私の見解では、中期的な顧客は、コード品質が向上すると、より迅速な進歩が見られます。おそらくリファクタリングを理解しないでしょう（これは彼らの範囲外なので、それは理にかなっています...）、それで私はこれを彼らから隠します
- 私が絶対にやらないことは、安定性を目標とするリリースブランチをリファクタリングすることです。そこではバグ修正のみが許可されています。
要約すると、コードラインに応じてリファクタリングを計画します。
- 機能ブランチ：小さいものだけ（私の機能を「助ける」場合）
- リファクタリングブランチ：リファクタリングのターゲットが完全に明確ではない、より大きなものの場合（私はしばしばそれらを「落書きリファクタリング」と呼びます）
- トランク/メインライン：OKですが、統合の悪夢を作らないように、機能ブランチで開発者と通信する必要があります。
- リリースブランチ：これまでにない
リファクタリングとマージは、PlasticSCMが焦点を当てている2つの結合されたトピックです。実際、焦点を当てるべき2つの重要な領域があります。1つは、ブランチ上で移動または名前変更されたファイルを（マージ中に）処理することです。ここでの朗報は、すべての「ニューエイジ」SCMで正しく実行できるようになり（Plastic、Git、Hg）、古いSCMでは失敗するだけです（SVN、Perforce、さらに古いもの）。
他の部分は、同じファイル内のリファクタリングされたコードを処理することです。ご存知のとおり、コードを移動し、他の開発者が並行してコードを変更します。これは難しい問題ですが、新しいマージ/差分ツールセットでも焦点を当てています。ここでxdiff情報を見つけ、ここでxmerge（クロスマージ）を見つけます。ここで移動したコードを見つける方法についての良い議論（「比較を超えて」と比較して）。
「ディレクトリのマージ」または構造のマージの問題はコアの問題ですが（システムがそれを行うかどうかに関係なく）、2番目の問題はツールの問題です（3方向のマージおよび差分ツールがどれほど優れているか）。最初の問題を解決するためにGitとHgを無料で使用できます（Plastic SCMも無料になりました）。
問題の一部は、ほとんどのマージツールが愚かすぎてリファクタリングを理解できないことです。メソッドの単純な名前変更は、101行のコードの編集としてではなく、メソッドの名前変更としてマージする必要があります。したがって、たとえば、葯ブランチのメソッドへの追加の呼び出しは自動的に処理される必要があります。
言語解析に基づいて、移動および変更されたコードを処理するように設計された、より優れたマージツール（ SemanticMergeなど）がいくつかあります。JetBrains（ReShaperの作成）がこれについてブログを投稿しました。
これについては何年にもわたって多くの研究が行われ、ついにいくつかの製品が市場に出てきています。