機能ブランチは常に開発からブランチする必要がありますか？
私はRails開発者であり、常にこの疑問を抱えていました。たとえば、ユーザーのコントローラとビュー（ブランチfeature/users-endpoint）のために何かを開発する必要があり、私が最終的に想像するとします。いくつかのヘルパー（ソーター、ページネーターなど）とコードを変調するための懸念を開発します。次に、管理者のコントローラーとビュー（ブランチfeature/admins-endpoint）を実行する必要があり、ヘルパーと懸念を使用したいとします。 feature/users-endpointで開発feature/users-endpointまたはdevelopから分岐する必要がありますか？
developから分岐する場合：
- 開発のためにマージするときに、より多くのマージの競合が発生する可能性があります（公開された例ではありませんが、他のケースでは、同じファイルを編集できました）。
feature/users-endpointの場合、より小さなプルリクエストが生成されます。
feature/users-endpointから分岐する場合：
- マージの競合が少ないかゼロ。
feature/users-endpointの場合、はるかに大きなプルリクエストが生成されます。
最初に-哲学的な質問。 feature/users-endpointブランチで開発を開始しました。ただし、そうする場合、高度にモジュール化されたコードを導入しました。多分あなたはこれが必要だと気づいたかもしれませんが、それはあなたが開発するのにより長い時間がかかるかもしれません。 DRYそれが繰り返される前にコードをアップしないことをお勧めしますか？ワークフローをより早くfeature/users-endpoint進行させることができましたか-プルリクエストレビュー用に開いたり、他の開発者が使用するdevelopブランチにマージしたり、ユーザーやユーザープロキシが対話してより迅速なフィードバックを取得できるようにテスト環境や本番環境にデプロイしたりしますか？
第二に-別の哲学的質問。 「完了」して「進行中の作業を制限する」とはどういう意味ですか？進行中の作業を制限することで品質が向上することはわかっています。これにより、コンテキストの切り替えが少ない特定の事柄へのフォーカスが向上し、品質が向上し、ワークフローを通過して次のワークフローにすばやく進む傾向があります。 1人で2つの機能ブランチを開いている必要がありますか？彼らの焦点と注意についてそれは何を意味しますか？
哲学的な議論はこれで十分だと思います。あなたがこの状況にいるとしましょう。職業はなんですか？
長所/短所を見ると、feature/users-endpointブランチから分岐する必要がほとんどあると思いますが、features/users-endpointブランチが最初にdevelopブランチにマージされていることを確認してください。これにより、マージの競合が減り（ワークロードが減り）、プルリクエストの大部分が減り（コードレビューアーのメンタルロードが減り、コードレビューが効果的になり）、feature/users-endpointの設計に関するフィードバックを得て、欠陥を見つけたり、リファクタリングを実行したりする場所（おそらくfeature/users-endpointブランチがマージされる前でも）。
ただし、最良のことは、2つのオープン機能ブランチを持たないことです。また、必要に応じて、それらを互いに依存しないようにし、両方をdevelopから分岐させます。
開発ブランチにマージするマージ競合はありません。どうして？マージの競合がある場合はマージしないためです。まずブランチに開発をマージし、次に競合なしでマージします。
別のブランチX（開発から分岐）から分岐する場合は、もちろんブランチXにマージして戻すことができます。開発へのマージはさらに難しい場合があります。
私がしていることときどきレビューにブランチXがあり、別の機能YがXでしたことを必要とする場合、私はXからブランチします-それらが両方とも知っているmyブランチ。 Xがマージされた後にのみ、Yをマージできます。レビュアーはプルリクエストの順序でレビューすることを知っているので、私はそれを行うことができます。自分がまだ作業している自分のブランチから、または他の誰かのブランチからブランチすることは絶対にありません。