マージの代わりにプルリクエストを使用する理由

ブランチを単純にブランチにマージする代わりにプルリクエストを使用する利点は何ですか？特に、すべての開発者がマスターに完全にアクセスできるチームでは。

プルリクエストは、誰でもマスターにプッシュできる場合でも、チェックとバランスを提供します。

最大の利点は、コードレビューの機会を提供することです。プルの実行を担当する人は、コードとテストを見て、組織またはチームが持っているあらゆる種類のガイドラインを満たしていることを確認できます。コードレビューには他の理由もあります -教育、欠陥または機能強化の発見、システム上のチームのクロストレーニング、テスターに​​システムのホワイトボックスビューの提供。

プルを実行する人がシステムのアーキテクチャに精通している場合、特にチーム全体が長期ビジョンを持っていない場合に、変更がシステムのアーキテクチャビジョンに適合することを確認できます。

プルリクエストを使用する習慣を身に付けることは、チーム全体がマスターにアクセスできないようにする必要があると将来的に判断した場合にも、チームに役立つ可能性があります。チームが大きくなった場合、特に製品やGitを初めて使用するチームメンバーがいる場合は、マスターへのアクセスを許可しないほうが、製品の整合性を確保できます。

機能の分岐と分岐+プルリクエストの両方を行った後、同じチームまたは会社で開発している場合、プルリクエストはほとんど利点がないと思います

それらはコードレビューのための優れたメカニズムとインターフェースを提供しますが、「物事を完成させる」プロセス全体を複雑にし、遅くします。特に、多くの小さな機能がある場合、それぞれがレビューを待って、マージし、他のすべてが再びマスターとマージされて変更などを取得します。 。

同じレポジトリのブランチ間でプルリクエストを実行できると述べました。フォークする必要も、別の権限を持っている必要もありません。

さらに、方法論とワークフロー全体を考慮する必要があります。チケットシステム、CI、自動受け入れテストなどもありますか？コードレビューは、コードが公開される前に重要な単一チェックを提供しますか、それとも、ワークフロー内の他のチェックによって冗長化された単なるゴム印の練習ですか？

コンウェイの法則と呼ばれる所見があります。

システムを設計する組織は、これらの組織の通信構造のコピーである設計を作成するように制限されています。

これはプルリクエストと何の関係がありますか？プルリクエストは、コードの重要な分岐点における主要な通信チャネルです。コードがテストと実稼働の次の段階に進む前に、レビュー、自動化されたテスト、および改善の機会を提供します。これらの変更は取り消すのがはるかに難しく、多くの人の多くの時間を無駄にします。

同様に、Conwayの法則は、明確に分離された自律的責任の領域と明確に定義されたインターフェイスを持つマイクロサービスアーキテクチャが必要な場合、組織の通信チャネルは達成したいアーキテクチャを反映する必要があることを示唆しています。つまり、5〜10人の小規模なチームには、特定のマイクロサービスへの直接コミットアクセス権が必要であり、チーム外のユーザーはプルリクエストを実行する必要があります。これにより、マイクロサービスに最も精通している人々がそれについてレビューし、助言することが保証されます。

誰もがどこにでも直接コミットするアクセス権を持つ大規模な組織の場合、最も抵抗の少ないコミュニケーションチャネルは、泥のアーキテクチャの大きなボールを生成するように設定します。

プルリクエストは、見返りに何もトレードオフしない場合にのみ負担のように感じます。私はビルドが常に壊れているため、1週間何もできない環境で働いていました。誰かがプルリクエストを送信し、壊れたのでそれをレビューする必要さえない環境で働いていましたCIビルド、そして私はあなたに言う、彼らは努力のすべての秒の価値があります。

カールビーレフェルトはまさにその通りです。私は付け加えます：それは品質に関するすべてです。

多くの（ほとんどの？）ショップには、開発を管理する正式なプロセスがありません。その結果、「ビルドが常に壊れているため、1週間何もできない環境で働いており、誰かがプルリクエストを送信し、CIビルドを壊したのでそれを確認する必要さえない環境で、私はあなたに、彼らは毎秒努力する価値があると言います。」

本当に努力する価値があります。

コードレビューにはプルリクエストを使用します。プルリクエストを介さずにコードをメイン開発ブランチ（通常は「開発」、場合によっては「マスター」）にマージすることはできません。リポジトリコントロールを使用してこれを厳密に強制することはありませんが、その必要はないためです。開発者はプロセスを乱用しない程度に成熟しています。