A new developer's first pull request should pass the exact gates every change passes: required review from code owners, CI tests, a dependency check, and signed commits if your policy asks for them. The first PR is also the best test that those gates actually work, so make it small and deliberate.
Why use the first PR as a drill
New hires are often told to fix a typo or add a line to a README. That is a missed opportunity. A planned first pull request exercises the whole path from branch to merge and shows both the person and you where the gaps are.
If the new person can merge without review, you have found a branch protection hole. If the pipeline takes forty minutes, you have found an onboarding cost. Both are cheaper to learn from one deliberate PR than from an incident.
The gates, in order
| Gate | What it confirms |
|---|---|
| Branch protection or ruleset | Direct pushes to the default branch are blocked |
| Required review | At least one reviewer other than the author approves |
| Code owner review | The owning team is requested for covered paths. GitHub assigns no owner if the listed user or team lacks write access |
| CI tests and lint | The build is reproducible on a clean machine |
| Dependency check | Newly added packages are inventoried and checked for known issues |
| Signed commits | Required only if you require them, and the new developer has set up signing |
| Secret scanning | Provided by a dedicated tool you already use |
A suggested first task
- Assign an issue that changes one line of code and adds one test.
- Ask them to add a harmless, well known dependency in a throwaway branch, as a second pull request that is closed, not merged. Watch how the dependency gate behaves.
- Have the reviewer note any step that was confusing.
- Check that the right code owner team was requested.
- After merge, confirm the audit trail shows author, reviewer and checks.
- Write down what you would change in the onboarding guide.
What a dependency gate should catch
A dependency check should flag newly introduced packages, show their version, and warn on known vulnerabilities or a policy breach, such as a disallowed license or an unmaintained package. The point is not to block every addition, but to make the decision visible to a reviewer.
Try it yourself
Open the pull request gate demo and watch how a change is evaluated against rules before it can merge.
Click through it at your own pace, or open it full screen.
Keep the experience kind
Gates are for the system, not a test of the person. Tell the new hire up front that the first PR is a pipeline drill, and that red checks are expected and useful.
Quick check
Should new hires have a lighter review process?
No. Use the same gates, but pair them with a reviewer who explains comments. The process should be uniform.
Do we need signed commits for everyone?
Only if your policy says so. If it does, set up signing in onboarding, before the first push.
Safeguard's policies, gates and dependency scanning can run on pull requests, so every change gets the same checks. You can also run a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
