「開発」ブランチがなくなる傾向
最近GitHubで人気のあるプロジェクトを調べているときに、developブランチがないことに気づきました。そして実際、 GitHubフローガイド でも言及されていません。私の理解から、masterは常に完全に安定していて、生産を反映している必要があります。開発者が機能ブランチで作業していて、完了時にそれらをmasterにマージする場合、機能/修正がmasterにマージされ、masterブランチが実際に本番環境よりも新しい期間があることを意味します。
チームがdevelopから機能/修正ブランチを作成し、そこにマージして、次のバージョンが完全にリリースできる状態になったら、developがmasterにマージされ、タグが作成されるのは、理にかなっていますか？人々がmasterに直接マージしていて、masterブランチのコードベースが大幅に変更されたために修正が困難になるバグが本番環境で報告されたとします。その後、開発者はユーザーに次のリリースまで問題が解決するのを待つように指示する必要があります。
編集：この質問は、「分岐するかしないか」とは異なります。それは特に、開発ブランチの使用をやめる人々とそれを取り巻く理由に対処しています。
[〜＃〜] ci [〜＃〜] 考え方から来ており、1日に数回統合されます。
両方の長所と短所があります。
私たちのチームでは、追加の利点はないがいくつかの欠点があると感じたため、開発ブランチも放棄しました。欠点を補うためにCIソフトウェア（Teamcity）を構成しました。
- 特定のコミットのデプロイを有効にします。つまり、ブランチはデプロイしません。コミットをデプロイします。
- Hotfix /プレフィックスで始まるマスターまたはブランチをデプロイできます。
これが機能する理由は、すべてのプル要求に潜在的に解放可能なコードが含まれているためですが、これはすべてのコミットをマスターにデプロイすることを意味するものではありません。
私たちが開発ブランチを放棄した主な理由は、実際に何が含まれているかを確認するには、大きくなりすぎて時間がかかりすぎる傾向があるためです。少し時期尚早に何かを展開した場合は、ホットフィックスブランチから分岐して、直接展開します。
リリースするプロセスが複雑で、深刻なリリース候補が必要な場合は、開発ブランチがさらに重要になります。
たとえば、自動車のファームウェアであるソフトウェアを書いているとしましょう。これは...修正するのは簡単ではなく、どのリリースでも実際のハードウェアで実行される非CI /統合テストの包括的なセットが含まれる可能性があります。
その場合、非マスターブランチ（「開発」など）の「リリース候補」を分離する方が理にかなっている可能性があります。これにより、これらのテストを実行しているチームは、機能をマージするブランチを持つことができます。
Webアプリやその他の簡単に更新できるソフトウェアには、この制約はありません。
ただし、次のことに注意してください。
- Github上の多くの（ほとんど？）プロジェクトにはこの種の制約がありません
- メインの「マスター」は同じ目的を果たします
- 「PR対マスターを作成する」というワークフローは、「このリポジトリですぐにわからないブランチに対してPRを作成する」よりもはるかに普遍的です。
プロジェクトで見た哲学は2つあり、選択は好みの問題だと思います。
「マスター」を製品リリースとして指定し、「開発」ブランチで開発します。
「マスター」で開発し、安定した製品リリースのために別の名前のブランチを用意します。これは、プロジェクトに一度に複数のリリースブランチがある場合にさらに意味があります（たとえば、現在の優先ブランチはリリース1.8ですが、リリース1.7も維持しています）。
どちらも一般的なアプローチであり、長所と短所があります。
プロダクションへのリリースにはタグを付けることができるので、リリースされた状況は、この目的のためにブランチ全体を費やすことなく常に再現できます。
マスターがリリースできない瞬間に本番環境で重大なバグが見つかった場合、タグをチェックアウトして、そこから新しい「hotfixes-for-release-1.2.0」ブランチを開始するのは簡単です。しかし、それはかなりまれなはずです。
ほとんどの場合、Webアプリケーションでは、マスターは前回のリリースから変更されていますが、それほど大きくは変更されていないため、修正されたマスターから新しいリリースを実行するだけで済みます。とにかく、非常に頻繁なリリースを行うのに役立ちます。
開発者が機能ブランチで作業していて、完了時にそれらをマスターにマージする場合、機能/修正が
masterとmasterブランチにマージされる期間があることを意味します実際には生産よりも新しいです。...
人々がマスターに直接マージしていて、マスターブランチのコードベースが大幅に変更されたために修正が困難になるバグが本番環境で報告されたとします。
それはGithub Flowではありません。
リンクによると、これはGithub Flowのデプロイ/マージプロセスです。
配置する
プルリクエストが確認され、ブランチがテストに合格したら、変更をデプロイして本番環境で検証できます。 ブランチで問題が発生した場合は、既存のマスターを本番環境にデプロイすることでロールバックできます。
マージ
変更が本番環境で検証されたので、コードをマスターブランチにマージします。
（エンファシス鉱山）
言い換えると、masterが本番環境よりも優先されることはありません。同様に、masterは常に安定した解放可能な状態になります（発見されていないバグを除く）。すべてがレビューされ、テストされて、本番環境にロールアウトされるため、beforemaster。
私が目にする問題は、Git/Hubフローのデプロイ/マージが、一度に1つの機能が開発/テスト/マージ/デプロイされることを想定していることです-私の経験では、多くの場合そうではありません。一度に機能をマージすると、回帰の問題が発生する可能性が高くなります-機能がマスターにマージされた後、おそらく本番環境でのみ発見されます。
複数の機能をテストし、複数の機能をマージして同じものをデプロイする方法が必要です。私は、qa/uatにデプロイされる「バンドルブランチ」（マスターから作成され、テスト準備機能ブランチがマージされたブランチ）を使用しています。 uat中の修正は機能ブランチでのみ発生し、それらはバンドルブランチに再度マージされます。バンドルブランチのサブセクションが承認されると、バンドル内で承認された機能のみがマスターにプルリクエストされ、サイクルは継続します。
私はこれをGitflowで使用していますが、GitHubフローで使用することを考えています。一度に多くのQA/UAT機能が重要であるように思われます。 GitHubフローのもう1つの問題は、すべてのsr開発者を想定していることであり、常にそうであるとは限りません。
単純化されているため、GitHubフローを使用します。バンドルのような機能があれば、準備が整っていると思います。バンドルがリリースに似ている可能性はありません。しかし、私はまだこれについても考えています。
もう1つの問題は、プルリクエストプロセスがマスターにマージする前に最後に発生することです。ただし、ビジネスqaテストの前にコードレビューを行う必要がある場合があるため、マージのかなり前