GitLab Git Associate study plan
GitLab Git Associate · Give each week a clear focus.
8 weeks · About 7 hours per week
Git fundamentals (repositories, commits, branching, merging)
Initialize a local repository and explain what lives in .git versus the working tree.
Create commits that each isolate one logical change, writing messages in imperative mood with a body when context is needed.
Demonstrate the difference between the working tree, the staging area (index), and HEAD by staging and unstaging partial file changes.
Build a three-branch topology (main, feature, hotfix) and merge each back with both fast-forward and --no-ff merges.
Resolve a deliberately introduced merge conflict by hand and explain what the conflict markers represent.
Your checkpoint
A local repository with at least 12 commits across three branches, a documented conflict resolution, and a one-page note mapping each Git object type (blob, tree, commit, tag) to something you created.
Git fundamentals (repositories, commits, branching, merging)
Explain how a commit is identified by its SHA and why the hash changes when history is rewritten.
Compare merge and rebase on the same branch pair and describe when each rewrites history and when it does not.
Perform an interactive rebase that squashes, rewords, and reorders commits, then verify the resulting log.
Use cherry-pick to move a single commit between branches and explain the duplicate-commit consequence.
Demonstrate a fast-forward-only merge policy and describe what it prevents.
Your checkpoint
A written comparison (roughly 400 words) of merge versus rebase using your own branch graphs, plus a branch whose messy history you cleaned with interactive rebase.
History and inspection (log, diff, blame, tags, reverting and resetting)
Read git log output with --oneline, --graph, --stat, and date/author filters to answer specific history questions.
Use git diff across working tree, index, and commit ranges, including the two-dot versus three-dot distinction.
Run git blame on a file and trace a line back to the commit and merge request that introduced it.
Create lightweight and annotated tags, then check out a tag in detached HEAD state and recover safely.
Use git revert to undo a published commit and explain why revert is preferred over reset on shared branches.
Your checkpoint
An investigation report on a real open-source repository: identify who introduced a specific bug-prone line, which release tag first contained it, and the exact diff that changed it.
History and inspection (log, diff, blame, tags, reverting and resetting)
Distinguish soft, mixed, and hard resets by predicting exactly which of working tree, index, and HEAD each moves.
Recover a commit that was lost after a hard reset using the reflog.
Use git stash to shelve work in progress, then pop and apply stashes and resolve a stash conflict.
Search history with git log -S (pickaxe) and git grep to locate when a string was added or removed.
Explain how to undo a merge commit and when reverting the merge is the correct choice.
Your checkpoint
A recovery log documenting three deliberate mistakes (hard reset, bad merge, dropped stash) and the exact command sequence that restored each one.
Remote collaboration (remotes, fetching, pulling, pushing, pull requests/merge requests)
Add, inspect, rename, and remove remotes, and explain the difference between origin/main and local main.
Fetch versus pull: demonstrate what each does to remote-tracking branches and when pull introduces a merge commit.
Push a new local branch with upstream tracking set, then push to a branch whose history diverged and choose between merge and rebase.
Configure SSH keys or a credential helper and verify authentication without embedding a token in a remote URL.
Explain what force-push does to collaborators and use --force-with-lease instead.
Your checkpoint
Two cloned repositories simulating two developers, with a documented sequence of fetch, pull, push, rejected push, and safe force-push, including the terminal output at each step.
Remote collaboration (remotes, fetching, pulling, pushing, pull requests/merge requests) & GitLab workflow and branching strategies (forks, protected branches, code review)
Fork a public project on GitLab, add the upstream remote, and keep your fork synced with upstream main.
Open a merge request from a feature branch, write a description that states the problem and the approach, and link it to an issue.
Review a merge request: leave line-level comments, request changes, and approve after the author addresses them.
Configure a protected branch so direct pushes are blocked and merges require approval.
Resolve review feedback by amending or adding commits, and explain how squash-on-merge affects the target branch history.
Your checkpoint
A completed merge request cycle on a fork: issue, branch, MR with description, at least two review comments you wrote, one round of changes you made in response, and a merged result.
GitLab workflow and branching strategies (forks, protected branches, code review)
Compare GitLab Flow, trunk-based development, and release-branch strategies on branch lifetime, review load, and release cadence.
Set up branch naming and commit message conventions and enforce them with a push rule or commit-message regex.
Design a CODEOWNERS file so that changes to specific paths require the right reviewers.
Describe how merge request pipelines and required status checks gate a merge.
Map a hotfix workflow from production bug to merged fix and back-merge into the main line.
Your checkpoint
A one-page branching-strategy proposal for a hypothetical team of eight, covering branch types, protection rules, CODEOWNERS, review requirements, and a hotfix path, with a justification for each choice.
Git fundamentals (repositories, commits, branching, merging) & Remote collaboration (remotes, fetching, pulling, pushing, pull requests/merge requests) & History and inspection (log, diff, blame, tags, reverting and resetting) & GitLab workflow and branching strategies (forks, protected branches, code review)
Complete a timed mixed practice set weighted 25 percent per domain and review every missed item to its root cause.
Re-derive from memory the commands for conflict resolution, revert versus reset, reflog recovery, and safe force-push.
Explain aloud, without notes, the full lifecycle of a change from local commit to merged merge request.
Audit your weak areas from weeks 1-7 and close the two lowest-scoring topics with targeted drills.
Your checkpoint
A scored practice exam with a written error analysis listing each miss, the underlying concept, and the corrected reasoning, plus a personal command cheat sheet you built yourself.
Milestones
Week 2: You can draw a commit graph from memory for a branch, merge, and rebase scenario and predict the resulting SHAs and parent relationships.
Week 4: Given a broken repository state, you recover it using reflog, revert, or stash within five minutes without looking up the syntax.
Week 6: You have personally completed at least one merge request on a fork, including a review cycle where you both received and gave substantive feedback.
Week 8: You score at least 80 percent on a full-length mixed practice set with no domain below 70 percent, and your error analysis shows no repeated root cause.