GitLab Git Associate cheat sheet

A commit is an immutable snapshot identified by a SHA-1 hash; HEAD points to the current branch tip, which references the latest commit.

The three areas are working tree, staging area (index), and repository; git add moves changes to the index, git commit records the index as a new commit.

Branches are lightweight movable pointers to commits; git branch <name> creates a pointer at HEAD, and git switch <name> or git checkout <name> moves HEAD.

A merge combines histories: fast-forward when the target is an ancestor of the source; otherwise a three-way merge creates a merge commit with two parents.

Merge conflicts occur when both branches modify the same lines; resolve by editing files, git add resolved files, then git commit (or git merge --continue).

git rebase <upstream> replays commits onto a new base, producing a linear history; never rebase commits already pushed to a shared branch.

git commit --amend replaces the most recent commit; it changes the commit hash and should be used only on unpushed commits.

git cherry-pick <commit> applies the changes from a specific commit onto the current branch, creating a new commit with a different hash.

A tag is a static reference to a commit; annotated tags (git tag -a) store metadata and are recommended for releases, while lightweight tags are just pointers.

git remote add <name> <url> registers a remote; origin is the default name for the clone source, and git remote -v lists remotes with fetch/push URLs.

git fetch <remote> downloads new commits and updates remote-tracking branches (e.g., origin/main) without modifying the working tree.

git pull is git fetch followed by git merge (or --rebase if configured); use git pull --rebase to avoid merge commits in linear workflows.

git push <remote> <branch> uploads local commits; the first push needs -u to set upstream tracking, after which plain git push works.

A pull request (GitHub/Bitbucket) or merge request (GitLab) is a request to merge a source branch into a target branch, enabling review and discussion before integration.

In GitLab, merge requests require a source branch and target branch; the source branch is typically a feature branch and the target is usually main or develop.

git push --force-with-lease is safer than --force because it refuses to overwrite remote work that you have not fetched; use it only on your own feature branches.

git remote prune origin or git fetch --prune removes stale remote-tracking branches that no longer exist on the remote.

git log shows commit history; useful options include --oneline, --graph, --decorate, and -n <count> to limit output.

git diff compares working tree to index; git diff --staged compares index to HEAD; git diff <commit1> <commit2> compares two commits.

git blame <file> shows the last commit and author for each line; use -L <start>,<end> to limit the range and -w to ignore whitespace changes.

git show <commit> displays the commit metadata and diff; git show <tag> shows the tagged commit.

git revert <commit> creates a new commit that undoes the changes of the specified commit; it is safe for shared history because it does not rewrite history.

git reset --soft <commit> moves HEAD but keeps changes staged; --mixed (default) unstages changes; --hard discards working tree and index changes, so use with caution.

git reflog records local HEAD movements and can recover commits lost by reset or branch deletion, even if they are no longer reachable from any branch.

git tag lists tags; git tag -d <tag> deletes a local tag, and git push origin --delete <tag> deletes a remote tag.

git log --follow <file> tracks history across renames, and git log -S<string> (pickaxe) finds commits that added or removed a specific string.

A fork is a personal copy of a repository under your namespace; changes are proposed back to the upstream project via merge requests from the fork.

Protected branches in GitLab restrict who can push or merge; common settings allow no direct pushes to main and require merge requests with approvals.

GitLab merge request approvals can require a minimum number of approvers and can be configured to reset approvals when new commits are pushed.

A common GitLab flow uses feature branches created from main, merged via merge request after review and passing CI, then deleted.

GitLab CI/CD pipelines run on merge requests and branches; required status checks can block merging until pipelines succeed.

Squash and merge combines all commits from a merge request into a single commit on the target branch, keeping history clean.

Merge request discussions can be resolved; unresolved threads can be configured to block merging.

Protected tags prevent deletion or modification of release tags; use them to secure version tags.

Code review in GitLab includes line-by-line comments, suggestions (which can be applied directly), and a merge request checklist.