GitLab Git Associate common mistakes
GitLab Git Associate · Understand the traps and how to avoid them.
Treating `git pull` as a synonym for `git fetch` and assuming the local branch is now identical to the remote, without checking whether the pull performed a merge or fast-forward and whether it created a merge commit.
Candidates memorize 'pull = fetch + merge' as a slogan but never look at the output or git log --graph, so they cannot say what state the branch is in after the command, which is exactly what scenario questions probe.
What to do instead
After any pull, run git log --oneline --graph --decorate -5 and git status and state explicitly: did it fast-forward, did it create a merge commit, or did it fail due to divergent branches? Practice with git pull --ff-only and git pull --rebase so you can explain the difference between the three outcomes.
Confusing `git fetch` with a change to working files - believing that fetching updates the working tree or that a fetched branch is automatically merged into the current branch.
The mental model 'fetch downloads, pull downloads and applies' is remembered too loosely, and candidates never test what origin/main looks like after a fetch versus what main looks like.
What to do instead
Memorize the two refs distinctly: fetch moves the remote-tracking ref origin/main only; your local main and working tree are untouched until you merge or rebase onto origin/main. Verify by fetching, then comparing git log main..origin/main.
Describing `git reset --soft`, `--mixed`, and `--hard` as interchangeable 'undo' commands, or claiming `reset` is safe for shared branches.
The three modes are learned as a list without tying each to which of the three areas (HEAD, index, working tree) it moves, so under exam pressure candidates pick whichever sounds gentler.
What to do instead
Anchor each mode to the areas it changes: --soft moves HEAD only (changes stay staged), --mixed (default) moves HEAD and resets the index (changes unstaged), --hard moves HEAD and resets index and working tree (changes discarded). Add that reset rewrites local branch position, so on shared branches prefer git revert, which creates a new commit undoing the change.
Using `git revert` and `git reset` interchangeably in answers about undoing a commit that has already been pushed and reviewed on a shared branch.
Both are filed mentally as 'undo a commit', and candidates miss that only one of them is safe for history others already have.
What to do instead
State the rule directly: published history is not rewritten - use git revert <sha> to add an inverse commit. Reserve reset/amend/interactive rebase for unpushed local commits. If asked what happens to collaborators after a force-push, say their local history diverges and they must reset or rebase onto the rewritten branch.
Explaining merge conflicts as an error to be avoided rather than a normal state, and being unable to name the steps to resolve one (identify files, edit markers, `git add`, commit).
Candidates have avoided conflicts in practice by discarding changes, so they never learned the resolution workflow or what git status reports mid-merge.
What to do instead
Learn the loop: git status lists unmerged paths; edit to remove <<<<<<<, =======, >>>>>>> markers; git add each resolved file; git commit completes the merge. Also know git merge --abort and git rebase --abort to back out, and that git diff during a conflict shows combined diff.
Describing rebase as 'the same as merge but cleaner' and failing to explain that rebase rewrites commit SHAs and linearizes history.
The 'clean history' talking point is repeated without the consequence, so candidates cannot answer why a rebase of shared commits is dangerous or why duplicates appear after rebasing a branch someone else also has.
What to do instead
Say it precisely: rebase replays commits onto a new base, producing new SHAs; the original commits become unreachable. Therefore never rebase commits others have pulled. Know that git rebase --onto, -i for squash/reword, and --abort/--continue exist, and that a rebase conflict is resolved per commit, not once.
Assuming a merge request merges the source branch into the target automatically and instantly, or that pushing to a fork updates the upstream project.
The GitLab UI vocabulary (source/target branch, fork, upstream) is confused with the git commands, and candidates conflate 'opened an MR' with 'merged'.
What to do instead
Separate the concepts: an MR is a review request from a source branch to a target branch; the merge happens only when someone with permission clicks Merge (and only if the pipeline and approvals allow). A fork is a separate repository; changes reach the upstream only via an MR or by adding the upstream as a remote and pushing where permitted.
Treating protected branches as merely 'important' branches, unable to state what protection actually enforces (who can push, whether force-push is allowed, whether merges require approvals or passing pipelines).
Candidates read the setting name and infer a vague sense of safety instead of the concrete rules, so they cannot answer scenario questions about a developer being unable to push to main.
What to do instead
Learn protected branches as a set of enforced rules: allowed-to-push/merge roles, no force-push by default, required approvals, and required status checks. Connect the symptom 'push rejected' or 'merge button disabled' to the specific rule that causes it.
Reading `git log` output only as a list of messages and being unable to use it to answer 'which commits are on this branch but not that one' or to find when a line changed.
Candidates run plain git log and never practice the range, graph, and search options, so inspection questions feel like trivia rather than tool use.
What to do instead
Practice the specific forms: git log --oneline --graph --all, git log main..feature and feature..main for asymmetric differences, git log -S<string> (pickaxe) and -G<regex> for content changes, git log --follow -- <path> for file history, and git blame -L for line attribution. Know git diff compares working tree vs index by default, --staged for index vs HEAD, and A..B for commits.
Confusing lightweight and annotated tags, or assuming a tag moves with new commits and must be pushed like a branch.
Tags are treated as 'branch labels', so candidates miss that tags are fixed refs, that annotated tags carry their own message/tagger, and that git push does not send tags by default.
What to do instead
State the differences: lightweight tag is just a ref to a commit; annotated tag is a full object with tagger, date, and message, and is what release tooling expects. Tags do not move unless deleted and recreated. Push explicitly with git push origin <tagname> or git push --tags, and delete with git push origin --delete <tagname>.
Choosing a branching strategy answer (Git Flow vs trunk-based vs feature branching) by naming the strategy without connecting it to review, protected branches, and merge request size.
Candidates memorize strategy names as vocabulary and never link them to the GitLab workflow mechanics the exam actually tests, such as short-lived branches, small MRs, and required approvals.
What to do instead
Answer strategy questions by describing the workflow: short-lived feature branches off the default branch, an MR for review, protected default branch with required approvals and passing pipelines, squash or merge commit policy, and deletion of the source branch after merge. Explain the trade-off (long-lived branches cause painful merges and stale reviews) rather than just naming the model.