Use this cheat sheet for GitHub Foundations after you know the vocabulary and need faster collaboration decisions. Foundations questions usually test whether you can separate Git mechanics from GitHub collaboration, pick the right workflow object, and protect a repository without overengineering it.
GH-900 answer sequence
Use this when the stem mixes Git, GitHub collaboration, repository objects, or security settings.
flowchart TD
S["Scenario"] --> L["Is this local Git or GitHub collaboration?"]
L --> O["Identify the object: commit, branch, PR, issue, or workflow"]
O --> P["Choose the simplest collaboration path"]
P --> V["Apply the right permission or protection layer"]
Read every GitHub Foundations question in this order
- Decide whether the question is about local Git, hosted GitHub collaboration, repository security, or project tracking.
- Identify the object: commit, branch, pull request, issue, discussion, project, release, workflow, or repository setting.
- Choose the simplest collaboration path that preserves review, history, and ownership.
- Add security only at the right layer: account, organization, repository, branch, secret, or workflow.
- Reject answers that mix up issues, pull requests, discussions, and repository files.
Git versus GitHub
| Need |
Git concept |
GitHub concept |
| record source change |
commit |
commit displayed in hosted repository |
| isolate work |
branch |
branch with PR, protection, and review |
| share local work |
remote push/pull |
repository collaboration and permissions |
| combine history |
merge or rebase |
PR merge strategy and protected-branch rules |
| recover history |
log, reflog, revert |
repository activity and review trail |
| coordinate work |
not Git-native |
issues, projects, discussions, notifications |
Collaboration object chooser
| Situation |
Use |
| propose code change |
pull request |
| track bug, task, or feature request |
issue |
| discuss broad idea or Q&A |
discussion |
| track planned work across issues and PRs |
project |
| group planned work by release target |
milestone |
| publish versioned software |
release and tag |
| explain repository usage |
README and docs |
Pull request review map
| Requirement |
Strong answer pattern |
| code needs peer review |
open PR, request reviewers, address comments |
| tests must pass before merge |
required status checks |
| protected main branch |
branch protection or ruleset |
| unclear proposed change |
PR description, linked issue, and smaller commits |
| conflict appears |
update branch and resolve conflict before merge |
| wrong merge style concern |
choose merge commit, squash, or rebase based on repository policy |
Repository and permission basics
| Topic |
Fast distinction |
| visibility |
public, private, or internal where available |
| collaborator access |
repository-level access for individuals or teams |
| organization access |
teams and roles scale better than one-off user grants |
| branch protection |
protects important branches from unsafe direct changes |
| CODEOWNERS |
routes review ownership for paths |
| secrets |
store sensitive values outside code and rotate if exposed |
| audit/activity |
use history and logs to understand what changed |
Security basics
| Risk |
Better instinct |
| secret committed |
revoke, rotate, remove, and prevent recurrence |
| direct push to main |
protect branch and require review/checks |
| broad repo access |
use least privilege and team-based access |
| dependency risk |
review alerts and updates before merge |
| untrusted automation |
check workflow permissions and secret exposure |
| suspicious account activity |
review authentication, sessions, tokens, and audit signals |
Common traps
| Trap |
Better instinct |
| Git equals GitHub |
Git is version control; GitHub adds hosted collaboration and governance |
| issue for code review |
issues track work; PRs review and merge code |
| discussion for private secret |
never put secrets in public collaboration surfaces |
| branch protection after incident only |
use protection before critical branch mistakes happen |
| merge without evidence |
reviews, checks, and linked context reduce risk |
| every solution is Actions |
many Foundations scenarios need repo settings or collaboration objects |
Final 15-minute review
| If the stem says… |
Start here |
| code change |
branch, commit, PR, review, status check, merge |
| work tracking |
issue, label, assignee, milestone, project |
| broad conversation |
discussion, not PR comments |
| protected workflow |
branch protection, required review, checks, CODEOWNERS |
| access problem |
visibility, collaborator, team, role, least privilege |
| exposed secret |
revoke, rotate, remove, prevent |
Practice fit
Use IT Mastery for the exact product route, practice status, spaced review when available, and close-answer explanation practice as coverage expands.
One-line decision rule
GitHub Foundations answers should choose the right collaboration object, preserve reviewable history, and protect repository access without confusing Git mechanics with GitHub workflow features.