GitHub Foundations common mistakes
GitHub Foundations · Understand the traps and how to avoid them.
Treats `git commit` as if it publishes work to GitHub, then gets confused when teammates cannot see the change or when the web UI shows an older file version.
Candidates memorise commands as a flat list and never build the four-stage model (working directory → staging area → local repository → remote), so 'save' and 'share' collapse into one mental step.
What to do instead
Before every practice task, say out loud which of the four stages the command touches; run git status and git log --oneline origin/main..HEAD after committing and confirm the commit count on the remote is still zero until git push runs.
Chooses `git reset --hard` to undo a commit that has already been pushed to a shared branch, reasoning that reset and revert are interchangeable 'undo' commands.
Both commands are taught as 'undo', so the distinguishing factor - whether history is rewritten or a new commit is added - never gets encoded.
What to do instead
Apply the rule: if the commit is on a branch anyone else has pulled, use git revert (adds an inverse commit, safe). Reserve git reset for local, unpushed commits, and be able to state that reset moves the branch pointer while revert does not.
Assumes anyone listed as a member of an organisation automatically has write access to every repository in that organisation, and answers permission questions on that basis.
Organisation membership and repository permission are two separate layers, and study material often lists roles without saying which layer they attach to.
What to do instead
Draw the two layers explicitly: organisation roles (owner/member) plus a configurable base permission that applies org-wide, then per-repository roles (read, triage, write, maintain, admin) that override the base. Check both layers before deciding what a user can do.
Believes a fork stays automatically in step with its upstream repository, so commits merged upstream will appear in the fork without any action.
Forks look like copies in the UI, and 'copy' suggests mirroring; the fact that a fork is an independent repository with its own history is easy to miss.
What to do instead
State plainly that a fork is a standalone repository that diverges. Describe the two sync paths - the 'Sync fork' button in the UI, or adding the source repository as an upstream remote and fetching/merging from it - and note that neither happens on its own.
Answers that a pull request can never be merged once a reviewer selects 'Request changes', in every repository and every configuration.
Review state and merge gating are conflated: the review verdict is a signal, while the actual block comes from branch protection or rulesets that require approvals.
What to do instead
Separate the two concepts in your notes. A 'request changes' review is a signal that blocks merging only when the target branch's protection rules require approving reviews; with no such rule, a user with merge permission can still merge. Read the question for whether protection rules are in play.
Writes 'closes #42' in a regular comment on a pull request and expects the issue to close automatically when the pull request merges.
Candidates generalise from seeing the keyword work somewhere and assume any text field on the pull request triggers the link.
What to do instead
Memorise the exact surfaces: closing keywords (close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved) take effect when placed in the pull request description or in a commit message that reaches the default branch - not in ordinary comments. Also note the keyword only links issues in the same repository.
Writes a workflow triggered by `pull_request` that expects repository secrets to be available, and is surprised when the run from a fork fails or the secret is empty.
The workflow file is visible in the fork's pull request, so the platform withholds secrets by design - a security property that is rarely stated in introductory Actions material.
What to do instead
Learn the fork-PR secret model as a rule: workflows triggered by pull_request from a fork run without repository secrets and with a read-only token. If secrets are genuinely required, describe pull_request_target and the review-before-run safeguards it demands, and be able to say why the default is restrictive.
Describes Dependabot as silently upgrading vulnerable dependencies in place, or uses 'Dependabot alerts' and 'Dependabot security updates' as if they were the same feature.
Three related capabilities share one name, so they merge into a single vague 'Dependabot fixes things' memory.
What to do instead
Keep the three distinct: alerts notify you about a vulnerable dependency, security updates open pull requests to fix alerted dependencies, and version updates open pull requests on a configured schedule regardless of vulnerabilities. Nothing is ever patched without a pull request being raised.
Treats a GitHub Project as a single-repository board where the column a card sits in is what actually sets the issue's status, and expects moving a card to close or reopen the issue.
Board tools elsewhere couple the column to the work item's state, so the separation between an issue's open/closed state and a project item's status field is not obvious.
What to do instead
Describe Projects as a planning layer that can span multiple repositories in an organisation, holding items that reference issues and pull requests. Status is a field on the project item; the issue's open/closed state is separate. Built-in workflows can sync them, but the sync is a configured automation, not an inherent link.
Uses labels to group issues for an upcoming release and then expects a progress indicator and due date, or treats milestones and labels as interchangeable ways to categorise issues.
Both are attached to issues from the sidebar, so the different purposes - cross-cutting tags versus time-boxed delivery grouping - never get separated.
What to do instead
Assign each a job: labels are reusable tags for filtering and triage (type, area, priority) and can be applied to anything; a milestone groups issues and pull requests toward a target date and shows completion percentage. When a question mentions release tracking or completion progress, reach for the milestone.