Git and GitHub

changeset

BitKeeper/cvsps speak for "commit". Since Git does not store changes, but states, it really does not make sense to use the term "changesets" with Git.

plumbing

Cute name for core Git.

porcelain

Cute name for programs and program suites depending on core Git, presenting a high level access to core Git. Porcelains expose more of a SCM interface than the plumbing.

DAG

Directed acyclic graph. The commit objects form a directed acyclic graph, because they have parents (directed), and the graph of commit objects is acyclic (there is no chain which begins and ends with the same object).

hook

During the normal execution of several Git commands, call-outs are made to optional scripts that allow a developer to add functionality or checking. Typically, the hooks allow for a command to be pre-verified and potentially aborted, and allow for a post-notification after the operation is done. The hook scripts are found in the $GIT_DIR/hooks/ directory, and are enabled by simply removing the .sample suffix from the filename. In earlier versions of Git you had to make them executable.

tree

Either a working tree, or a tree object together with the dependent blob and tree objects (i.e. a stored representation of a working tree).

Enterprise account

Enterprise accounts allow you to centrally manage policy and billing for multiple GitHub.com organizations. Enterprise accounts are available with GitHub Enterprise Cloud. For more information, see "About enterprise accounts."

fetch

Fetching a branch means to get the branch's head ref from a remote repository, to find out which objects are missing from the local object database, and to get them, too. See also git-fetch(1).

Fetch

Fetching refers to getting the latest changes from an online repository without merging them in. Once these changes are fetched you can compare them to your local branches (the code residing on your local machine).

core Git

Fundamental data structures and utilities of Git. Exposes only limited source code management tools.

Git

Git is an open source program for tracking changes in text files, and is the core technology that GitHub, the social and user interface, is built on top of.

grafts

Grafts enables two otherwise different lines of development to be joined together by recording fake ancestry information for commits. This way you can make Git pretend the set of parents a commit has is different from what was recorded when the commit was created. Configured via the .git/info/grafts file. Note that the grafts mechanism is outdated and can lead to problems transferring objects between repositories; see git-replace(1) for a more flexible and robust system to do the same thing.

hash

In Git's context, synonym for object name.

cherry-picking

In SCM jargon, "cherry pick" means to choose a subset of changes out of a series of changes (typically commits) and record them as a new series of changes on top of a different codebase. In Git, this is performed by the "git cherry-pick" command to extract the change introduced by an existing commit and to record it based on the tip of the current branch as a new commit.

Issue

Issues are suggested improvements, tasks or questions related to the repository. Issues can be created by anyone (for public repositories), and are moderated by repository collaborators. Each issue contains its own discussion forum, can be labeled and assigned to a user.

What is a pathspec has only a colon?

It means "there is no pathspec". This form should not be combined with other pathspec.

file system

Linus Torvalds originally designed Git to be a user space file system, i.e. the infrastructure to hold files and directories. That ensured the efficiency and speed of Git.

Markdown

Markdown is a simple semantic file format, not too dissimilar from .doc, .rtf and .txt. Markdown makes it easy for even those without a web-publishing background to write prose (including with links, lists, bullets, etc.) and have it displayed like a website. GitHub supports Markdown, and you can learn about the semantics.

Merge

Merging takes the changes from one branch (in the same repository or from a fork), and applies them into another. This often happens as a pull request (which can be thought of as a request to merge), or via the command line. A merge can be done automatically via a pull request via the GitHub web interface if there are no conflicting changes, or can always be done via the command line. For more information, see "Merging a pull request."

shallow clone

Mostly a synonym to shallow repository but the phrase makes it more explicit that it was created by running git clone --depth=... command.

detached HEAD

Normally the HEAD stores the name of a branch, and commands that operate on the history HEAD represents operate on the history leading to the tip of the branch the HEAD points at. However, Git also allows you to check out an arbitrary commit that isn't necessarily the tip of any particular branch. The HEAD in such a state is called "detached".

object type

One of the identifiers "commit", "tree", "tag" or "blob" describing the type of an object.

overlay

Only update and add files to the working directory, but don't delete them, similar to how cp -R would update the contents in the destination directory. This is the default mode in a checkout when checking out files from theindex or a tree-ish. In contrast, no-overlay mode also deletes tracked files not present in the source, similar to rsync --delete.

Open source

Open source software is software that can be freely used, modified, and shared (in both modified and unmodified form) by anyone. Today the concept of "open source" is often extended beyond software, to represent a philosophy of collaboration in which working materials are made available online for anyone to fork, modify, discuss, and contribute to. For more information on open source, specifically how to create and grow an open source project, we've created Open Source Guides that will help you foster a healthy open source community. You can also take a free GitHub Learning Lab course on maintaining open source communities.

Organization

Organizations are shared accounts where businesses and open-source projects can collaborate across many projects at once. Owners and administrators can manage member access to the organization's data and projects with sophisticated security and administrative features.

pathspec

Pattern used to limit paths in Git commands. Pathspecs are used on the command line of "git ls-files", "git ls-tree", "git add", "git grep", "git diff", "git checkout", and many other commands to limit the scope of operations to some subset of the tree or worktree. See the documentation of each command for whether paths are relative to the current directory or toplevel.

Private repository

Private repositories are repositories that can only be viewed or contributed to by their creator and collaborators the creator specified.

pseudoref

Pseudorefs are a class of files under $GIT_DIR which behave like refs for the purposes of rev-parse, but which are treated specially by git. Pseudorefs both have names that are all-caps, and always start with a line consisting of aSHA-1 followed by whitespace. So, HEAD is not a pseudoref, because it is sometimes a symbolic ref. They might optionally contain some additional data. MERGE_HEAD and CHERRY_PICK_HEAD are examples. Unlike per-worktree refs, these files cannot be symbolic refs, and never have reflogs. They also cannot be updated through the normal ref update machinery. Instead, they are updated by directly writing to the files. However, they can be read as if they were refs, so git rev-parse MERGE_HEAD will work.

Pull

Pull refers to when you are fetching in changes and merging them. For instance, if someone has edited the remote file you're both working on, you'll want to pull in those changes to your local copy so that it's up to date.

Pull request

Pull requests are proposed changes to a repository submitted by a user and accepted or rejected by a repository's collaborators. Like issues, pull requests each have their own discussion forum. For more information, see "About pull requests."

pull

Pulling a branch means to fetch it and merge it. See also git-pull(1).

push

Pushing a branch means to get the branch's head ref from a remote repository, find out if it is an ancestor to the branch's local head ref, and in that case, putting all objects, which are reachable from the local head ref, and which are missing from the remote repository, into the remote object database, and updating the remote head ref. If the remote head is not an ancestor to the local head, the push fails.

Push

Pushing refers to sending your committed changes to a remote repository, such as a repository hosted on GitHub. For instance, if you change something locally, you'd want to then push those changes so that others may access them.

per-worktree ref

Refs that are per-worktree, rather than global. This is presently only HEAD and any refs that start with refs/bisect/, but might later include other unusual refs.

SSH key

SSH keys are a way to identify yourself to an online server, using an encrypted message. It's as if your computer has its own unique password to another service. GitHub uses SSH keys to securely transfer information to your computer.

SCM

Source code management (tool).

Status checks

Status checks are external processes, such as continuous integration builds, which run for each commit you make in a repository. For more information, see "About status checks."

object database

Stores a set of "objects", and an individual object is identified by its object name. The objects usually live in $GIT_DIR/objects/.

symref

Symbolic reference: instead of containing the SHA-1 id itself, it is of the format ref: refs/some/thing and when referenced, it recursively dereferences to this reference. HEAD is a prime example of a symref. Symbolic references are manipulated with the git-symbolic-ref(1) command.

revision

Synonym for commit (the noun).

object identifier

Synonym for object name.

Git archive

Synonym for repository (for arch people).

Team

Teams are groups of organization members that reflect your company or group's structure with cascading access permissions and mentions.

Blame

The "blame" feature in Git describes the last modification to each line of a file, which generally displays the revision, author and time. This is helpful, for example, in tracking down when a feature was added, or which commit led to a particular bug.

explore

The Explore link takes you to a list of things you may be interested in. You may find events and opportunities that GitHub hosts or supports. For example, at the time we wrote this book, GitHub just released "The State of the Octoverse," which presents a lot of interesting analytics about code on GitHub — for example, GitHub users made 1.1 billion contributions in 2018!

account menu

The account menu appears when you click on your avatar. Here, you can get to your profile, repositories, anything you've starred, gists you've created, the help documents, and settings and can sign out.

resolve

The action of fixing up manually what a failed automatic merge left behind.

commit, as a verb

The action of storing a new snapshot of the project's state in the Git history, by creating a new commit representing the current state of the index and advancing HEAD to point at the new commit.

checkout

The action of updating all or part of the working tree with a tree object or blob from the object database, and updating the index and HEAD if the whole working tree has been pointed at a new branch.

quick pick

The add-sign icon provides you with a list of quick actions you can take at any time: create a new repository, import a repository from another SCM, create a gist (a quick way to share code, notes, and snippets), or create a new organization.

HEAD

The current branch. In more detail: Your working tree is normally derived from the state of the tree referred to by HEAD. HEAD is a reference to one of the heads in your repository, except when using a detached HEAD, in which case it directly references an arbitrary commit.

upstream branch

The default branch that is merged into the branch in question (or the branch in question is rebased onto). It is configured via branch.<name>.remote and branch.<name>.merge. If the upstream branch of A is origin/B sometimes we say "A is tracking origin/B".

master

The default development branch. Whenever you create a Git repository, a branch named "master" is created, and becomes the active branch. In most cases, this contains the local development, though that is purely by convention and is not required.

origin

The default upstream repository. Most projects have at least one upstream project which they track. By default origin is used for that purpose. New upstream updates will be fetched into remote-tracking branches named origin/name-of-upstream-branch, which you can see using git branch -r.

index entry

The information regarding a particular file, stored in the index. An index entry can be unmerged, if a merge was started, but not yet finished (i.e. if the index contains multiple versions of that file).

What happens when a pathspec begins with a colon in the long form?

The leading colon : is followed by an open parenthesis (, a comma-separated list of zero or more "magic words", and a close parentheses ), and the remainder is the pattern to match against the path.

What happens when a pathspec begins with a colon in the short form?

The leading colon : is followed by zero or more "magic signature" letters (which optionally is terminated by another colon :), and the remainder is the pattern to match against the path. The "magic signature" consists of ASCII symbols that are neither alphanumeric, glob, regex special characters nor colon. The optional colon that terminates the "magic signature" can be omitted if the pattern begins with a character that does not belong to "magic signature" symbol set and is not a colon.

pack index

The list of identifiers, and other information, of the objects in a pack, to assist in efficiently accessing the contents of a pack.

directory

The list you get with "ls" :-)

marketplace

The marketplace on GitHub is a great place to find applications and tools that can help your collaborative coding workflow. For example, I have used AppVeyor, a continuous integration application, on projects. When you connect AppVeyor to one of your repositories, it continuously runs tests and deploys apps to make sure that every bit of code you're adding won't break what you've already built.

pickaxe

The term pickaxe refers to an option to the diffcore routines that help select changes that add or delete a given text string. With the --pickaxe-all option, it can be used to view the full changeset that introduced or removed, say, a particular line of text. See git-diff(1).

working tree

The tree of actual checked out files. The working tree normally contains the contents of the HEAD commit's tree, plus any local changes that you have made but not yet committed.

object name

The unique identifier of an object. The object name is usually represented by a 40 character hexadecimal string. Also colloquially called SHA-1.

object

The unit of storage in Git. It is uniquely identified by the SHA-1 of its contents. Consequently, an object cannot be changed.

Remote

This is the version of something that is hosted on a server, most likely GitHub. It can be connected to local clones so that changes can be synced.

merge, as a verb

To bring the contents of another branch (possibly from an external repository) into the current branch. In the case where the merged-in branch is from a different repository, this is done by first fetching the remote branch and then merging the result into the current branch. This combination of fetch and merge operations is called a pull. Merging is performed by an automatic process that identifies changes made since the branches diverged, and then applies all those changes together. In cases where changes conflict, manual intervention may be required to complete the merge.

octopus

To merge more than two branches.

rebase

To reapply a series of changes from a branch to a different base, and reset the head of that branch to the result.

rewind

To throw away part of the development, i.e. to assign the head to an earlier revision.

blob object

Untyped object, e.g. the contents of a file.

User

Users are personal GitHub accounts. Each user has a personal profile, and can own multiple repositories, public or private. They can create or be invited to join organizations or collaborate on another user's repository.

alternate object database

Via the alternates mechanism, a repository can inherit part of its object database from another object database, which is called an "alternate".

Upstream

When talking about a branch or a fork, the primary branch on the original repository is often referred to as the "upstream", since that is the main place that other changes will come in from. The branch/fork you are working on is then called the "downstream".

Dashboard

Your personal dashboard is the main hub of your activity on GitHub. From your personal dashboard, you can keep track of issues and pull requests you're following or working on, navigate to your top repositories and team pages, and learn about recent activity in repositories you're watching or participating in. You can also discover new repositories, which are recommended based on users you're following and repositories you have starred. To only view activity for a specific organization, visit your organization's dashboard. For more information, see "About your personal dashboard" or "About your organization dashboard."

merge, as a noun

unless it is a fast-forward, a successful merge results in the creation of a new commit representing the result of the merge, and having as parents the tips of the merged branches. This commit is referred to as a "merge commit", or sometimes just a "merge".

SHA-1

"Secure Hash Algorithm 1"; a cryptographic hash function. In the context of Git used as a synonym for object name.

> git add

- 'stages' file - puts it into staging area

git GUIs

- GitHub Desktop - GitKraken - SourceTree - Git Extensions

special files in github repo

- README - LICENSE - CONTRIBUTING and CONTRIBUTORS - CHANGELOG - SUPPORT - CODE_OF_CONDUCT

diff tools

- VS.code has one built in - KDiff3 - P4Merge - vimdiff3 - Beyond Compare

git branching

- a branch is a pointer to a commit - lightweight, compared to CCVS - uses 'snapshots' instead of 'differences' - for each version, full file with change stored, and pointers to prior versions when not changed, for all files - moves forward with every commit - encouraged - used for feature and bug dev

a branch points to

- a snapshot in the history of the project

github projects

- agile methodology to add features - basic kanban template

github pull request, aka PR, aka GitHub Flow

- announcing changes made in another branch - want review and discussion 1. create PR for our branch 2. add more commits 3. add comments 4. explore files in the PR 5. merge PR into branch 6. delete branch

> git checkout [name]

- checkout a branch - if branch doesn't exist, it is created

> git commit

- commit changed files file to remote repo - behind scenes, uses snapshots

> git config

- configure git on local system

project boards

- contain issues, PRs - cards - templates: 1. basic kanban 2. automated kanban 3. automated kanban with review 4. bug triage

> git branch [name]

- create a new branch

> git tag v1 master

- creates a tag 'v1' on master branch - indicate important point in history of project - two types 1. lightweight 2. annotated - message, checksum, etc - can download code (zip) - see commits

> git tag -a v0.1 -m "0.1 release"

- creates annotated tag

why git?

- distributed version control - every dev has full copy of source - fast - easy to use - branching

> git clone

- download from remote / github

> git fetch

- fetch files to local repo - no merge (not 'destructive')

github repo

- folder for project - owned by account or org - public or private (for fee) - assign a topic/tag - issues - bugs, to-dos, etc - insights - info about traffic - pull requests

> git pull

- git fetch + git merge

fast-forward on git merge

- git merge with no conflicts

repo insights

- help determine most significant contributors, which can then be asked to join team - traffic - commits - code frequency

> git log --oneline --graph --decorate --all

- history log of repo - can be very long - use qualifiers to make it easier to read

wiki

- hub for doco - repo based (can clone them, add, push)

github archive

- indicate repo isn't active anymore - close out issues first - makes it read-only - not truly destructive, can reactivate

branching in traditional CCVS

- initial versions of files plus change sets over time - expensive

> git init

- initialize a local git repo

releases

- just like tags - with release notes - and links to binary files

> git tag

- list tags

repo collaborators

- main people on team - trusted to change code

fork

- make personal copy of repo - changes can be merged via PRs - anyone can fork - part of github, not git

labels

- organize and prioritize issues - built-in and custom - e.g. bug, duplicate, enhancement, help wanted, question, wontfix, good first issue, invalid

repo contributors

- people outside team - less privs - pull requests to make changes

why github?

- pull requests - social aspects of coding (knowledge sharing) - code reviews - documentation - team tools - gists - snippets of code

> git push origin master

- push commits to remote repo, master branch - will be rejected if remote has files updated and not in local repo - if so, need to do a git fetch or git pull

> git push -u [origin] [branch]

- push to a specific branch

gists

- share code snippets and notes - gist.github.com - attach files - public or private - repo based (can clone them, add, push) - downloadable

github pages

- static site hosting - no server-side code - repo based (can clone them, add, push)

> git status

- status of git - what needs to be added (not tracked) - which branch working with

issues

- track bugs, new feature requests, etc - linked to PRs - linked to project board - has notifications - can be filtered

milestones

- track reaching a point - group issues together - track progress

notifications

- types 1. participating - e.g. code review request 2. watching - something changes in repo - delivery via email or within github

typical steps

1. git clone repo 2. git add files to staging area 3. git commit changes from files in staging area 4. deal with merge conflicts 4.a. git fetch, or 4.b. git pull - effectively a git fetch + git merge 5. git push to repo

git file states

1. modified - changed, but not in local db 2. committed - local db 3. staged - marked to be part of next commit to remote repo

git storage areas

1. working directory 2. staging area - where files are stored before commit 3. .git repo - when cloned 4. remote repo on github

branch

A "branch" is an active line of development. The most recent commit on a branch is referred to as the tip of that branch. The tip of the branch is referenced by a branch head, which moves forward as additional development is done on the branch. A single Git repository can track an arbitrary number of branches, but your working tree is associated with just one of them (the "current" or "checked out" branch), and HEAD points to that branch.

refspec

A "refspec" is used by fetch and push to describe the mapping between remote ref and local ref.

bare repository

A bare repository is normally an appropriately named directory with a .git suffix that does not have a locally checked-out copy of any of the files under revision control. That is, all of the Git administrative and control files that would normally be present in the hidden .git sub-directory are directly present in the repository.git directory instead, and no other files are present and checked out. Usually publishers of public repositories make bare repositories available.

Branch

A branch is a parallel version of a repository. It is contained within the repository, but does not affect the primary or master branch allowing you to work freely without disrupting the "live" version. When you've made the changes you want to make, you can merge your branch back into the master branch to publish your changes. For more information, see "About branches."

Check

A check is a type of status check on GitHub. See "Status checks."

Clone

A clone is a copy of a repository that lives on your computer instead of on a website's server somewhere, or the act of making that copy. With your clone you can edit the files in your preferred editor and use Git to keep track of your changes without having to be online. It is, however, connected to the remote version so that changes can be synced between the two. You can push your local changes to the remote to keep them synced when you're online.

Collaborator

A collaborator is a person with read and write access to a repository who has been invited to contribute by the repository owner.

index

A collection of files with stat information, whose contents are stored as objects. The index is a stored version of your working tree. Truth be told, it can also contain a second, and even a third version of a working tree, which are used when merging

repository

A collection of refs together with an object database containing all objects which are reachable from the refs, possibly accompanied by meta data from one or more porcelains. A repository can share an object database with other repositories via alternates mechanism.

parent

A commit object contains a (possibly empty) list of the logical predecessor(s) in the line of development, i.e. its parents.

commit-ish (also committish)

A commit object or an object that can be recursively dereferenced to a commit object. The following are all commit-ishes: a commit object, a tag object that points to a commit object, a tag object that points to a tag object that points to a commit object, etc.

Commit

A commit, or "revision", is an individual change to a file (or set of files). It's like when you save a file, except with Git, every time you save it creates a unique ID (a.k.a. the "SHA" or "hash") that allows you to keep record of what changes were made when and by who. Commits usually contain a commit message which is a brief description of what changes were made.

Contributor

A contributor is someone who has contributed to a project by having a pull request merged but does not have collaborator access.

Diff

A diff is the difference in changes between two commits, or saved changes. The diff will visually describe what was added or removed from a file since its last commit.

fast-forward

A fast-forward is a special type of merge where you have a revision and you are "merging" another branch's changes that happen to be a descendant of what you have. In such a case, you do not make a new merge commit but instead just update to his revision. This will happen frequently on a remote-tracking branch of a remote repository.

Fork

A fork is a personal copy of another user's repository that lives on your account. Forks allow you to freely make changes to a project without affecting the original. Forks remain attached to the original, allowing you to submit a pull request to the original's author to update with your changes. You can also keep your fork up to date by pulling in updates from the original.

chain

A list of objects, where each object in the list contains a reference to its successor (for example, the successor of a commit could be one of its parents).

ref

A name that begins with refs/ (e.g. refs/heads/master) that points to an object name or another ref (the latter is called a symbolic ref). For convenience, a ref can sometimes be abbreviated when used as an argument to a Git command; see gitrevisions(7) for details. Refs are stored in the repository. The ref namespace is hierarchical. Different subhierarchies are used for different purposes (e.g. the refs/heads/ hierarchy is used to represent local branches). There are a few special-purpose refs that do not begin with refs/. The most notable example is HEAD.

head

A named reference to the commit at the tip of a branch. Heads are stored in a file in $GIT_DIR/refs/heads/ directory, except when using packed refs. (See git-pack-refs(1).)

gitfile

A plain file .git at the root of a working tree that points at the directory that is the real repository.

remote-tracking branch

A ref that is used to follow changes from another repository. It typically looks like refs/remotes/foo/bar (indicating that it tracks a branch named bar in a remote named foo), and matches the right-hand-side of a configured fetch refspec. A remote-tracking branch should not contain direct modifications or have local commits made to it.

tag

A ref under refs/tags/ namespace that points to an object of an arbitrary type (typically a tag points to either a tag or a commit object). In contrast to a head, a tag is not updated by the commit command. A Git tag has nothing to do with a Lisp tag (which would be called an object type in Git's context). A tag is most typically used to mark a particular point in the commit ancestry chain.

reflog

A reflog shows the local "history" of a ref. In other words, it can tell you what the 3rd last revision in this repository was, and what was the current state in this repository, yesterday 9:14pm. See git-reflog(1) for details.

topic branch

A regular Git branch that is used by a developer to identify a conceptual line of development. Since branches are very easy and inexpensive, it is often desirable to have several small branches that each contain very well defined concepts or small incremental yet related changes.

Repository

A repository is the most basic element of GitHub. They're easiest to imagine as a project's folder. A repository contains all of the project files (including documentation), and stores each file's revision history. Repositories can have multiple collaborators and can be either public or private.

submodule

A repository that holds the history of a separate project inside another repository (the latter of which is called superproject).

superproject

A repository that references repositories of other projects in its working tree as submodules. The superproject knows about the names of (but does not hold copies of) commit objects of the contained submodules.

remote repository

A repository which is used to track the same project but resides somewhere else. To communicate with remotes, see fetch or push.

pack

A set of objects which have been compressed into one file (to save space or to transmit them efficiently).

shallow repository

A shallow repository has an incomplete history some of whose commits have parents cauterized away (in other words, Git is told to pretend that these commits do not have the parents, even though they are recorded in the commit object). This is sometimes useful when you are interested only in the recent history of a project even though the real history recorded in the upstream is much larger. A shallow repository is created by giving the --depth option to git-clone(1), and its history can be later deepened with git-fetch(1).

commit, as a noun

A single point in the Git history; the entire history of a project is represented as a set of interrelated commits. The word "commit" is often used by Git in the same places other revision control systems use the words "revision" or "version". Also used as a short hand for commit object.

Status

A status is a type of status check on GitHub. See "Status checks."

head ref

A synonym for head.

tree-ish (also treeish)

A tree object or an object that can be recursively dereferenced to a tree object. Dereferencing a commit object yields the tree object corresponding to the revision's top directory. The following are all tree-ishes: a commit-ish, a tree object, a tag object that points to a tree object, a tag object that points to a tag object that points to a tree object, etc.

clean

A working tree is clean, if it corresponds to the revision referenced by the current head. Also see "dirty".

dirty

A working tree is said to be "dirty" if it contains modifications which have not been committed to the current branch.

reachable

All of the ancestors of a given commit are said to be "reachable" from that commit. More generally, one object is reachable from another if we can reach the one from the other by a chain that follows tags to whatever they tag,commits to their parents or trees, and trees to the trees or blobs that they contain.

evil merge

An evil merge is a merge that introduces changes that do not appear in any parent.

unmerged index

An index which contains unmerged index entries.

tree object

An object containing a list of file names and modes along with refs to the associated blob and/or tree objects. A tree is equivalent to a directory.

tag object

An object containing a ref pointing to another object, which can contain a message just like a commit object. It can also contain a (PGP) signature, in which case it is called a "signed tag object".

stash entry

An object used to temporarily store the contents of a dirty working directory and the index for future reuse.

commit object

An object which contains the information about a particular revision, such as parents, committer, author, date and the tree object which corresponds to the top directory of the stored revision.

unreachable object

An object which is not reachable from a branch, tag, or any other reference.

dangling object

An unreachable object which is not reachable even from other unreachable objects; a dangling object has no references to it from any reference or object in the repository.