Learn vocabulary for repository governance: CODEOWNERS, branch protection, and rulesets.
0 / 18 completed
1 / 18
What is a CODEOWNERS file on GitHub?
CODEOWNERS automatically assigns specific reviewers when a PR touches matched files — e.g., /src/auth/ @security-team means the security team must approve any changes to that directory.
2 / 18
What is 'branch protection' on GitHub?
Branch protection rules prevent unreviewed or untested code from being merged — e.g., requiring 2 approvals, passing CI checks, and up-to-date status before merging to main.
3 / 18
What is 'squash merge' in PR merge strategy vocabulary?
Squash merge combines all PR commits into one commit — keeping the main branch history clean and readable. The trade-off is losing individual commit history from the PR.
4 / 18
What is a 'required status check' in branch protection?
Required status checks ensure specific CI jobs (tests, builds, security scans) pass before merging. If a required check fails, the PR cannot be merged even with sufficient approvals.
5 / 18
What is 'repository ruleset' in GitHub (introduced 2023)?
GitHub Rulesets replace and extend branch protection — allowing organisation-wide rules, multiple branch targeting with patterns, bypass permissions for specific actors, and enforcement across repositories.
6 / 18
John in the code review comment says: "I'm not responsible for this module; it was inherited from the legacy system. It's a known pain point – we should really consider refactoring eventually, but I don't have time right now."
Which of the following best describes John's statement regarding repository governance?
John's statement reflects the concept of *component ownership* within repository governance. While acknowledging a legacy component isn't ideal, it's perfectly acceptable to state limited responsibility when dealing with inherited code, especially if coupled with an understanding of its known issues and a recognition of resource constraints – this aligns with established guidelines for prioritizing work and managing technical debt. Option A is too aggressive; option C misrepresents his position entirely, and option D incorrectly frames the situation as blame-shifting.
7 / 18
John's comment during the code review raises concerns about accountability and long-term strategy within the repository. He's effectively stating a lack of ownership regarding a problematic module due to its origin. This inaction could be interpreted as a failure to address potential risks or contribute to improvements. What does John's statement primarily illustrate concerning repository governance?
The correct answer highlights that John's statement demonstrates responsible risk management by acknowledging a legacy dependency. The other options misinterpret his words: he isn't *solely* responsible, nor is deferring responsibility inherently good governance (it can lead to problems if not addressed); and his comment doesn't directly relate to the governance process itself – it's a statement about the module's state. A key element of repository governance is identifying and managing technical debt like this, even if immediate action isn't possible.
8 / 18
John in the code review comment says: "I'm not responsible for this module; it was inherited from the legacy system. It's a known pain point – we should really consider refactoring eventually, but I don't have time right now."
Which of the following best describes John's statement regarding repository governance?
John's statement reflects the concept of *component ownership* within repository governance. While acknowledging a legacy component isn't ideal, it's perfectly acceptable to state limited responsibility when dealing with inherited code, especially if coupled with an understanding of its known issues and a recognition of resource constraints – this aligns with established guidelines for prioritizing work and managing technical debt. Option A is too aggressive; option C misrepresents his position entirely, and option D incorrectly frames the situation as blame-shifting.
9 / 18
John's comment during the code review raises concerns about accountability and long-term strategy within the repository. He's effectively stating a lack of ownership regarding a problematic module due to its origin. This inaction could be interpreted as a failure to address potential risks or contribute to improvements. What does John's statement primarily illustrate concerning repository governance?
The correct answer highlights that John's statement demonstrates responsible risk management by acknowledging a legacy dependency. The other options misinterpret his words: he isn't *solely* responsible, nor is deferring responsibility inherently good governance (it can lead to problems if not addressed); and his comment doesn't directly relate to the governance process itself – it's a statement about the module's state. A key element of repository governance is identifying and managing technical debt like this, even if immediate action isn't possible.
10 / 18
John in the code review comment says: "I'm not responsible for this module; it was inherited from the legacy system. It's a known pain point – we should really consider refactoring eventually, but I don't have time right now."
Which of the following best describes John's statement regarding repository governance?
John's statement reflects the concept of *component ownership* within repository governance. While acknowledging a legacy component isn't ideal, it's perfectly acceptable to state limited responsibility when dealing with inherited code, especially if coupled with an understanding of its known issues and a recognition of resource constraints – this aligns with established guidelines for prioritizing work and managing technical debt. Option A is too aggressive; option C misrepresents his position entirely, and option D incorrectly frames the situation as blame-shifting.
11 / 18
John's comment during the code review raises concerns about accountability and long-term strategy within the repository. He's effectively stating a lack of ownership regarding a problematic module due to its origin. This inaction could be interpreted as a failure to address potential risks or contribute to improvements. What does John's statement primarily illustrate concerning repository governance?
The correct answer highlights that John's statement demonstrates responsible risk management by acknowledging a legacy dependency. The other options misinterpret his words: he isn't *solely* responsible, nor is deferring responsibility inherently good governance (it can lead to problems if not addressed); and his comment doesn't directly relate to the governance process itself – it's a statement about the module's state. A key element of repository governance is identifying and managing technical debt like this, even if immediate action isn't possible.
12 / 18
John in the code review comment says: "I'm not responsible for this module; it was inherited from the legacy system. It's a known pain point – we should really consider refactoring eventually, but I don't have time right now."
Which of the following best describes John's statement regarding repository governance?
John's statement reflects the concept of *component ownership* within repository governance. While acknowledging a legacy component isn't ideal, it's perfectly acceptable to state limited responsibility when dealing with inherited code, especially if coupled with an understanding of its known issues and a recognition of resource constraints – this aligns with established guidelines for prioritizing work and managing technical debt. Option A is too aggressive; option C misrepresents his position entirely, and option D incorrectly frames the situation as blame-shifting.
13 / 18
John's comment during the code review raises concerns about accountability and long-term strategy within the repository. He's effectively stating a lack of ownership regarding a problematic module due to its origin. This inaction could be interpreted as a failure to address potential risks or contribute to improvements. What does John's statement primarily illustrate concerning repository governance?
The correct answer highlights that John's statement demonstrates responsible risk management by acknowledging a legacy dependency. The other options misinterpret his words: he isn't *solely* responsible, nor is deferring responsibility inherently good governance (it can lead to problems if not addressed); and his comment doesn't directly relate to the governance process itself – it's a statement about the module's state. A key element of repository governance is identifying and managing technical debt like this, even if immediate action isn't possible.
14 / 18
Sarah, the team lead, posted this message in Slack: 'Regarding the refactor-payments branch – we need to enforce stricter governance. All PRs must include a clear justification for any changes to the core payment logic and adhere to the documented API contracts. Failure to comply will result in immediate rejection.' What does 'adhere to the documented API contracts' primarily mean in this context?
The phrase 'adhere to' means to follow or comply with. In API terms, it signifies that PRs must respect the documented rules and structures of the payment APIs – essentially, they must use the correct inputs and outputs as defined by those contracts. Option A is about coding style, not API adherence; option C is about timing, not compliance; and option D describes a separate approval process.
15 / 18
During a standup meeting, David said: 'I've been working on the data-pipeline repository and I'm trying to get it fully governed. I've added a CODEOWNERS file to designate specific team members for different components. It seems like a good way to distribute responsibility.' What is the primary purpose of a CODEOWNERS file in a repository?
A CODEOWNERS file doesn't automatically assign PRs or track usage. Its core function is to designate specific people who are accountable for particular parts of the code. This facilitates targeted reviews and support when issues arise – ensuring that the right expertise is involved in addressing problems.
16 / 18
You're reviewing a PR to update the authentication module. The PR description reads: 'Fixes a bug where users couldn't log in after password resets. Updated the JWT generation logic and added some error handling.' Which of these phrases best describes the level of detail expected in a good PR description related to repository governance?
While brevity is useful, a good PR description should provide enough context to allow reviewers to understand *why* the change was made and assess its potential impact. Option B offers specifics about the updated logic, allowing for scrutiny of security considerations – it's a crucial element of repository governance.
17 / 18
The API response from the GitHub Enterprise server after attempting to set up branch protection rules for the api-gateway repository is: `{"status": "success", "message": "Branch protection rule created successfully."}`. What does this response *primarily* indicate regarding the implementation of repository governance?
The response confirms that a branch protection rule was *created* successfully. While this is an important first step, it doesn't guarantee full compliance; further actions (like setting up required status checks) would be needed to meet all governance requirements. The API simply acknowledges the rule's creation.
18 / 18
In a discussion about repository governance, Maria says: 'We should implement a policy that requires all PRs to be reviewed by at least two developers before they're merged.' What is she advocating for, in terms of best practices for managing code and ensuring quality?
Requiring a minimum review by two developers introduces redundancy and increases the likelihood of identifying potential issues. This multi-perspective approach is a fundamental aspect of robust governance – it minimizes the risk of errors and promotes higher code quality through diverse viewpoints.
What will I practise in "Repository Governance — Vocabulary and Language"?
Learn vocabulary for repository governance: CODEOWNERS, branch protection, and rulesets.
How many exercises are in this module?
This module has 18 multiple-choice exercises, each with instant feedback and a full explanation of the correct answer.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do I need to create an account to do these exercises?
No account is required. Just click an option to answer — your score for this session is tracked automatically in the progress bar above.
What happens if I choose the wrong answer?
You'll immediately see which answer was correct, plus a full explanation covering the vocabulary and reasoning behind it — mistakes are where most of the learning happens.
Can I retry the exercises if I want a higher score?
Yes — use the "Try again" button on the results screen to reset and go through all the questions again.
Is my progress saved if I close the page?
No. Progress is tracked only for your current visit; reloading or leaving the page resets the counter. This keeps the exercise simple and account-free.
Where can I find more GitHub Platform Language exercises?
Browse the full GitHub Platform Language hub for related drills, or check the "Next up" link below to continue with a connected topic.
How is this different from reading an article on the same topic?
Articles explain vocabulary and concepts in prose; this exercise tests and reinforces that vocabulary through active recall with immediate feedback — the two work best together.
Who writes these exercises?
Every exercise is written by the CoderSlingo team, drawing on real workplace English used in IT roles, then reviewed for accuracy and clarity.