Gitのコミットハッシュとブランチ間のマージ
developおよびmasterとも呼ばれる、gitワークフローで2つのブランチを使用するシナリオがあります。
現在の流れは次のとおりです。
feat-branchを作成します-このブランチはmasterに基づいています。feat-branchで変更を加え、最後に変更をコミットして、リモートfeat-branchにアップストリームにプッシュします。- 最後に、最終的には（GitHub経由で）2つのプルリクエストを作成します。 1つは
develop <- feat branch、もう1つはmaster <- feat branchになります。
機能ブランチはすでにマスターブランチから分岐しているため、この方法は完全にマスターブランチにマージするために正常に機能します（古くなったときにgit pull Origin masterする必要があることは別として、これは予期されることです（私は個人的にも機能ブランチをリベースしたいです））。
ただし、最初にdevelopにプルリクエストを作成することになります（masterにマージするセカンダリプルリクエストを作成する前に）。
developブランチへのマージは、この時点で危険になります。各コントリビューターは、開発とマスターの両方に同じ正確なPRを効果的に作成し、同じ変更で各ブランチに異なるマージコミットハッシュを作成するためです。
ただし、誰もがマスターから分岐しているため、最終的にマスターになるマージコミットは、最終的には時間の経過とともに最終的に開発ブランチにマージされます...これにより、PRに誤った違いが表示され、基本的に同じ変更が行われていると言われます別の人が作った。
これは、プルリクエストがマスターにマージされた後に作成されるすべてのマージコミットが、開発ブランチのPRに含まれることになるため、コミットハッシュがどのように機能するかを組み合わせたものだと思います。
この時点では、2分岐モデルにまったく異なる方法でアプローチする場合でも、まったく異なる方法で解決する場合でも、解決に関する一般的な方向性やアイデアを探しているだけです。
私には、developブランチは実際には統合およびテスト（またはQA）ブランチのように説明から聞こえます。 masterブランチは、実際には本番（またはリリース）ブランチです。
その場合、機能ブランチはdevelopから分岐し、masterにマージするのはリリースマネージャーだけにしてください。これらのマージはdevelopからのみ行う必要がありますブランチ。
プライマリブランチとしてdevelopを使用するか、テストスイートを使用してプルリクエストをmasterにゲートします。
現在、動作中のテスト済みソフトウェアを表すためにmasterを使用しており、さまざまな機能ブランチを統合するためにdevelopを使用しています。
現在のプロセスはそれをうまく実行できません。機能ブランチを別々にdevelopとmasterにマージすると、2つのターゲットブランチがまったく同じ状態にならないというリスクがあります。さらに、Gitの仕組みにより、ブランチが分岐するにつれてマージはますます面倒になります。
これに対処する1つの方法は、機能をdevelopにのみマージすることです。準備ができたら、developの現在の状態をmasterにマージできます。これは実質的にNvie Git-Flowであり、そのすべての利点と欠点があります。 Git-Flowは、しばらくの間並行してサポートする必要がある大きくて頻繁ではないリリースのソフトウェアに適しています。
別のアプローチは、すべての機能を直接masterにマージすることです。これは非常に簡単で簡単ですが、変更によって何も壊されないようにする必要があります。masterは常に解放可能な状態にする必要があります。継続的インテグレーションを発明したのと同じ人々が、自動化されたテストにも力を注いでおり、2人は今や事実上同義語となっています。 GitHubはプルリクエストベースのパターンを普及させました。PRは手動によるレビューと自動テストの機会を提供します。
このようなPRベースのアプローチは、特にSaaSまたはWebコンテキストで）小さなリリースが頻繁にあり、リリースされたバージョンのバグの影響が少ない傾向がある場合に適しています。今後のリリースで修正される予定です（ホットフィックスなし！）。ただし、これには自動テストで高い信頼性を持つQAカルチャーが必要です。これは必ずしも100％の単体テストカバレッジを意味するわけではありませんが、重要な機能とリントの一部の統合テスト/潜在的な問題を見つけるための静的分析すでに高い収束がある場合は、「追加された行をテストでカバーする必要がある」などのチェックが役立ちます。
プルリクエストベースのアプローチでは、大きな機能がmasterから大きく分岐し、リリース可能な状態にないWIPの変更で問題が発生します。ただし、リファクタリングパターンと機能の切り替えを使用して、何も壊すことなく段階的な変更を行い、準備ができたときにのみ危険な機能を有効にすることができます。ただし、このような安全なパターンを守り、適切なテストを作成するには、ある程度の訓練と能力が必要です。