GitLab Git Associate key terms

A directory tracked by Git that stores project files plus the complete history of every committed change, kept in a hidden .git folder at its root.

An immutable snapshot of the tracked files at one point in time, identified by a SHA hash and linked to its parent commit, forming the project history.

The 40-character hexadecimal hash Git computes for each object; the first 7 to 12 characters usually identify a commit unambiguously in commands.

The checked-out files on disk that you edit, which may differ from the last commit until you stage and commit changes.

Also called the index; a holding area where selected changes are prepared with git add before being recorded in the next commit.

A movable pointer to a commit that lets you develop work in isolation; creating one is cheap and does not copy files.

A reference pointing to the commit currently checked out, usually by pointing at the current branch; a detached HEAD points directly at a commit instead.

The operation of switching the working tree to another branch or commit, updating files on disk to match the target.

Combining the histories of two branches by creating a merge commit with two parents, or by fast-forwarding when no divergence exists.

A merge where the target branch simply moves forward to the source commit because no new commits exist on the target since divergence.

A state where two branches changed the same lines of a file, so Git cannot merge automatically and requires manual resolution before committing.

Replaying a branch's commits onto a new base commit to produce a linear history, rewriting the commit hashes of the replayed commits.

A named reference to another copy of the repository, usually on a server such as GitLab, used for fetching and pushing commits.

The default name Git gives to the remote from which a repository was cloned; it is a convention, not a reserved keyword.

Copying a remote repository to your machine, including its history, and setting up a remote named origin with tracking branches.

Downloading new commits and refs from a remote into local remote-tracking branches without changing your working tree or current branch.

Fetching from a remote and then integrating the downloaded commits into the current branch, by merge by default or by rebase when configured.

Uploading local commits to a remote branch so other collaborators can see them; rejected if the remote has commits you do not have.

Overwriting a remote branch with your local history using --force or --force-with-lease, which can discard others' commits and is risky on shared branches.

A local branch linked to a remote branch, so git pull and git push work without naming the remote and branch each time.

GitLab's proposal to merge one branch into another, providing review, discussion threads, pipelines, and approval controls before the merge happens.

A server-side copy of a repository under another namespace, commonly used to contribute to projects where you lack push access to the source.

The command that lists commits reachable from a ref, showing hashes, authors, dates, and messages; options control format and graph layout.

A line-by-line comparison between two states of files or commits, showing added and removed lines with surrounding context.

Annotating each line of a file with the commit, author, and date that last changed it, useful for tracing the origin of a specific line.

A named pointer to a commit used to mark releases; lightweight tags are just refs, while annotated tags store a message, tagger, and date.

Creating a new commit that undoes the changes of an earlier commit, preserving history and safe to use on shared branches.

Moving the current branch pointer to another commit; soft keeps changes staged, mixed unstages them, and hard discards working tree changes.

Temporarily saving uncommitted changes so the working tree becomes clean, allowing you to switch context and reapply the changes later.

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

A GitLab branch rule that restricts who can push or merge, often requiring merge requests, approvals, and passing pipelines before changes land.

The practice of examining proposed changes in a merge request, leaving comments and approvals, to catch defects and share knowledge before merging.

A short-lived branch created from a shared base to develop one change or feature, then merged back through a merge request.

A branching model using long-lived main and develop branches plus feature, release, and hotfix branches, suited to scheduled releases.

A strategy where developers integrate small changes into a single main branch frequently, using short-lived branches and feature flags to reduce merge risk.

Combining several commits into one before merging, producing a single tidy commit on the target branch while keeping the source history intact.

A file listing patterns for paths Git should not track, such as build output, secrets, and dependency folders, keeping the repository clean.