こんにちは、コンテナソリューショングループの髙井です。
MicrosoftがGitHubを買収したのが2018年で、すっかり前のことになりましたね。
Azure DevOpsを使う場合でもリポジトリはGitHubを使うケースも多いとは思いますが、今日はReposを使う場合の話です。
ReposはAzure DevOpsの一部なので、同じアカウント内、同じページ内で完結するうれしさがあります。
特に、エンタープライズだといろんなサービスのアカウントを無尽蔵にポコポコ作ったりできないケースもままあるでしょうし、Reposの存在はGitHubがMicrosoft傘下になった今でも重要です。
ただ、普段GitHubに慣れている人がReposを使うと、細かいところで多少デフォルトの挙動の違いに戸惑う面もあります。
というわけで、今回はそんな細かいポイントのひとつとしてFeatureブランチのマージ後にブランチ削除ができないというのを見ていきます。
Pull RequestのComplete
Azure Reposでは、GitHubでいうところのプルリクマージのボタンが下記の画像のようにCompleteという文言になっています。
別のサービスなのでUIが違うのは当たり前なんですが、このボタン自体もPull Request画面の右上にあったりして、この時点で少し戸惑う開発者もいるかもしれません。
問題なのは、この次です。
Complete後にブランチを削除できない
運用ルールにもよりますが、マージ後はソースブランチを削除したいです。
削除ヨシ!と思ったら、
削除できません。
force push permissionが必要と書いてありますね。
force push permissionはProject Settingsから変更する
変更は、少し奥まったところにあります。まず、画面左下のProject SettingsからRepositoriesへ。
さらに、そこからSecurityタブへ移動します。
強力な権限の開放
ここまで来たら、対象のユーザーやグループに対しforce pushの権限をAllowにするだけです。
この権限があるとリモートの内容を書き換え放題なので、間違ってもgit push -f origin :main
とかしないでください。
ちなみにBypass policies when pushingとかいうさらなる闇の権限もあります。
さらに詳しい話
実は、もっとちゃんと管理しようとするとAzure DevOpsのReposの権限は上記だけではなく、3階層に分かれていることを理解する必要があります。
上で紹介したのは、Projectレベルでの権限でした。
実際には、権限は以下の3階層に分かれています。
- Projectレベル
- Repositoryレベル
- Branchレベル
より上位の権限は下位に引き継がれます。
たとえばBranchレベルの権限を確認してみましょう。先ほどのProject Settingsを掘ってもいいのですが、ReposのBranchesブレードから到達することもできます。
するとどうでしょう、inheritedと書いてあるのがわかります。
force pushは強力な権限のため、付与する範囲を意識したほうがよいでしょう。
さらにもっと詳しい話
実は、Branchを作成した人には、そのBranchのforce push権限が自動で割り当たります。
つまりPull Requestのマージ後も、本人がソースブランチを削除する場合はそのまま削除できます。
そのため、本人がマージする運用をしている場合は今回のような問題は起こりません。
とはいえ、レビューする人がマージする運用がそれなりに多いと思いますので、このあたりは運用に合わせて権限付与を考えるのがよいでしょう。
おわりに
面倒くさがって全員にforce pushを許可したりせず、PoLP(最小特権の原則)に沿う形でやっていきましょう!