A snapshot of the repository at a point in time, identified by a unique SHA-1 hash and containing author, message, and parent commit references.

A special pointer that indicates the current branch or commit checked out in the working tree; usually points to the tip of the current branch.

The index that holds changes prepared for the next commit; `git add` moves changes from the working tree into the staging area.

A merge that moves the target branch pointer forward when the target is an ancestor of the source, without creating a merge commit.

A merge that combines two branch histories using their common ancestor; if changes conflict, manual resolution is required before committing.

Reapplies commits from one branch onto another base, creating a linear history; it rewrites commit hashes and should be avoided on shared branches.

Applies the changes introduced by a specific commit onto the current branch, creating a new commit with a different hash.

A tag object that stores a message, tagger name, email, and date along with the commit reference; recommended for release marking.

A named reference to another repository URL, such as `origin`, used to fetch from and push to a shared or upstream repository.

Downloads objects and refs from a remote repository and updates remote-tracking branches, but does not modify the working tree or current branch.

Fetches from a remote and integrates changes into the current branch, typically by merging; with `--rebase`, it rebases instead.

Upstream tracking branch

A local branch configured to track a remote branch, enabling `git pull` and `git push` without arguments; set with `git push -u`.

A GitLab feature that requests merging a source branch into a target branch, enabling review, discussion, and CI checks before integration.

A safer force push option that only overwrites the remote branch if it still matches the local remote-tracking ref, preventing loss of others' work.

Removes remote-tracking branches that no longer exist on the remote; `git fetch --prune` performs the same cleanup during a fetch.

Displays each commit on a single line with an abbreviated hash and commit message, providing a compact view of history.

Shows differences between the staging area and the last commit (HEAD), revealing what would be included in the next commit.

Annotates each line of a file with the last commit hash and author that changed it, useful for tracing the origin of code.

Creates a new commit that applies the inverse of a specified commit's changes, safely undoing changes in shared history without rewriting it.

Moves HEAD to a specified commit and discards all changes in the working tree and staging area; irreversible for uncommitted work.

Records local movements of HEAD and branch tips, allowing recovery of commits that are no longer reachable from any branch.

The pickaxe option that finds commits which added or removed a specific string, useful for locating when code was introduced.

Displays the metadata and diff of a commit, tag, or other object; for a commit, it shows the changes introduced by that commit.

A personal copy of a repository under your own namespace, allowing you to propose changes to the original project via merge requests.

A GitLab branch setting that restricts pushes and merges, often requiring merge requests and approvals to prevent direct changes.

A merge strategy that combines all commits from a merge request into a single commit on the target branch, simplifying history.

Merge request approval

A GitLab setting requiring a specified number of approvals before a merge request can be merged; approvals can reset on new commits.

A CI/CD status check that must succeed before a merge request can be merged, ensuring code passes tests and builds.

A GitLab tag setting that controls who can create, delete, or modify tags, often used to secure release version tags.

Feature branch workflow

A branching strategy where each feature is developed on a dedicated branch created from main and merged back via a merge request.

Merge request discussion

A threaded comment on a merge request that can be resolved; unresolved threads can be configured to block merging.

Code review suggestion

A GitLab merge request feature allowing reviewers to propose exact code changes that authors can apply directly with one click.

GitLab Git Associate study materials

GitLab Git Associate flashcards

GitLab Git Associate · Build recall with a focused review session.

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

Commit: A snapshot of the repository at a point in time, identified by a unique SHA-1 hash and containing author, message, and parent commit references.
HEAD: A special pointer that indicates the current branch or commit checked out in the working tree; usually points to the tip of the current branch.
Staging area: The index that holds changes prepared for the next commit; `git add` moves changes from the working tree into the staging area.
Fast-forward merge: A merge that moves the target branch pointer forward when the target is an ancestor of the source, without creating a merge commit.
Three-way merge: A merge that combines two branch histories using their common ancestor; if changes conflict, manual resolution is required before committing.
Rebase: Reapplies commits from one branch onto another base, creating a linear history; it rewrites commit hashes and should be avoided on shared branches.
Cherry-pick: Applies the changes introduced by a specific commit onto the current branch, creating a new commit with a different hash.
Annotated tag: A tag object that stores a message, tagger name, email, and date along with the commit reference; recommended for release marking.
Remote: A named reference to another repository URL, such as `origin`, used to fetch from and push to a shared or upstream repository.
git fetch: Downloads objects and refs from a remote repository and updates remote-tracking branches, but does not modify the working tree or current branch.
git pull: Fetches from a remote and integrates changes into the current branch, typically by merging; with `--rebase`, it rebases instead.
Upstream tracking branch: A local branch configured to track a remote branch, enabling `git pull` and `git push` without arguments; set with `git push -u`.
Merge request: A GitLab feature that requests merging a source branch into a target branch, enabling review, discussion, and CI checks before integration.
Force-with-lease: A safer force push option that only overwrites the remote branch if it still matches the local remote-tracking ref, preventing loss of others' work.
git remote prune: Removes remote-tracking branches that no longer exist on the remote; `git fetch --prune` performs the same cleanup during a fetch.
git log --oneline: Displays each commit on a single line with an abbreviated hash and commit message, providing a compact view of history.
git diff --staged: Shows differences between the staging area and the last commit (HEAD), revealing what would be included in the next commit.
git blame: Annotates each line of a file with the last commit hash and author that changed it, useful for tracing the origin of code.
git revert: Creates a new commit that applies the inverse of a specified commit's changes, safely undoing changes in shared history without rewriting it.
git reset --hard: Moves HEAD to a specified commit and discards all changes in the working tree and staging area; irreversible for uncommitted work.
git reflog: Records local movements of HEAD and branch tips, allowing recovery of commits that are no longer reachable from any branch.
git log -S: The pickaxe option that finds commits which added or removed a specific string, useful for locating when code was introduced.
git show: Displays the metadata and diff of a commit, tag, or other object; for a commit, it shows the changes introduced by that commit.
Fork: A personal copy of a repository under your own namespace, allowing you to propose changes to the original project via merge requests.
Protected branch: A GitLab branch setting that restricts pushes and merges, often requiring merge requests and approvals to prevent direct changes.
Squash and merge: A merge strategy that combines all commits from a merge request into a single commit on the target branch, simplifying history.
Merge request approval: A GitLab setting requiring a specified number of approvals before a merge request can be merged; approvals can reset on new commits.
Required pipeline: A CI/CD status check that must succeed before a merge request can be merged, ensuring code passes tests and builds.
Protected tag: A GitLab tag setting that controls who can create, delete, or modify tags, often used to secure release version tags.
Feature branch workflow: A branching strategy where each feature is developed on a dedicated branch created from main and merged back via a merge request.
Merge request discussion: A threaded comment on a merge request that can be resolved; unresolved threads can be configured to block merging.
Code review suggestion: A GitLab merge request feature allowing reviewers to propose exact code changes that authors can apply directly with one click.