Fundamentals 14 min read

Master Git Basics: Visual Guide to Core Commands and Workflows

This article provides a comprehensive visual guide to Git's most common commands—add, commit, reset, checkout, merge, rebase, cherry‑pick, and more—explaining how they move files between the working directory, index, and repository while illustrating concepts such as HEAD, detached HEAD, and the underlying blob/tree storage model.

MaGe Linux Operations

Feb 4, 2021

Master Git Basics: Visual Guide to Core Commands and Workflows

Basic Usage

This article illustrates the most frequently used Git commands. If you have a basic understanding of Git's workflow, the visual explanations will deepen your comprehension.

Core Commands

The four commands below copy files among the working directory, staging area (also called the index), and repository.

git add files – adds the current files to the staging area.

git commit – creates a snapshot from the staging area and records it as a commit.

git reset – files – undoes the last git add files; git reset without arguments clears all staged files.

git checkout – files – copies files from the staging area back to the working directory, discarding local modifications.

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, retrieving files directly from the repository or committing directly.

Conventions

In the following sections, images are used to illustrate concepts.

Green five‑character strings represent commit IDs and point to parent nodes. Orange blocks indicate branches, each pointing to a specific commit. The current branch is marked with a HEAD label. The diagram shows the last five commits, with ed489 as the latest; master points to this commit, while another maint branch points to an older parent commit.

Command Details

Diff

There are many ways to view changes between two commits; the following image shows an example.

Commit

When committing, Git creates a new commit from the files in the staging area and sets the current node as its parent. The current branch is then moved to point to the new commit. In the diagram, master originally points to ed489; after the commit it points to f0cec, whose parent is ed489.

If the current branch is an ancestor of another branch, Git still creates a new commit. In the example, a commit on the maint branch (ancestor of master) creates 1800b, after which maint is no longer an ancestor of master. A merge is then required.

To amend a commit, use git commit --amend. Git creates a new commit with the same parent as the current one and discards the old commit.

Another example is a detached HEAD commit (see below).

Checkout

The checkout command copies files from a historical commit (or the staging area) to the working directory and can also switch branches.

When a file name is provided (or the -p option is used), Git copies the file from the specified commit to both the staging area and the working directory. For example, git checkout HEAD~ foo.c copies foo.c from the parent of the current commit to the working directory and stages it. If no commit is specified, the content is taken from the staging area, and the current branch does not change.

If a branch name is given instead of a file, the HEAD pointer moves to that branch, the working directory and index are updated to match the commit pointed to by HEAD, and any files that exist only in the previous commit are removed.

If neither a file nor a branch is specified but a tag, remote branch, SHA‑1, or a notation like master~3 is used, Git creates an anonymous branch called a detached HEAD. This allows easy switching between historical versions, e.g., git checkout v1.6.6.1 to build a specific release, then returning to master. Commits made while HEAD is detached update an unnamed branch and are not referenced by any named branch.

HEAD Detached Commit

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

If you later switch to another branch (e.g., master), the commit may become unreferenced and eventually be garbage‑collected. To preserve it, create a new branch with git checkout -b name.

Reset

The reset command moves the current branch to another commit and optionally updates the working directory and index. Without options, the branch pointer moves; with --hard the working directory is also updated, and with --soft nothing changes.

If no commit is specified, HEAD is used. By default the branch stays the same but the index is rolled back to the last commit; with --hard the working directory is also rolled back.

If a file name (or -p) is given, the effect is similar to checkout with the index updated.

Merge

The merge command combines different branches. Before merging, the index must match the current commit. 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 branch, a fast‑forward merge occurs, simply moving the branch pointer and creating a new commit.

Otherwise a true three‑way merge is performed: Git saves the current directory and index, then merges the current commit, the other commit, and their common ancestor into a new commit.

Cherry‑Pick

The cherry-pick command copies a specific commit and creates an identical new commit on the current branch.

Rebase

Rebase is an alternative to merge. While merge creates a non‑linear history, rebase replays the commits of another branch onto the current branch, producing a linear history. Conceptually, it is an automated series of cherry‑picks.

All the commands above are executed on a topic branch, not directly on master. After rebasing, the branch pointer moves to the new commits, and the old commits become unreferenced and may be garbage‑collected.

To limit the range of a rebase, use the --onto option. The example rebases the recent commits from 169a6 onto master, resulting in commit 2c33a.

Interactive rebase ( git rebase -i) allows you to drop, reorder, edit, or squash commits conveniently.

Technical Details

File contents are not stored directly in the index ( .git/index) or commit objects; they are stored as blobs in the object database ( .git/objects) and identified by SHA‑1 hashes. The index lists the relevant blob files and other data. Commits store a tree object, which represents the directory hierarchy; each tree contains sub‑trees or blobs corresponding to sub‑directories and files. Every commit records the hash of its parent tree.

If a commit is made while HEAD is detached, the last commit is referenced only by the reflog for HEAD and will eventually be pruned, similar to git commit --amend or git rebase.