Appendix 1
Glossary

• ^: Adding a caret to any commit name (a commit ID, branch name, or tag) tells Git to use that commit, minus one. You can add multiple carets: HEAD^^ means HEAD minus two, and so on.

• ~#: The tilde followed by a number is used with a commit name (a commit ID, branch name, or tag) to specify the commit located at that point minus the number: HEAD~2 means two commits before HEAD, and so on.

• amend: Applies the commit that is being made to the previous commit to amend it.

• bare repository: A repository without a working tree. Generally used for repositories that are meant to be pushed and pulled to and from.

• blame: An annotated view of a file (or portion of a file) that shows what commit a change was made in, when that commit happened, and who made it.

• branch: A separate line of history within the repository stored as a pointer to a particular commit.

• check out or checkout: The act of taking a branch or files from the repository and checking it out into the working tree.

• cherry-pick: Taking one commit and applying it to the current branch.

• commit: The individual points in time that your repository tracks. Each commit in Git tracks who made it, when it was made, the changes that were made, and what commit (or commits) are its direct parents.

• commit ID: The ID for each commit is an SHA-1 hash based on the data that makes up a commit. Any change to the commit causes a different commit ID to be generated. Each commit provides its own integrity check through its ID.

• commit message: A plain-text message that is stored with the commit. It is used to convey what the commit did and why. By convention, Git breaks commit messages into two parts. The first line is considered the subject, followed by an empty line, followed by the body of the commit message.

• conflict: See merge conflict.

• diff: Describes the differences between two (or more) versions of a file or files.

• fast-forward merge: A merge that moves the pointer of a branch to another point in the future without creating a merge commit.

• fetch: Retrieving commits from a remote repository and storing them in the local repository.

• HEAD: The latest point in your repository that your working tree currently points to.

• index: See staging area.

• interactive rebase: Same as rebase, except Git pauses before the rebase is started and allows you to modify the commits that are being applied, modify the order in which they are applied, and specify which commits should be stopped at so they can be edited.

• log: A reverse chronological output of all the commits that, by default, include the committer, commit date, commit ID, and commit message.

• master: Refers to the name of the default branch where the majority of development happens in Git.

• merge: Bringing the contents of two separate branches into sync by merging them together. This can happen by any number of merge strategies, the most common of which are a fast-forward merge and a recursive merge.

• merge commit: A commit with multiple parents used to signify a merging of two or more branches. Merge commits are generally created by recursive merges.

• merge conflict: A conflict that happens when two commits attempt make changes that cannot be reconciled by automated means. This generally happens during a merge or while replaying commits during a rebase.

• non-fast-forward merge: See recursive merge.

• ORIG_HEAD: Refers to the location of HEAD before making any changes bigger than a simple commit, such as running git rebase, git reset, or git merge.

• origin: The default name for your main remote repository.

• patch: The differences between two states of a file along with metadata explaining which file or files were modified.

• patch mode: An interactive mode of staging files via git add or git stash that allows you to stage portions of the change rather than the entire file.

• pull: The act of fetching changes from a remote repository and merging them into your local branch via git pull. This can be done with a standard merge or via a rebase.

• push: The act of sending commits to a remote repository. Generally used when sending your changes to a repository that others can access.

• rebase: Replaying one or more commits on top of another point in the history of the repository. Generally used between branches, often where the point you are rebasing against is a remote branch.

• recursive merge: A merge where a merge commit is created.

• reflog: A log of all changes to the point of a branch (for example, new commits, checkouts, rebases, and so on). Useful for fixing bad rebases.

• refspec: References to a particular point inside the repository. Used to refer to branches, it follows the <source>:<destination> schema. Normally used with git pull and git push. When pulling, the source is the remote branch, and the destination is the local branch; when pushing, the source is the local branch, and the destination is the remote branch.

• remote: Shorthand for remote repository, which refers to repositories other than your own local one.

• repository: The place where all your codes and the changes to it—commits—live.

• revert: A reverse commit, used to track when a commit was undone.

• revision: A particular commit, identified by a commit ID. See commit and commit ID.

• stage: To add a one or more changes to the staging area to be committed.

• staging area: The place that sits between the repository and your working tree. You must stage your changes here before they are committed to the repository.

• stash: To put all changes in the working tree into a temporary holding area to be reapplied or discarded later. Useful when running rebase, which requires a clean working tree.

• tag: A mark of significance within the repository when used as a noun. The act of creating a tag when used as a verb.

• working tree: Your copy of a particular point in the repository’s history—normally the very last commit, or HEAD—that exists on the file system. This is where you edit the files in your project.