Git

Each Git commit stores an ordered list of parent commit IDs: zero for a root commit, one for an ordinary commit, two or more for a merge. Following those pointers backwards yields a directed acyclic graph, not a straight line.

HEAD is a pointer to whatever you currently have checked out. Normally it is a symbolic ref holding the name of a branch, such as refs/heads/main, while the branch itself is a ref holding one commit hash.

In Git, HEAD~2 walks two steps back along the first-parent chain, i.e. the grandparent. HEAD^2 takes one step to the second parent, which exists only on a merge commit; on a non-merge it is an error.

In git log, main..feature lists commits reachable from feature but not from main. main...feature lists the symmetric difference: commits reachable from either side but not both. In git diff, three dots means something else — merge base against the right side.

A commit stores the hash of one tree (a full snapshot of the tracked files), the hashes of its parent commits, author and committer identity with timestamps, and the message. It stores no diff.

git commit --amend replaces the tip commit with a brand-new commit built from the current index, and --no-edit reuses the old message. A commit's name is a hash of its whole content, including the committer timestamp, so the replacement gets a new SHA.

A Git commit message is a short subject line, a blank line, then an optional body. The convention keeps the subject under about 50 characters and wraps body lines at 72. The blank line is the part Git itself depends on.

In modern Git, add -A stages new, modified and deleted paths across the whole working tree; add -u stages modifications and deletions for already-tracked paths only, never new files; add . does what -A does but limited to the current directory and below.

Git juggles three trees: the working tree (your files on disk), the index or staging area (the proposed next commit), and HEAD (the commit you are on). git add copies working tree into index; git commit turns the index into a commit.

git add -p walks the diff between your working tree and the index hunk by hunk and asks whether to stage each one. Only the accepted hunks enter the index, so one messy file can become several focused commits.

It writes one new ref holding the hash of the commit you branched from. No files are copied and no history is duplicated, which is why branching is instant in a repository of any size.

Git writes both versions of a region it could not merge into the file. Text between <<<<<<< and ======= is the side you are on; text between ======= and >>>>>>> is the incoming side. You edit the file to the final content, delete the markers, and stage it.

A fast-forward merge happens when the current branch's commit is already an ancestor of the commit being merged. Git records no merge commit; it simply moves the branch pointer forward and updates the index and working tree.

A three-way merge combines two branch tips using their best common ancestor, the merge base, as a reference point. Comparing each tip against that base tells Git which side changed what, so it can combine changes instead of guessing.

HEAD is detached when it names a commit directly instead of a branch, so commits you make advance nothing. Rescue them by creating a branch at that commit — git switch -c <name> before leaving, or git branch <name> <hash> from the reflog afterwards.

It applies that commit's change on top of your current branch and creates a new commit for it. The original commit stays where it is; the copy has a different SHA because its parent, committer and timestamp differ.

A forced push overwrites the remote branch pointer even when the new tip is not a descendant of the old one, so commits other people pushed can stop being reachable and everyone who already fetched the branch now has a history that diverges from it.

Git opens an editor holding a todo list of the three commits after HEAD~3, oldest first, each on a pick line. You edit the verbs and the order, save, and Git replays the commits as scripted, creating new commit IDs.

Merging adds a new commit that joins both histories and leaves your existing commits untouched. Rebasing re-creates your commits on top of main's tip as new commits with new hashes, producing a straight line with no merge commit.

A Git commit only adds a new snapshot. Every earlier commit still references the blob holding that file, so the content stays reachable and clonable until history itself is rewritten and the old objects are pruned.

git clone --depth 1 downloads only the tip commit of a single branch plus the trees and file contents needed to check it out. Older history and other branches are absent, so log and blame reach back one commit.

git fetch downloads new objects and updates remote-tracking refs such as origin/main, leaving your branch and working tree untouched. git pull runs that same fetch and then immediately integrates the result into your current branch by merging or rebasing.

By convention origin is your own fork, the copy you can push to, and upstream is the original project you forked from and normally only fetch from. Git gives neither name any special meaning.

Use git push origin --delete feature. The older equivalent, git push origin :feature, is a refspec with an empty source: pushing nothing onto the destination ref deletes it. Both remove only the remote branch, never your local one.

It only edits .git/config, adding a remote section with a url and a default fetch refspec. No network call happens and no objects arrive until you run git fetch, and the name origin is purely local.

Nothing was deleted: git reset --hard only moved the branch pointer. Find the old tip's hash with git reflog, verify it with git show, then re-anchor it using git branch rescue <hash> or git reset --hard <hash>.

git log walks commit ancestry from a ref, showing shared project history. git reflog lists a local journal of where HEAD or a branch has pointed over time, newest first, including commits no longer reachable from any branch.

Run git restore --staged <file>. It rewrites that path in the index from HEAD, leaving the file on disk exactly as you edited it. The older equivalent is git reset -- <file>.

Both restore a saved stash into your working tree; pop also deletes the stash entry afterwards, while apply leaves it in the list. If a pop hits a conflict, the entry is kept, so nothing is lost.

HEAD~2 is graph navigation: two commits back along parent links from the current commit. HEAD@{2} is reflog navigation: the commit HEAD pointed at two ref movements ago, regardless of ancestry.

git blame annotates every line of a file with the commit that last modified it, plus that commit's author and date. It shows only the most recent touch, never the line's full history, and it says nothing about deleted lines.

Plain git diff compares the working tree against the index, showing changes you have not staged yet. git diff --staged (identical to --cached) compares the index against HEAD, showing exactly what the next commit would contain.

In git log, --oneline prints one abbreviated-hash-plus-subject line per commit, --graph draws the commit DAG as ASCII art down the left margin, and --decorate appends the ref names — branches, tags, HEAD — that point at each commit.

git show prints one object: for a commit it prints the metadata and log message plus the patch against its first parent. git diff prints only a patch between two snapshots and never shows commit metadata.

List the reformatting commit's full id in a file and point Git at it: git blame --ignore-rev <sha>, or --ignore-revs-file <file>, or set blame.ignoreRevsFile so it applies automatically. Blamed lines are then attributed to the previous commit that touched them.

A non-zero exit from a pre-operation hook such as pre-commit, commit-msg or pre-push aborts the operation — no commit is created, no push is sent. Post-hooks like post-commit run afterwards and cannot abort anything.

They fire in that order during one git commit: pre-commit inspects the staged content before any message exists, prepare-commit-msg seeds or rewrites the message file before the editor opens, and commit-msg validates the final message. All three can abort by exiting non-zero.

Hooks live in .git/hooks, part of the repository metadata that is never committed, so a clone never copies them. Teams instead commit hook scripts to a tracked directory and point Git at it with the core.hooksPath config setting.

pre-receive runs once per push and reads every proposed ref update on stdin, so a non-zero exit rejects the whole push. update runs once per ref with the ref name and old and new object names as arguments, and rejecting there blocks only that one ref.

lint-staged runs the commands you configure only against the files currently staged in Git's index, not the whole project. That keeps a pre-commit hook proportional to the change, so it finishes fast and only reports problems in code you touched.

A plain clone fetches only the superproject, which records submodules as commit references rather than files, so it creates the directories but leaves them empty. Clone with --recurse-submodules, or run git submodule update --init --recursive afterwards.

It creates an additional working directory with its own checked-out branch, backed by the same repository. Unlike a second clone it shares one object database and one set of branches, so it costs no extra fetch and no duplicated history.

Only a commit SHA. The parent's tree holds a special gitlink entry, mode 160000, recording which commit of the other repository belongs at that path. The URL to fetch it from lives separately, in the tracked .gitmodules file.

Subtree stores the dependency's actual files in your repository, so a plain clone builds immediately; submodules store only a pinned pointer, so consumers need an extra recursive step. Subtree costs repository size and a mixed history.

Objects, refs, remotes and repository config are shared by all worktrees. Each worktree keeps its own working directory, index, HEAD, HEAD reflog and in-progress operation state, stored in .git/worktrees/<name> inside the original repository.

Git Flow defines two permanent branches, main and develop, plus three temporary types: feature branches cut from develop, release branches cut from develop, and hotfix branches cut from main. Releases and hotfixes merge back into both permanent branches.

A plain git push sends branch refs only; tags live in refs/tags and are excluded by the default refspec. Push one explicitly with git push origin v1.4.0, or push a branch plus its reachable annotated tags with git push --follow-tags.

Trunk-based development means everyone integrates into one shared branch — the trunk, usually main — continuously. Branches off it are short-lived, typically merged back within a day or two, so the repository never accumulates long-running parallel lines of development.

git format-patch writes one mbox-formatted file per commit, containing the message plus the diff and author metadata. A maintainer replays them with git am, which recreates the commits with their original author, date and message rather than just applying a diff.

Make each commit one self-contained step that builds and passes tests on its own: preparation and refactoring first, behaviour change second, then tests and docs. Order them so a reviewer reading top to bottom sees the change being argued, not assembled.

They name three config files: machine-wide, per-user, and per-repository. Git reads them in that order and the narrower scope wins, so a repository's .git/config overrides your home-directory settings, which override the system file.

Git ignore rules apply only to untracked paths. Once a file has an entry in the index, Git keeps reporting and committing its changes whatever .gitignore says. Untrack it with git rm --cached, then commit that removal.

The file's line endings switched between LF and CRLF. Git compares whole lines, so an invisible carriage return at the end of every line makes every line differ and the whole file looks rewritten.

A .gitattributes file assigns per-path attributes that change how Git diffs, merges, filters and archives matching files. Patterns use .gitignore syntax; within one file the last matching line wins, and .git/info/attributes outranks committed files.

A leading slash anchors a Git ignore pattern to the directory holding the .gitignore instead of matching at any depth. A trailing slash restricts the match to directories. Double asterisk matches across directory separators, which a single asterisk never does.