Gitでトランクベースと機能ベースのワークフローを使用する場合の長所と短所は何ですか？
私は、Gitの機能ベースのワークフローのアイデアに非常によく似ています：機能ブランチを使用して並行開発をサポートします。
機能ベースのワークフローでは、機能ブランチ（マスター外）でタスクを開発し、潜在的な競合を避けるためにマスターから頻繁にリベースします。共同作業の場合、機能ブランチをリモートにプッシュ/プルします。マスターに統合する準備ができたら、機能ブランチからマスターへのプルリクエストを開き、プルリクエストがピアによってレビューされ、プルリクエスト（機能ブランチのマスターへのマージ）かどうかを自動的に評価しますビルドと単体テストに合格します。プルリクエストが「グリーン」の場合、機能ブランチは自動的にマスターにマージされます。
前述のワークフローは問題ありません。ただし、一部のインターネット投稿では、「トランクベースの開発」を推奨しています（例： 1 、 2 ）。
私の知る限り、トランクベースの開発は個別の機能ブランチへの開発を奨励していませんが、すべての開発者はマスターに開発しています。このモデルは、開発者が競合を回避するために、開発者が毎日（Martin FowlerのCIプラクティス）をマスターに統合することを推奨しています（対照的に、機能ブランチをマスターにリベースすることです）。
このモデルが機能ベースのモデルにどのような利点をもたらすのか疑問に思っていました。トランクベースのモデルにはいくつかの疑問があります。
コードレビューはどのように行われますか？機能ベースのモデルでは簡単です：機能ブランチに。トランクベースのモデルでは、すべてのコミットがマスターで公開されているため、どうすればそれらをレビューできますか？実際、マスターにマージするときに競合を解決した場合、このコミットはレビューされているように見えませんか？
2人の開発者が同じ機能でどのように協力しますか？機能ベースのモデルでは、両方が機能ブランチで機能します。トランクベースのモデルでは、すべての開発者が「すべての機能」で（何らかの形で）共同作業を行います。正しい？
幹線ベースのモデルは、長寿命の機能ブランチがメインラインにマージする際の潜在的な競合地獄の問題を回避するために「作成」されたと考えています。しかし、機能ブランチが短命で、メインラインから頻繁にリベースされる場合、問題は何ですか？
- 全体的に、機能ベースのワークフローと比較して、トランクベースのメリットはどれですか？
ありがとう:-)
あなたのリファレンス 1 はすでにコードレビューに関するいくつかのポイントを議論しています。この回答は、主に Gerrit ツールとトランクベースのワークフローの使用経験に基づいています。
- コードレビューはどのように行われますか？機能ベースのモデルでは簡単です：機能ブランチに。トランクベースのモデルでは、すべてのコミットがマスターで公開されているため、どうすればそれらをレビューできますか？実際、マスターにマージするときに競合を解決した場合、このコミットはレビューされたように見えませんか？
トランクベースのワークフローでのコードレビューは、コミットがマスターに統合される前に行うことが理想的です。手動で、開発者はコミットを一時的な機能ブランチにプッシュし、承認された場合、それらのコミットをマスターにリベースしてプッシュします（オプションで単一のコミットに押しつぶします）。
Gerritはこのプロセスを自動化します。コミットをGerritにプッシュすると、（ほとんど見えない）一時的なブランチのセットが作成され、レビュー中のコミットが保持されます。レビュー中、行われた修正はレビュー中のコミットに修正され、再びGerritにプッシュされます。承認されると、コミットはアトミックにマスターに統合されます（ユーザーは、リベース、チェリーピック、マージなどのオプションからどのように選択できるか）。
Gerritは、トランクベースのワークフローでのコードレビューに最適です。コミットごとのレビューを促進し、プッシュされたコミットはレビューに合格した後にマスターにのみ表示されるためです（修正は修正として行われるため、「間違った」コミットはマスターに移動しません）。
- 2人の開発者が同じ機能でどのように協力しますか？機能ベースのモデルでは、両方が機能ブランチで機能します。トランクベースのモデルでは、すべての開発者が「すべての機能」で（何らかの形で）共同作業を行います。正しい？
正しい。すべての機能は同じブランチで開発されているため、すべての開発者は同じブランチでコミットします。コードレビュー（および継続的インテグレーション）により、このブランチが常に十分に安定しているという確信が得られます（少なくとも本番用ではないにしても、開発用）。
欠点は、さまざまな複雑な機能のコミットがログでインターリーブされることです。いくつかの問題追跡システムの数を追加すると、非常に役立ちます。ただし、コードレビュー後のコミットの縮小、またはGerrit（ブランチごとではなくコミットごとの強制的なコミット）を使用すると、ほとんどの機能が単一のコミットであることが経験により示されています（マージコミットと同等）機能ベースのワークフロー）。
- 幹線ベースのモデルは、長寿命の機能ブランチがメインラインにマージする際の潜在的な競合地獄の問題を回避するために「作成」されたと考えています。しかし、機能ブランチが短命で、メインラインから頻繁にリベースされる場合、問題は何ですか？
問題は、長寿命の機能ブランチがマスターに統合されている場合にあります。その後、他のすべての長寿命機能ブランチは、その完成した機能からのすべての変更を一度に統合する必要があります。完成したブランチとリベースされたフィーチャーの両方が何らかのリファクタリングを行った場合、それはさらに悪いことです。
- 全体的に、機能ベースのワークフローと比較して、トランクベースのメリットはどれですか？
私が見た最大の利点は次のとおりです。
- より線形の履歴。理解しやすく、チェリーピックと復帰が容易です。
- 主に主要なリファクタリングの場合の、より小さな紛争解決。
ただし、プル要求（機能ベースのワークフロー）をレビューするために設計されたツールを使用する代わりに、トランクベースのワークフローでコードレビュープロセスを自動化するためにGerrit（または同様のツール）を使用することを再度お勧めします。
あなたと同じように、Debitoorの開発者は、トランクベースの開発に疑問を抱いていました。これらの問題を克服するために、彼らはコリツと呼ばれる革新的なソリューションを思いつきました。
Kōritsuは効率を表す日本語の言葉であり、このアプローチは開発者がお互いを邪魔したりブロックしたりしないように設計されています。 Koritsuは、機能ブランチを最大1週間有効にし、すべてのマージをトランクに自動的に展開することを除いて、短命の機能ブランチとかなり似ています。
Debitoorは、当社のWebサイトおよびモバイル開発に数年間、Koritsuを使用しています。私たちにとっては、問題なくスムーズに実行されています。 1つ確かなことは、トランクベースの開発に戻らないことです。
私たちのCTO Allanは、 Trunk Based Developmentの問題 と、Koristuがそれらを修正するためにどのように設計されているかについての記事を書きました。この記事には、彼がトランクベース開発の革新的なソリューションについて行った講演のビデオも含まれています。