<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=25523) </details> <!--IssueSummary end--> We should completely replace passing ref names to `Project#protected_for?` with using full refs. https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2596 prevents ambiguity in the `protected_for?` by supporting both full refs and ref names and erroring out on ambiguous refs. To better abstract the concepts of full ref and ref name we should create classes for them (`Gitlab::Git::FullRef` and `Giltab::Git::RefName`). This method gets called from `Gitlab::Ci::Pipeline::Chain::Command`, which gets built in `CreatePipelineService` which receives parameters from the controller which receives parameters from the fronted. All of those places send back just the ref name. Fixing this requires those parts of the frontend to be reworked into sending back full refs. There's also lots of places in specs where we use only ref names. All other occurrences of `protected_for?` are covered in https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2596 and use full refs as a parameter. I see a couple of steps for achieving this: 1. Prevent ambiguity (https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2596) 1. Use only full refs when calling `Projected#protected_for?` - requires frontend refactor (https://gitlab.com/gitlab-org/gitlab-ce/issues/54700) 1. Simplify `Project#protected_for?` and remove parts of code which are no longer necessary (https://gitlab.com/gitlab-org/gitlab-ce/issues/54701) 1. Use a class based approach for handling refs (https://gitlab.com/gitlab-org/gitlab-ce/issues/54702)