GitHub GH-900: Work with GitHub Repositories Practice Questions

The 'Internal' visibility setting is available on GitHub Enterprise Cloud/Server and makes the repository visible to all authenticated members of the enterprise, while remaining hidden from the public internet and external users. 'Public' would expose the repository to anyone on the internet, which violates the requirement. 'Private' would restrict access to only explicitly invited collaborators, which is more restrictive than needed and would exclude all other employees by default. 'Protected' is not a valid repository visibility setting in GitHub.

Branch protection rules, found under Repository Settings → Branches, allow administrators to require pull request reviews before merging, prevent direct pushes to protected branches, and enforce other policies like status checks. Action workflow permissions control what GitHub Actions can do, not human push access. Collaborator role assignments control what permissions a user has globally on the repo, but they do not enforce the pull-request-only workflow for a specific branch. Environment protection rules are used to gate deployment workflows to specific environments, not to protect branches from direct commits.

'git tag -a' creates an annotated tag, which is a full Git object containing the tagger's name, email, date, and a message — suitable for public release milestones. 'git tag v2.0.0' (with no flags) creates a lightweight tag, which is simply a pointer to a commit with no extra metadata. '--light' is not a valid git tag flag. 'git tag -s' creates a GPG-signed tag (which is a type of annotated tag), but the question specifically mentions extra metadata including a tagging message, and the most direct/standard command for that is '-a'; additionally, '-s' requires a configured GPG key, making it a more specific and less universally applicable answer.

Under Semantic Versioning, the MINOR version is incremented when new, backward-compatible functionality is added — resulting in 1.5.0 (the patch number resets to 0). The MAJOR version (2.0.0) is incremented only for breaking, backward-incompatible changes. The PATCH version (1.4.3) is incremented only for backward-compatible bug fixes, not new features. A pre-release label like '1.4.2-beta.1' denotes an unstable pre-release version, not a stable feature release.

'git commit --amend' rewrites the most recent commit, allowing the developer to edit its message (and optionally its content) without adding a new commit to the history — ideal for fixing a typo before pushing. 'git revert HEAD' creates a brand-new commit that undoes the changes of the last commit; it does not change the commit message. 'git reset --soft HEAD~1' undoes the last commit but keeps the changes staged, so the developer would need to re-commit everything — it doesn't simply fix the message. 'git commit --fixup' creates an additional fixup commit intended for use with interactive rebase; it does not directly amend the message.