DVCSトランクベースの開発でのまれな同期は、GitFlowの長期間有効な機能ブランチに似ていますか？
私はプロジェクトに取り組んでおり、トランクベースの開発のバリエーションとgitフローのような機能の分岐との違いとトレードオフを理解して、チームに適切なソリューションを実装できるようにしています。
以下のGitFlowの最初の図も、トランクベースの開発を表していますか？ TBDの実行方法（2番目のイメージ）ではなく、2人の開発者がマスターのローカルコピーで作業していて、リモートマスターとのマージ/プッシュを頻繁に行わない場合はどうなるでしょうか。
TBDの主な利点が、トランクと頻繁に統合することで解決することが難しい意味的およびテキストのマージの競合を回避することである場合、マージの頻度が減少するにつれて、これらの利点が減少することがわかります。
私が探しているトランクベースの開発のイメージのほとんどには、短命の機能ブランチへの参照が含まれていますが、マスターに直接コミットすることがどのようになるかをよりよく理解したいと思います。
https://martinfowler.com/bliki/FeatureBranch.html からの画像
DVCSでのトランクベースの開発は、基本的に機能ブランチの開発と同じであり、マージされていない変更が（リモート機能ブランチまたはトランクのローカルコピーに）保存される場所が異なるという参照を見つけました。したがって、これが当てはまる場合、私の質問に対する答えは「はい」になります。これは、ローカルトランクコピーまたはリモートブランチのいずれかでのまれなマージが長期間有効なブランチになるためです。
https://devops.com/feature-branching-vs-feature-flags-whats-right-tool-job/
誰もがGitFlowが何であるかを知っており、GitFlowには、機能ブランチを長持ちさせる必要があると言っているものはありません。
しかし、トランクベースの開発は比較的定義されていません。
あらゆる形式の共同開発の問題は、1つのことに取り組んでいる2人が、すべてを機能させたい場合は、互いの変更を考慮に入れる必要があることです。
つまり、自分で作業を長く続けるほど、他の人の変更にマージするときに問題が発生します。
この問題を解決するために、GitFlowなどの分岐ソリューションが開発されました。彼らはあなたがあなたのものに取り組み、「大きなマージ」の問題を最小限に抑えるために時間の経過とともに他の変更のマージを管理することを可能にします。
率直に言って、 https://trunkbaseddevelopment.com/ によって提示されたトランクベースの開発アプローチは、要約すると「より小さな機能ブランチを作成する」ということです。
これは、任意の分岐モデルで実行できます。それらの図の主な違いは、開発ブランチがないことです。しかし、リリースブランチが存在し、GitFlowでマスターに関する作業が一般的に不足していることを考えると、これが実際的な違いになることはないと思います。
「より小さな機能ブランチ」は良い目標ですが、ブランチモデルの目的は、それらを避けられないときにあなたを助けることです！ TBDは、実際の現実の問題をどのように解決するかについて明確ではありません
未定を見る人々の主な理由は、グーグルが彼らがそれをすると言ったということです。しかし、彼らが実際に言ったことを詳しく調べると、彼らがしていることは「ブランチのないgitを使用する」と実際には比較できないと私は信じています。
彼らはPERFORCEから始めました。
PERFORCEを使用したことがある場合は、それがVisual SourceControlの1つ上のステップであることがわかります。 perforceのブランチはgitのブランチとは異なります
彼らは今、カスタムソース管理システムを持っています
したがって、リポジトリ、ブランチ、コミットなどの用語は、gitと同じ意味ではありません
彼らには25000人の開発者がいて、毎日16000のコミットを行っています。
これは、単一のリポジトリとしては非常に高い数値です。しかし、開発者あたりの数は非常に少ないです。今日は少なくとも20回のコミットを行いましたが、それは（非常に）遅いものでした。
すべてのコミットはコードレビューを通過します
では、ここで詳細を説明します。基本的にこれらのコミットは、コミットというより機能ブランチのマージに似ています。各開発者は「ローカルコピー」（機能ブランチ）に取り組み、完了したらレビューとマージのために提出されます
したがって、答えられていないように見える大きな質問は次のとおりです。
- 1時間あたり666回のコミットがあり、コードがコミットされるまで1.5日かかる場合。私がコーディングを始めてから起こった他の開発者からの23976のコミットとどのようにマージしますか？
行間を読むと、次のように推測できると思います。
- 彼らの「モノリス」「単一リポジトリ」は単一のコンパイルされたアプリケーションではありません
- 潜在的なマージの競合があるかどうかを判断し、開発者を変更する自動化された方法があります。基本的に、コードのセクションを「ロック」できるようにします
要約すると、私はあなたの質問に答えます、私たちは皆同じ問題を抱えており、小さな変更を加えることでそれを解決します。