GitLab Git Associate study materials
GitLab Git Associate study resources

GitLab Git Associate study plan

GitLab Git Associate · Give each week a clear focus.

8 weeks · About 7 hours per week

Week 1

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.

Week 2

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.

Week 3

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.

Week 4

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.

Week 5

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.

Week 6

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.

Week 7

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.

Week 8

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.