Per-Arne's Git Good!Glossary
The terms the course uses, in the order the course introduces them. Commands are in the command reference.
| Term | Meaning | Introduced in |
|---|---|---|
| repository | The database holding the whole history, all objects and refs, in the .git folder, usually together with a working tree. A bare repository has no working tree. |
What is Git? Snapshots and your first commit |
| commit | A stored snapshot of the project with author, time, message and parent. A commit never changes; to “change” one is to make a new one. | What is Git? Snapshots and your first commit |
| snapshot | The complete state of every tracked file in a commit, not just the difference from the previous one. Unchanged files are not stored again but reused. | What is Git? Snapshots and your first commit |
| parent | The commit a commit builds on. The first commit has none, an ordinary commit has one and a merge commit two or more. The chain of parents is the history. HEAD~1 and HEAD^ are the first parent of HEAD. |
What is Git? Snapshots and your first commit |
| working tree | The files you see and edit on disk. Changes here do not become part of the history until they are staged and committed. | Three areas: working tree, staging area and HEAD |
| staging area (index) | The draft of the next commit: the version of each tracked file that the next commit will record. git add copies the file's current version there; later edits must be staged again. |
Three areas: working tree, staging area and HEAD |
| tracked / untracked file | A tracked file is in the staging area, and so in the next commit. An untracked file exists only in the working tree; Git keeps no copy of its current content until you run git add. |
Three areas: working tree, staging area and HEAD |
| HEAD | Where you are: usually a pointer to the current branch, which in turn points at a commit. The next commit gets HEAD's commit as its parent. | Three areas: working tree, staging area and HEAD |
| .gitignore | A file of patterns for untracked files that Git should leave alone, such as build output, logs and files with secrets, before they are ever committed. It does not affect files that are already tracked, and removes nothing that is already committed. | Good commits: small, intentional and well described |
| commit ID (hash) | The name of a commit: a hash (40 hexadecimal characters by default, often shown abbreviated) computed from the snapshot, parents, author, time and message. Change any of these and you get a different commit with a new ID. | Reading history: log, show and the objects behind them |
| branch | A movable name that points at one commit, not a copy of the files. When you commit on the branch, it moves to the new commit. | Branches and HEAD: pointers, not copies |
| detached HEAD | HEAD points straight at a commit instead of at a branch, for example after git switch --detach. Commits you make there have no branch; give them one with git switch -c before you switch away. |
Branches and HEAD: pointers, not copies |
| merge | Integrating another branch into the one you are on with git merge. The result is either a fast-forward or a new merge commit. |
Fast-forward: when merge only moves a pointer |
| fast-forward | A merge where the branch you are on is an ancestor of the other, so Git only moves the pointer forward. No new commit is made. --no-ff forces a merge commit. |
Fast-forward: when merge only moves a pointer |
| merge commit | A commit with more than one parent, usually two, that joins two lines of work. When HEAD is a merge commit, HEAD^1 is the commit you were on and HEAD^2 the tip you merged in. |
Three-way merge: when both lines have moved |
| merge base | The best common ancestor of two commits, usually where the lines parted. A three-way merge compares both sides with it. Found with git merge-base. |
Three-way merge: when both lines have moved |
| conflict | Git stops because it cannot combine the two sides by itself, typically because both changed the same or adjacent lines since the merge base. You decide the content, remove the markers, run git add and finish, or abort with git merge --abort. |
Conflicts without panic |
| tag (lightweight / annotated) | A fixed name for one commit, typically a release; it does not move when you commit. A lightweight tag is just the name. An annotated tag (git tag -a) is an object of its own with tagger, date and message, and suits releases. |
Tags: fixed names for important versions |
| remote | Another repository, usually with related history, which you fetch from and publish to. Stored as a short name with an address; list them with git remote -v. |
Remotes and clone: three things called main |
| origin | The name git clone gives the remote you cloned from. A local nickname for the address, not the server itself. |
Remotes and clone: three things called main |
| clone | git clone copies a repository with its whole history, names the source origin, creates remote-tracking branches and checks out the default branch. |
Remotes and clone: three things called main |
| remote-tracking branch (remote-tracking ref) | Your local record of where a branch in the remote was the last time you talked to it, for example origin/main. Fetch, pull and push move it, never someone else's push, and you do not commit on it. |
Remotes and clone: three things called main |
| upstream | The branch a local branch follows, usually a remote-tracking branch, for example origin/main for main. git pull and git push use it by default, and git status counts ahead and behind against it. Set with git push -u or git branch -u. |
Remotes and clone: three things called main |
| fetch | git fetch downloads new commits from the remote and moves the remote-tracking branches. Your branches, staging area and working tree stay as they are. |
Fetch, pull and push: keeping in step with the team |
| pull | git pull is a fetch followed by integrating the upstream into the branch you are on: by merge (--no-rebase), rebase (--rebase) or fast-forward only (--ff-only). |
Fetch, pull and push: keeping in step with the team |
| push | git push sends commits to the remote and moves the branch there. It is accepted only as a fast-forward; otherwise it is rejected, and you must fetch and integrate first. A forced push overwrites other people's commits. |
Fetch, pull and push: keeping in step with the team |
--force-with-lease |
A git push option that overwrites the remote branch only if it is still where your remote-tracking branch says. After a fetch it matches anyway, so it suits only your own rewritten branch, never a shared one. |
Fetch, pull and push: keeping in step with the team |
| pull request | A feature of a hosting service such as GitHub, not of Git: a request to review a published branch and merge it into another. GitLab calls it a merge request. | Team workflow: feature branches, pull requests and agreements |
| restore | git restore FILE copies the file from the staging area into the working tree. With --staged the HEAD version goes into the staging area, and with --source a version from another commit. No branch moves. |
Undo in your files: git restore |
reset (--soft / --mixed / --hard) |
git reset COMMIT moves the branch you are on to another commit. --soft keeps the staging area and working tree, --mixed (the default) resets the staging area, and --hard also resets the working tree, discarding uncommitted changes in tracked files. |
Move the branch back: git reset |
| revert | git revert COMMIT makes a new commit that undoes the change of an earlier commit. No history is rewritten, so it suits shared history. |
Undo shared history: git revert |
| rebase | git rebase replays your commits on top of a new base. The copies get new IDs, and the branch no longer points at the originals. Only for commits nobody else has. |
Rebase: replay your work on a new base |
| ORIG_HEAD | A ref that reset, merge and rebase set to where HEAD was before the operation. git diff ORIG_HEAD HEAD shows what the operation changed, and git reset --hard ORIG_HEAD moves the branch back there, discarding uncommitted changes. |
Rebase: replay your work on a new base |
| interactive rebase | git rebase -i lets you edit the plan before the commits are replayed: reorder, reword, squash, fixup or drop. Used to tidy private history before you share it. |
Interactive rebase: tidy up before you share |
| reflog | A local log of where HEAD and each branch have pointed, for example HEAD@{1}. It lets you find commits that no branch points at any more. Entries expire (after 30 or 90 days by default) and do not travel with a clone or push, so the reflog is not a backup. |
Reflog: rescue work that looks lost |
| stash | A local shelf where git stash push sets uncommitted changes to tracked files aside, so the tracked files match the last commit again; untracked files only with -u. git stash pop brings them back and drops the entry if they applied without conflict, git stash apply keeps it. |
Stash: set unfinished work aside |
| cherry-pick | git cherry-pick COMMIT copies the change from one commit onto the branch you are on, as a new commit with a new ID. -x writes the original ID into the message. |
Cherry-pick: copy one commit |
| bisect | git bisect binary-searches between a known good and a known bad commit to find the first bad one, either with you answering good or bad, or automatically with git bisect run. |
Bug hunting: log -S, blame and bisect |
| blame | git blame FILE shows, for each line, which commit last changed it, with author and date. The answer says where the line last changed, not who is to blame for a bug. |
Bug hunting: log -S, blame and bisect |
| worktree | An extra working tree attached to the same repository (git worktree add), so two branches can be checked out at once. Git refuses to check out the same branch in two worktrees. |
Worktrees and bigger projects |
| hook | A script Git runs at an event, such as pre-commit or pre-push. Hooks live locally in .git/hooks, are not cloned and can be skipped, so rules the team must rely on are enforced on the server. |
Worktrees and bigger projects |