更新箇所を取り込んだらバグって動かなくなりました。C:見せてみ?うんにゃ?これはBさんの修正箇所だわな。B:え、あ・・・すいません。Aさんから許可をもらったんで・・・A:あ?それぐらい自分で気付けや!B:ううう・・・D:(ところで、Aってそこまでこの開発言語知識あったっけ?)C:(いや、この言語は結構最新のだからおそらくねえな。俺が見ときゃよかったか。)言語や技術力によって、得意不得意があるので適正外の方が結合許可を出すのは良くないです。そんな時にこれを使います。フォルダを作って、中にCODEOWNERSファイルを作成します。書き方は以下を参照してください。(全ファイルを特定のユーザチェック必須にするには以下のように書きます。(特定のファイルのみを特定のユーザチェック必須にするには以下のように書きます。(特定のフォルダのファイル指定も可能です。reviewsところで、以下のようになったらどうしますか?A:おい!誰だよこの結合拒否出したの!B:あ、はい。私のレビューをEさんにお願いしたんです。D:Eさんって凄い技術者だったよね。弄れよ)Cの発言はさておき、職場では色々あり担当者がいなくなるなど日常茶飯事です。上記の場合Eさんがチームに復帰するまで結合不能で詰みます。そこでこの機能を設定し、ユーザー(例えばAさん)を設定することにより設定されたユーザー(例えばAさん)は結合拒否をキャンセルさせることができます。対象のリポジトリで管理者権限以上を持っていれば態々自分のユーザーを設定しなくてもこの項目にチェックがついているだけで結合拒否をキャンセルできます。merging超簡単に説明すると、自身でオリジナルのチェック方法を設定できるというものです。設定方法とかは滅茶苦茶面倒臭いので割愛します。第一、設定しなくても十分ブランチを保護できます。mergingデフォルトのチェックとして上記のものがついています。これは、結合したいブランチが結合先のブランチで更新された内容を取得しているかチェックするものです。古すぎるブランチほど結合先の最新情報を取得していない可能性が増えるのでこのチエックで引っかかるようになります。作ったブランチは出来るだけ早く取り込めるようにタスク内容を切り分けることが必要になってきます。commitsコミット時、デジタル署名をしなければコミットできません。セキュリティ特化でもない限り利用しません。commitsの方法をrejectします。merging詳細の説明はこちらに投げますが結合履歴が一番複雑になる結合方法をrejectすることにより結合履歴を管理しやすくします。最近追加された要素みたいです。administratorsブランチ保護の適応範囲に管理者も含めさせます。branches以下の揉め事を回避できます。D:おっと、僕のブランチのコミット履歴にBさんの名前が入っているね。B:え?私、自分のブランチにコミットしたと思ったのですが・・・A:おい、pushする時にはちゃんとブランチ確認しろって言っただろ!B:ご、ごめんなさい・・・C:(普通に考えて毎回毎回いちいち確認してられっかっての!)ここを有効にした上で、ユーザー名を指定することにより、ブランチにpushできるユーザーを指定できます。登録されていないユーザーがpushしようとするとrejectされます。administrators簡単に説明すれば、このブランチに対し強制プッシュやブランチ削除可能にするものです。今回は保護とは逆の判断なので割愛。まとめ他のサイトでも似たような説明は結構ありますが、どう言った場面でどのように活用するのかがよくわからなくて結局取り入れないというのが帝石な感じがしたのでメモとして記載してみました。どっかの他のシステムや資産管理とは違い最低限のものは結構簡単に設定できるので、出来るだけ利用して頂きより利便性よくそして犯人探しという罪のなすり合い付けが起きないことを祈っています。upLoginユーザーは見つかりませんでした。