From da57d36d20e7bc6c3b59671df3b9bf247cb44878 Mon Sep 17 00:00:00 2001 From: Junki Mano Date: Fri, 20 Dec 2024 11:57:30 +0900 Subject: [PATCH] =?UTF-8?q?=E3=83=AC=E3=83=93=E3=83=A5=E3=82=A2=E3=83=BC?= =?UTF-8?q?=E3=80=81=E3=83=AC=E3=83=93=E3=83=A5=E3=82=A4=E3=83=BC=E3=81=AE?= =?UTF-8?q?=E3=81=A0=E3=82=8C=E3=81=8C=E3=83=9E=E3=83=BC=E3=82=B8=E3=81=99?= =?UTF-8?q?=E3=82=8B=E3=81=8B=E3=82=92=E8=BF=BD=E8=A8=98?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- documents/forGitBranch/git_branch_standards.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/documents/forGitBranch/git_branch_standards.md b/documents/forGitBranch/git_branch_standards.md index 8fbb9d9f..223f6535 100644 --- a/documents/forGitBranch/git_branch_standards.md +++ b/documents/forGitBranch/git_branch_standards.md @@ -291,6 +291,24 @@ featureブランチでの作業中に、developブランチが更新された場 [^2]: https://docs.github.com/ja/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors +### マージはだれが行うべきか + +プリリクエストの承認（Approve）をもらった後、マージはレビュアー／レビュイーのどちらが行うべきか議論になる場合がある。 + +| 観点 | レビュアー派 | レビュイー派閥 | +|-------|------------------------------------------|------------------------------------------------| +| 説明 | 開発者の責務が、developブランチにマージするまでという役割分担の場合に有効 | 各開発者がその機能のリリースについて責任を負うモデルの場合に有効 | +| 生産性 | ⚠️レビュアーがブロッキングになりがち | ✅️高い。コメントはあるがApproveしたので、適時対応してマージして、といった運用が可能 | +| 統制 | ✅️レビュアーが管理しやすい | ✅️メンバーの自主性に依存 | +| 要求スキル | ✅️低い。中央で統制を書けやすい | ⚠️開発メンバーの練度が求められる | + +上記にあるように、そのプルリクエストで実装した機能を、本番環境にデリバリーする責務をどちらに持たせるかという観点で、意思決定することが多い。 + +本規約の推奨は以下。 + +* プロダクトオーナー（業務側）などでリリースタイミングを完全にコントロールしたいといった分業制を取る場合は、レビュアーがマージする +* 各開発者により自律性を持たせ、アジャイル的に生産性を重視するのであれば、レビュイーがマージする + ## 3. 永続ブランチ間で変更を取り込む 永続ブランチ同士の変更を取り込むケースとして、`develop` ブランチを `main` ブランチや `release`ブランチにマージするといった場合がある。