GitHub FlowとGitLab Flowの違いは何ですか？
最近、GITのワークフローの3つの概念、GitFlow、GitHub Flow、GitLab Flowを見つけました。私はそれについての素敵な記事を読みました（ https://docs.gitlab.com/ee/workflow/gitlab_flow.html ）が、GitLab Flowについてはあまりよくわかりません。たぶん私はネイティブスピーカーではないからです:)
手短に。
GitFlow（ https://docs.gitlab.com/ee/workflow/gitdashflow.png ）。
運用ブランチとしてマスターブランチがあります。また、すべての開発者が自分の機能をマージする開発ブランチがあります。リリースブランチを作成して、本番環境に機能を展開する場合があります。リリースブランチにバグがある場合、それを修正して開発ブランチに変更をプルします。本番環境に重大なバグがある場合は、新しいホットフィックスブランチを作成し、バグを修正し、ブランチを本番環境（マスター）にマージし、ブランチを開発します。
作業の結果をめったに表示しない場合、このアプローチは非常に適切です。 （2週間に1回程度）。
GitHub Flow（ https://docs.gitlab.com/ee/workflow/github_flow.png ）。
運用ブランチとしてマスターブランチがあります。そして、（開発者として）新しい機能を追加したりバグを修正したりするためのブランチを作成し、それらを本番（マスター）ブランチとマージすることしかできません。とても簡単に聞こえます。このアプローチは、実稼働ブランチが1日に数回展開される極端なプログラミングに適しています。
GitLab Flow（ https://docs.gitlab.com/ee/workflow/production_branch.png 、 https://docs.gitlab.com /ee/workflow/environment_branches.png 、 https://docs.gitlab.com/ee/workflow/release_branches.png ）。
運用前、運用、リリース（安定）ブランチ、ステージング環境、運用前環境、運用環境などの新しい用語を見てきました。彼らはどのような関係を持っていますか？
そのように理解しています。新しい機能を追加する必要がある場合は、マスターブランチから運用前ブランチを展開します。この機能が終了したら、運用前ブランチから運用ブランチを展開します。運用前ブランチは中間段階です。そして、マスターブランチはすべての変更を本番ブランチからプルします。
個別の機能を確認したい場合は、このアプローチが適しています。ブランチで必要なものをチェックアウトするだけです。
ただし、作業を表示する必要がある場合は、タグを含むリリースブランチをできるだけ遅く作成します。後でmasterブランチのバグを修正する場合、最後のリリースブランチにそれらをチェリーピックする必要があります。最後に、バージョン間を移動するのに役立つタグを含むリリースブランチがあります。
私のビジョンは正しいですか？プルとチェリーピックの違いは何ですか？
GitLab Flowは、masterおよびfeatureブランチも使用することを提案しています。機能が完成したら、それをmasterブランチにマージして戻します。この部分はGitHub Flowと同じように見えます。
それから、私の理解では、SAASアプリかモバイルアプリ（世界にリリースできる）かによって、2つの選択肢があります。
これがSAASアプリの場合、環境ブランチを使用します。 pre-productionおよびproduction。これらのブランチは、アプリケーションをデプロイする準備ができたときにmasterから作成されます。環境ごとに異なるブランチを持つことで、CI/CDツールをセットアップして、これらのブランチへのコミット時に自動的に展開できます。重大な問題がある場合は、featureまたはmasterブランチで修正してから、environmentブランチにマージします。
世界にリリースできるアプリケーション（モバイルアプリやデスクトップアプリなど）に関しては、環境ブランチの代わりにreleaseブランチを使用することで異なるモデルを使用することを提案していると理解しています。 featureブランチですべての作業を実行し、完了時にそれらをマージしてmasterブランチに戻します。次に、masterブランチが十分に安定していることを確認したら、つまり、すべてのテストとバグ修正を既に実行したので、releaseブランチを作成してソフトウェアをリリースします。重大な問題がある場合は、最初にmasterブランチで修正し、releaseブランチの修正をチェリーピックします。
この投稿が提起されてから1年が経ちましたが、将来の読者と事実が少し変わったということを考えると、リフレッシュする価値があると思います。
GitHub Flow2011年にスコット・チャコンによって最初に描かれたように は、feature branchおよびmasterにマージされたものは、すぐに実稼働にデプロイする必要があります。これは当時は機能し、唯一のGitHub Flowルールに準拠していましたが、これはmasterブランチ内のすべてがデプロイ可能、 ですぐに発見されましたmasterを既知の稼働中の生産コードの真の記録を保持するために、生産への実際の展開はfeature branchから行われるべきですbeforemasterにマージします。 feature branchからデプロイすると、masterをデプロイすることで問題の生産を即座に元に戻すことができるため、完全に理にかなっています。 GitHub Flowの簡単な視覚的紹介 をご覧ください。
GitLab Flowは、一連の ガイドラインとベストプラクティス を伴うGitHub Flowの一種の拡張機能ですプロセスをさらに標準化することを目指します。すぐにデプロイできるmasterブランチと機能ブランチ（GitHub Flowと同じ）を促進する以外に、他の3種類のブランチを導入します。
Productionbranch- 環境ブランチ ：
uat、pre-production、production - リリースブランチ ：
1-5-stable、1-6-stable
上記の名前と例は自己記述的であると考えているため、これ以上詳しく説明しません。