Master Git: Visual Guide to Essential Commands and Workflows

Basic Usage

The four commands shown move files between the working directory, the staging area (index), and the repository. git add files – Add the specified files to the staging area. git commit – Create a snapshot of the staging area and record it as a commit. git reset – Undo the last git add; with no arguments it can clear the entire staging area. git checkout – Copy files from the staging area back to the working directory, discarding local changes.

You can enter interactive mode with git reset -p, git checkout -p, or git add -p.

It is also possible to skip the staging area and directly retrieve files from the repository or commit them.

git commit -a

– Stages all modified files and commits them in one step. git commit files – Commits the specified files, adding them to the staging area first. git checkout HEAD -- files – Reverts the specified files to the state of the last commit.

Conventions

Green five‑character IDs represent commit hashes; orange nodes indicate branches; the current branch is marked by HEAD. The diagram shows the last five commits, with ed489 as the latest on master, and another maint branch pointing to an older commit.

Command Details

Diff

Various methods exist to view changes between two commits; examples are illustrated below.

Commit

When committing, Git creates a new commit from the files in the staging area, sets the current commit as its parent, and moves the current branch pointer to the new commit.

If the current branch is an ancestor of another branch, Git still creates a new commit, after which a merge (or rebase) becomes necessary.

To amend the most recent commit, use git commit --amend, which creates a new commit with the same parent and discards the old one.

Checkout

The checkout command retrieves files from the repository or switches branches.

It copies files to the working directory and index; for example, git checkout HEAD~ foo.c restores foo.c from the parent of the current commit without moving the branch pointer.

If a branch name is given, Git switches to that branch and updates the index and working tree accordingly.

When neither a file nor a branch is specified, Git can check out a tag, remote branch, SHA‑1, or a relative reference like master~3, resulting in a detached HEAD state.

Detached HEAD Commits

When HEAD is detached, commits are created normally but do not update any named branch; they exist on an anonymous reference.

Switching to another branch discards the work unless a new branch is created first, e.g., git checkout -b name.

Reset

The reset command moves the current branch pointer and optionally updates the working directory and index.

Without options, it moves the branch; --hard also updates the working tree, while --soft leaves both unchanged.

If no commit is given, HEAD is used; the index rolls back to the last commit, and --hard also resets the working tree.

Providing a file name or -p makes reset behave similarly to checkout, but only the index is updated.

Merge

The merge command combines different branches. The index must match the current commit before merging.

If the other branch is an ancestor of the current commit, the merge does nothing; if the current commit is an ancestor of the other, a fast‑forward merge occurs.

Otherwise a true three‑way merge is performed, combining the current commit, the other commit, and their common ancestor.

Cherry‑Pick

git cherry-pick

copies a specific commit onto the current branch, creating a new identical commit.

Rebase

Rebase is an alternative to merge that reapplies commits from one branch onto another, producing a linear history; it can be seen as an automated cherry‑pick.

The commands are run on a topic branch and then replayed onto master, moving the branch pointer to the new commits; the original commits become unreferenced and are eventually garbage‑collected.

To limit the range, use the --onto option; for example, rebase the recent commits since 169a6 onto master.

Interactive rebase ( git rebase -i) allows you to drop, reorder, edit, or squash commits; see git-rebase(1) for details.

Technical Details

File contents are not stored directly in the index ( .git/index) or commit objects; instead they are saved as blobs in the object database ( .git/objects) and identified by SHA‑1 hashes. The index lists the relevant blob IDs and other metadata. Commits are stored as trees, which represent directories; trees contain other trees or blobs for subdirectories and files. Each commit records the hash of its parent tree.

When committing on a detached HEAD, the commit is referenced only by the reflog for HEAD and will eventually be pruned, similar to the effect of git commit --amend or git rebase.