Jul 4, 2024 22 min read

Git and GitHub Glossary

Discover the comprehensive Git and GitHub Glossary to unveil essential terms and definitions associated with version control, collaboration, and repository management.

Git and GitHub Glossary
Git and GitHub Glossary
Table of Contents


Navigate the world of version control and collaborative software effortlessly.

Dive into our combined glossary to unravel critical terms, enhance your proficiency, and optimize your software development approach effortlessly. Master version control systems and streamline collaborative workflows with ease.

Git and GitHub Terms


Access Token: A token that serves as a substitute for a password when executing Git operations over HTTPS via the command line or API, and is also known as a personal access token.

Alternate Object Database: The "alternates" mechanism enables a repository to inherit a portion of its object database from another object database, which is referred to as an "alternate".

API preview: A means of testing new APIs and modifications to existing API methods prior to their inclusion in the official GitHub API.

Appliance: A software application designed to operate optimally on standard industry hardware (commonly servers) or in a virtual environment, accompanied by a minimal operating system (JeOS).

Assignee: The individual designated to handle an issue.

Authentication Code: A code that you will provide, in addition to your GitHub password, when signing in using two-factor authentication (2FA) via a web browser. This code is either generated by an application or sent to your phone via text message. Also known as a "2FA authentication code".


Base Branch: The branch where changes are integrated when a pull request is merged. When a pull request is created, the base branch can be altered from the repository's default branch to another branch if necessary.

Basic Authentication: A form of authentication in which credentials are transmitted as unencrypted text.

Bare Repository: A bare repository is typically a directory with a .git suffix and an appropriate name, devoid of a locally checked-out copy of any files under version control. In other words, all Git administrative and control files that are usually stored in the hidden .git subdirectory are directly present in the repository.git directory, and no other files are checked out. Publishers of public repositories commonly make bare repositories available.

Billing Cycle: The duration covered by your particular billing plan.

Billing Email: The email address associated with the organization where GitHub sends receipts, credit card or PayPal charges, and other billing-related communications.

Billing Manager: The organization member responsible for managing billing settings for the organization.

Billing Plan: User and organization payment plans that offer predetermined features for each plan type.

Bio: A user-generated description on a profile, such as adding a biography to your profile

Blame: In Git, the "blame" feature reveals the latest modification made to each line of a file, typically showing the revision, author, and timestamp. This feature is useful for tasks like pinpointing when a feature was introduced or identifying the commit responsible for a specific bug.

Blob Object: An object that is not associated with a specific type, such as the contents of a file.

Block: To revoke a user's permission to collaborate on the repositories of an organization.

Branch: In Git, a "branch" represents a distinct line of development. The latest commit on a branch is known as the tip of that branch. This tip is indicated by a branch head, which advances as further development occurs on the branch. While a Git repository can monitor multiple branches, your working tree is linked to only one (the "current" or "checked out" branch), with HEAD pointing to this branch.

Branch Restriction: A limitation that repository administrators can implement, allowing only specific users or teams to push or make particular changes to the branch.

Business Plan: A billing plan for an organization that enables collaboration on unlimited public and private repositories, allows or mandates organization members to authenticate to GitHub using SAML SSO, and facilitates provisioning and deprovisioning access via SAML or SCIM.


CA certificate: A digital certificate issued by a Certificate Authority (CA) guarantees secure connections between two devices, like a user's computer and GitHub.com, while also validating the site's ownership.

Card: A square that can be moved within a project board, connected to either an issue or a pull request.

Chain: A collection of objects, with each object containing a reference to its successor (for instance, the successor of a commit may be one of its parents).

Changeset: In the context of BitKeeper/cvsps, "commit" is the equivalent term. Given that Git stores states rather than changes, using the term "changesets" with Git is not particularly meaningful.

Check: A status check on GitHub is a type of verification or evaluation.

Checkout: The process of refreshing the entire or a portion of the working tree with a tree object or blob from the object database, and updating the index and HEAD if the entire working tree has been directed to a new branch.

Cherry-Picking: In the terminology of SCM, "cherry pick" refers to the selection of a subset of modifications from a sequence of changes (commonly commits) and their recording as a new series of changes on top of a separate codebase. In Git, this is accomplished using the "git cherry-pick" command, which extracts the modification introduced by an existing commit and records it based on the tip of the current branch as a new commit.

Child Team: In a hierarchical team structure, the subteam that receives the parent team's access permissions and is tagged in communications.

Clean: A working tree is considered clean when it matches the revision indicated by the current head.

Clone: A clone refers to a duplicate of a repository stored on your local computer rather than on a remote server, or the process of creating this duplicate. By cloning a repository, you gain the ability to modify files using your chosen editor and utilize Git to manage these changes offline. The cloned repository remains linked to the remote version, enabling you to synchronize your local modifications with the remote repository when you are connected online.

Clustering: Enabling GitHub Enterprise services to operate on multiple nodes and distribute requests among them for load balancing.

Code Frequency Graph: A visualization of a repository's history that displays the content additions and removals for each week.

Code of Conduct: A text that outlines guidelines for participating in a community.

Code Owner: A designated individual who holds responsibility for a section of a repository's codebase. This individual, known as the code owner, is automatically invited for review when a pull request is submitted (excluding draft mode) that includes modifications to the code they oversee.

Collaborator: A collaborator is an individual who has been granted read and write permissions to a repository by the owner and has been invited to contribute.

Commit: As a noun, a "commit" represents a single point in Git history, with the entire project history depicted as a network of interconnected commits. The term "commit" is frequently employed by Git in the same contexts where other version control systems use "revision" or "version". It also serves as a shorthand for a commit object. Now, As a verb, "commit" refers to the action of preserving a new snapshot of the project's state in Git history, by generating a new commit that represents the current state of the index and updating HEAD to point to the new commit.

Commit Author:  The individual responsible for creating a commit.

Commit Graph Concept, Representations and Usage: The term "commit graph" is a synonym for the DAG (Directed Acyclic Graph) structure formed by the commits in the object database, which is referenced by branch tips through their linked chain of commits. This structure represents the definitive commit graph, which can be depicted in various ways, such as the "commit-graph" file.

Commit-Graph File: The "commit-graph" file (typically hyphenated) offers an alternative depiction of the commit graph, designed to enhance commit graph traversals. This file is stored in either the .git/objects/info directory or the info directory of an alternate object database.

Commit ID: A 40-character unique identifier, also known as a SHA, that is assigned to a commit.

Commit-ish (also committish): A "commit-ish" refers to a commit object or an object that can be iteratively dereferenced to a commit object. Examples of commit-ish include a commit object itself, a tag object pointing directly to a commit object, a tag object pointing to another tag object that ultimately points to a commit object, and so forth.

Commit Message: A brief, explanatory message that is associated with a commit and conveys the modification that the commit is implementing.

Commit Object: A "commit" object is a data container that encompasses details about a specific revision, including parents, committer, author, date, and the tree object that corresponds to the top directory of the stored revision.

Compare Branch: The branch used to initiate a pull request, which is contrasted with the selected base branch to identify the modifications. Upon merging the pull request, the base branch is updated with the changes from the compared branch, also known as the head branch of the pull request.

Contribution Graph: The section of a user's profile that displays their daily contributions over a period of up to one year.

Contribution Guidelines: A text that outlines the process for individuals to follow when contributing to a project.

Continuous Integration: Commonly referred to as CI, Continuous Integration is a practice in software development where automated builds and tests are triggered whenever a change is committed to a configured repository on GitHub. CI serves as a widely adopted best practice that aids in error detection.

Core Git: Git's core encompasses essential data structures and utilities. It offers a restricted set of source code management functionalities.

Contributor: A contributor is an individual who, despite not having collaborator access to a repository, has made contributions to a project and had a pull request they initiated successfully merged into the repository.

Contributors Graph: A visualization of a repository's history that highlights the top 100 contributors.

Cron: A scheduler for time-based tasks in Unix-like computer operating systems.

cURL: Employed in command lines or scripts to transmit data.


Dashboard: Your personal dashboard serves as the central hub for your GitHub activity. It allows you to monitor the progress of issues and pull requests you are involved with, access your key repositories and team pages, and stay informed about recent developments in repositories you are observing or contributing to.

Default Branch: The primary branch for initiating new pull requests and committing code changes within a repository. Every repository is initially equipped with at least one branch, typically established by Git during repository initialization. This initial branch is commonly named main and frequently serves as the default branch.

Dependency Graph: A visualization of a repository's dependencies, including packages and projects.

Dependents Graph: A graphical representation of a public repository's dependencies, encompassing packages, projects, and other repositories that rely on it.

Deploy Key: A deploy key is a type of SSH key that is stored on a server and provides access to a specific GitHub repository. Unlike regular SSH keys, deploy keys are directly linked to the repository rather than to a personal user account.

Detached HEAD: Git issues a warning when you work on a detached HEAD, which signifies that Git is not currently associated with a branch, and any commits you make will not be incorporated into the commit history. For instance, when you check out a non-latest commit from any branch, you are in a state of working on a detached HEAD.

Diff: A diff represents the variations in modifications between two commits or saved changes, providing a visual overview of the additions or deletions made to a file since its previous commit.

Directory: A directory is a container for one or more files or folders, serving to organize the contents of a repository.

Dirty: A working tree is deemed "dirty" when it contains uncommitted modifications in relation to the current branch.


Evil Merge: An evil merge is a type of merge that incorporates modifications that are not present in either of the parent branches.

Explorer: A manifestation of GraphiQL, which is an interactive GraphQL Integrated Development Environment (IDE) with graphical interface.


Fast-Forward: A fast-forward merge constitutes a particular type of merge where one revision is merged with another branch's descendant changes. In this scenario, a new merge commit is not created, and the revision is simply updated. This occurrence is commonplace in remote-tracking branches of remote repositories.

Feature Branch: A branch utilized for testing new features or resolving issues prior to their deployment, also known as a topic branch.

Fenced Code Block: A block of indented code that can be created using GitHub Flavored Markdown with triple backticks ``` at the beginning and end of the code block.

Fetch: By employing git fetch, you incorporate modifications from the remote repository into your local working branch without immediately committing them. This approach differs from git pull as fetching enables you to assess the changes before integrating them into your local branch.

Following (users): To receive alerts regarding another user's contributions and actions.

Force Push: A Git push that discards remote repository modifications in favor of local changes, disregarding potential conflicts.

Fork: A fork is a personal duplicate of another user's repository, hosted on your account, enabling you to independently modify the project without impacting the original upstream repository. By forking, you can submit pull requests to the upstream repository and maintain synchronization with the latest updates, as both repositories remain interconnected.


Git Archive: Alternative term for repository used by Arch Linux users.

Gitfile: A simple .git file located at the root of a working tree, directing to the actual repository directory.

Gist: A gist represents a shareable file on GitHub that allows editing, cloning, and forking capabilities. Gists can be made public or secret, with the latter being accessible to anyone with the URL.

Git: Git is an open-source software designed for monitoring alterations in text files, originally developed by the Linux operating system's creator. The social and user interface, GitHub, is founded on Git's core technology.

GraphQL: A language for crafting queries to APIs, complemented by a runtime system for executing those queries and retrieving relevant data from existing sources.


Hash: In the context of Git, an alternative term for object name.

Head: A designated reference to the concluding commit of a branch, known as a head. Heads are saved in a file within the $GIT_DIR/refs/heads/ directory, with the exception of instances utilizing packed refs.

HEAD: The active branch, more specifically: Your working tree generally corresponds to the state of the tree referenced by HEAD. HEAD is a reference to one of the repository's heads, unless in a detached HEAD state, where it directly points to a specific commit.

Head Ref: An alternative term for head.

Hook: Throughout the regular execution of various Git commands, optional scripts are invoked to enable developers to incorporate additional functionality or validation. These hooks typically facilitate pre-command verification, potentially halting the process, and post-operation notifications. Located in the $GIT_DIR/hooks/ directory, these hook scripts can be activated by removing the .sample extension from the filename. In earlier Git versions, making them executable was necessary.


Identicon: A automatically generated image that serves as the default profile picture when users register on GitHub. Users have the option to substitute this identicon with a personalized profile photo.

Identity Provider: Referred to as an IdP, a trusted entity that enables SAML single sign-on (SSO) for accessing other websites.

Index: An assemblage of files containing stat information, with their contents preserved as objects. The index serves as a stored version of your working tree. In reality, it can also accommodate multiple versions of a working tree, utilized during merging processes.

Index Entry: Details concerning a specific file, housed in the index. An index entry can become unmerged if a merge operation is initiated but not yet completed, resulting in multiple versions of the file within the index.

Instance: A private version of GitHub managed by an organization within a virtual machine, which they configure and administer.

Integration: An external application that interfaces with GitHub, frequently taking the form of GitHub Apps, GitHub Actions, or tailored actions.

Issue: Suggestions for enhancements, tasks, or queries associated with the repository are termed as issues. These can be initiated by any individual (in the case of public repositories) and are overseen by repository collaborators. Each issue includes a dedicated discussion thread. Additionally, you have the option to classify an issue using labels and assign it to a specific individual.


Jekyll: A tool for generating static websites for personal, project, or organizational purposes.


Key Fingerprint: A concise sequence of bytes that serves as a reference to a lengthier public key.

Keychain: A password management solution integrated within the macOS operating system.

Keyword: A distinct term that, when included in a pull request, results in the closure of an associated issue.


Label: A categorization applied to an issue or pull request, with a set of default labels provided for repositories, and users retaining the ability to create custom labels.

LFS: Git Large File Storage, an open-source extension for Git, facilitates the versioning of extensive files.

License: A document that can be incorporated with your project to inform individuals about the permissible and non-permissible actions related to your source code.

Line Comment: A remark made within a pull request, specifically pertaining to a particular line of code.

Line Ending: An unseen character or sequence of characters that signify the conclusion of a line within a text file.

Linguist: A library utilized on GitHub for detecting languages in blobs, disregarding binary or vendored files, excluding generated files from differences, and producing language composition graphs.


Main: The customary development branch. When you establish a Git repository, a branch labeled main is created and becomes the active one. Generally, this encompasses local development, although this is merely a convention and not a necessity.

Management Console: A segment in the GitHub Enterprise interface housing administrative functionalities.

Markdown: Markdown is a straightforward semantic file format, akin to .doc, .rtf, and .txt. It simplifies the process of writing content, including links, lists, and bullets, even for individuals without web-publishing experience, and presents it in a website-like format. GitHub endorses Markdown and employs a variant known as GitHub Flavored Markdown.

Markup: A methodology for annotating and styling a document.

Master: The primary branch in numerous Git repositories. Typically, when initiating a new Git repository via the command line, a branch named master is established. Various tools have transitioned to using an alternate designation for the default branch. For instance, on GitHub, the default branch is referred to as main when creating a new repository.

Members Graph: A repository graph that visually represents all the forks of a repository.

Mention: A notification directed to a user, initiated by prefixing their username with the "@" symbol. In an organization on GitHub, users can also be associated with a team that can be mentioned.

Merge: Merging involves integrating modifications from one branch (within the same repository or from a fork) into another branch. This process commonly occurs through a "pull request" (essentially a merge request) or using command line operations. If there are no conflicting changes, a merge can be executed through a pull request on the GitHub.com web interface, or it can always be performed via the command line.

Merge Conflict: A disparity that arises between merged branches, known as merge conflicts. These occur when individuals introduce dissimilar modifications to the same line of the same file, or when one person edits a file while another person deletes the same file. The merge conflict must be rectified before the branches can be successfully merged.

Milestone: A method to monitor the advancement of sets of issues or pull requests within a repository.

Mirror:  A fresh instance of a repository.


Network Graph: A repository graph that visually represents the branch history of the entire repository network, encompassing the root repository's branches and forks' branches that contain exclusive commits within the network.


Object: The fundamental unit of storage in Git is a Git object, which is distinctly identified by the SHA-1 hash of its contents. Consequently, the immutability of a Git object is upheld, as it cannot be altered.

Object Database: The Git object store retains a collection of "objects," with each object being distinguished by its object name. Typically, these objects are housed in $GIT_DIR/objects/.

Object Identifier (oid): An alternate name for object name.

Object Name: The exclusive identifier of a Git object, often denoted by a 40-character hexadecimal string, also commonly referred to as SHA-1.

Object Type: Among the identifiers "commit", "tree", "tag", or "blob", which categorize the type of a Git object.

Octopus: To integrate modifications from more than two branches.

Orphan: The process of switching to a branch that has not been created yet, referred to as an unborn branch. Following this action, the initial commit made becomes a root commit without a parent, initiating a new history.

Origin: The customary repository for tracking upstream updates. Most projects maintain at least one upstream project, with origin being the default repository for this purpose. Upon receiving new upstream updates, they are fetched into remote-tracking branches, denoted as origin/name-of-upstream-branch, which can be observed using git branch -r.

Overlay: This mode only updates and incorporates files into the working directory, without deleting them, analogous to how cp -R manages the contents in the destination directory. This is the default behavior during a checkout when transferring files from the index or a tree-ish. Conversely, the no-overlay mode also eliminates tracked files not included in the source, comparable to rsync --delete.


Pack: A collection of compressed objects consolidated into a single file for space conservation or efficient transmission.

Pack Index: A catalog of identifiers and additional information pertaining to the objects within a pack, facilitating efficient access to the pack's contents.

Permalink: An enduring static reference link to a specific web page.

Personal Account:  A GitHub account associated with an individual user.

Pinned repository: A repository that a user has chosen to highlight on their profile.

Pre-receive Hooks: Scripts that operate on the GitHub Enterprise server, available for implementing quality checks.

Primary Email Address: The primary email address to which GitHub sends receipts, credit card or PayPal charges, and other billing-related correspondence.

Private Contributions: Contributions made to a non-public (as opposed to public) repository.

Private Repository: Private repositories are exclusively accessible to the owner and any collaborators specifically designated by the owner.

Production Branch: A branch encompassing conclusive modifications that are prepared for implementation or deployment to an application or website.

Project Board: GitHub boards that consist of issues, pull requests, and notes, organized as cards within columns.

Protected Branch: Protected branches restrict various Git features on a branch selected by a repository administrator for protection. These restrictions include preventing force pushes, deletion, merging of changes without necessary checks passing or required reviews being approved, or uploading files through the GitHub web interface. Protected branches are commonly the default branch.

Public Contributions: Contributions made to a publicly accessible (as opposed to private) repository.

Public Repository: A public repository is accessible to all users, including those who are not registered with GitHub.

Pull: The term "pull" refers to the process of retrieving changes and merging them. For example, if another user has modified a remote file you are both collaborating on, you would pull in those updates to ensure your local copy remains current. For further information, refer to "fetch".

Pull Access: An alternative term for accessing read-only content.

Pull Request: Pull requests represent proposed modifications to a repository, submitted by a user and subject to approval or rejection by the repository's collaborators. Similar to issues, each pull request features its own discussion platform.

Pull Request Review: Collaborator feedback on a pull request, either approving the modifications or requesting additional changes prior to merging the pull request.

Pulse Graph: A repository diagram that provides a comprehensive view of the repository's activity.

Punch Graph: A repository diagram that visualizes the update frequency of a repository, categorized by the day of the week and hour of the day.

Push: The action of transmitting committed modifications to a remote repository on GitHub.com is referred to as "pushing". For example, if you modify something locally, you can push those changes to enable others to access them.

Push a Branch: Upon successfully pushing a branch to a remote repository, you update the remote branch with modifications from your local branch. When you "push a branch", Git searches for the branch's HEAD ref in the remote repository and confirms that it is a direct ancestor to the branch's local HEAD ref. Once validated, Git transfers all objects (reachable from the local HEAD ref and absent from the remote repository) into the remote object database and then updates the remote HEAD ref. If the remote HEAD is not an ancestor to the local HEAD, the push operation will fail.

Push Access: An alternative term for accessing content with editing capabilities.


Read Access: A repository permission level that grants the user the ability to retrieve, or read, information from the repository. All public repositories grant read access to all GitHub users. An alternative term for pull access.

README: A text file encompassing details about the files in a repository, often being the initial file a visitor to your repository encounters. A README file, together with a repository license, contribution guidelines, and a code of conduct, aids in conveying expectations and managing contributions to your project.

Rebase: Reapplying a sequence of modifications from one branch to a different base, and resetting the HEAD of that branch to reflect the outcome.

Recovery Code: A recovery mechanism designed to restore access to a GitHub account.

Release: GitHub's method of packaging and delivering software to your users.

ref: A label starting with refs/ (e.g., refs/heads/master) that directs to an object name or another reference (the latter known as a symbolic ref). Refs can be shortened for ease when utilized as an argument in Git commands and are stored within the repository.

Reflog: A reflog displays the local "chronicle" of a reference, effectively showing what the third-to-last revision in the repository was, and what the repository's state was at 9:14 pm yesterday.

refspec: A "refspec" is utilized by fetch and push to outline the correlation between a remote reference and a local reference.

Remote: This refers to the repository or branch version that is stored on a server, typically GitHub.com. Remote versions can be linked to local clones, enabling synchronization of changes.

Remote Repository: A repository that monitors the same project but is situated in a different location.

Remote URL: The location where your code is housed, which could be a GitHub repository, another user's fork, or a distinct server.

Replica: A secondary GitHub Enterprise instance that offers redundancy for the primary GitHub Enterprise instance.

Repository: At the core of GitHub, a repository is fundamental. Visualize it as a project's directory, encompassing all project files, including documentation, and preserving the revision history of each file. Repositories support multiple collaborators and can be public or private.

Repository Cache: A read-only duplicate of repositories for your GitHub Enterprise server instance, situated near geographically dispersed teams and CI clients.

Repository Graph: A graphical depiction of your repository's data.

Repository Maintainer: An individual responsible for managing a repository, who might address issues, and employ labels and other features to organize the repository's work. This person may also be tasked with maintaining the README and contributing files.

Required Pull Request Review: Mandatory reviews guarantee that pull requests receive at least one approved review before collaborators can modify a protected branch.

Required Status Check: Examinations on pull requests that verify all necessary CI tests are successful before collaborators can modify a protected branch.

Resolve: The process of manually correcting the remnants of a failed automatic merge.

Revert: Upon reverting a pull request on GitHub, a new pull request is automatically generated containing a single commit that undoes the merge commit from the initial merged pull request. In Git, you can reverse commits using git revert.

Review: Reviews enable individuals with repository access to comment on the modifications proposed in pull requests, approve the changes, or request additional modifications before the pull request is merged.

Root Directory: The primary directory in a hierarchical structure.

Root Filesystem: The foundational operating system and the GitHub Enterprise application environment.


SCM: Source code management (tool).

SHA-1: SHA-1, or "Secure Hash Algorithm 1," is a cryptographic hash function. In Git, it serves as a synonym for object names.

Shallow Clone: Primarily synonymous with a shallow repository, but the phrase emphasizes that it was generated by executing the git clone --depth=... command.

Shallow Repository: A shallow repository features a condensed history, with certain commits having their parental lineage severed (Git is instructed to disregard these commits' parents, even though they are preserved in the commit object). This can be advantageous when focusing on a project's recent history, as the full history recorded upstream can be significantly larger. Shallow repositories are generated using the --depth option in git-clone, and their history can be expanded with git-fetch.

Stash Entry: An entity employed to temporarily hold the contents of an unclean working directory and the index for future utilization.

Special ref: A reference with distinct semantics compared to typical references. These references can be accessed via standard Git commands, but their behavior may differ from regular references in certain scenarios.

Server-to-Server Request: An API request executed by an application that operates autonomously, independent of any specific user. An example is an application that runs on a predetermined schedule and closes issues with no recent activity. Applications utilizing this type of authentication do not consume a licensed GitHub account, meaning they do not deplete the available GitHub licenses in an enterprise plan. The token for server-to-server requests is procured programmatically through the GitHub API.

Service Hook: Commonly known as a "webhook," this feature enables notifications to be sent to an external web server whenever specific actions take place on a repository or organization.

Single Sign-On: Also known as Single Sign-On (SSO), this method enables users to log in to a single location - an identity provider (IdP) - which then grants the user access to other service providers.

Submodule: A repository that preserves the history of a distinct project within another repository, referred to as the superproject.

Superproject: A repository that incorporates repositories of other projects in its working tree as submodules, with the superproject being aware of the names of (but not storing copies of) the contained submodules' commit objects.


Tag: A reference within the refs/tags/ namespace that directs to an object of any type (usually a tag points to either a tag or a commit object). Unlike a head, a tag remains unchanged by the commit command. It's important to note that a Git tag is unrelated to a Lisp tag (which would be termed an object type in Git's context). Tags are commonly employed to designate specific points within the commit ancestry chain.

Tag Object: An object that includes a reference pointing to another object, with the capacity to hold a message akin to a commit object. Additionally, it can contain a (PGP) signature, in which case it is classified as a "signed tag object".

Timeline: A sequence of occurrences in a pull request or on a user profile.

Topic Branch: A conventional Git branch that developers utilize to signify a conceptual line of development. Given the simplicity and affordability of creating branches, it is often advantageous to maintain multiple small branches, each encapsulating specific, clearly defined concepts or incremental, interconnected modifications.

Tree: A working tree or a tree object, accompanied by the necessary blob and tree objects (representing a stored version of a working tree).

Tree Object: An object that includes a list of file names and modes, together with references to the corresponding blob and/or tree objects. A tree is analogous to a directory.

Tree-ish (also treeish): A tree object, or an object that can be recursively resolved to a tree object. When a commit object is dereferenced, it reveals the tree object associated with the revision's top directory. The following can all be categorized as tree-ishes: a commit-ish, a tree object, a tag object pointing to a tree object, a tag object pointing to another tag object that ultimately points to a tree object, and so on.


Unborn:  An API request carried out by an application that acts on behalf of a specific user. When a task is executed with user-to-server authentication, it is displayed on GitHub as having been performed by the user via the application. For instance, a user might opt to create an issue within a third-party application, and the application would then execute this action on the user's behalf on GitHub. The range of tasks an application can perform using a user-to-server request is limited by both the app's and the user's permissions and access levels. The token utilized in a user-to-server request is acquired through OAuth.

Unmerged Index: An index that comprises unmerged entries.

Unreachable Object: An object that cannot be traced back from a branch, tag, or any other reference.

Upstream: In discussions involving a branch or a fork, the primary branch on the original repository is frequently referred to as the "upstream," as it serves as the primary source for incoming changes. The branch or fork you are working on is then designated as the "downstream." This terminology is also known as "origin".

Upstream Branch: The default branch that is combined with the branch under consideration (or the branch in question is rebased onto). It is configured using branch.<name>.remote and branch.<name>.merge. When the upstream branch of A is origin/B, it is common to say "A is tracking origin/B."

User: Users are individuals who possess GitHub accounts. Each user maintains a personal profile and can own multiple repositories, which can be either public or private. They have the ability to establish organizations or collaborate on other users' repositories, either by invitation or through their own initiative.

User-to-Server Request: An API request carried out by an application that acts on behalf of a specific user. When a task is executed with user-to-server authentication, it is displayed on GitHub as having been performed by the user via the application. For instance, a user might opt to create an issue within a third-party application, and the application would then execute this action on the user's behalf on GitHub. The range of tasks an application can perform using a user-to-server request is limited by both the app's and the user's permissions and access levels. The token utilized in a user-to-server request is acquired through OAuth.

Username: A user's handle on GitHub.


Watch: By opting to watch a repository or issue, you will receive notifications whenever there are updates made to an issue or pull request.

Working Tree: The collection of actual checked-out files. Under normal circumstances, the working tree encompasses the contents of the HEAD commit's tree, along with any local modifications that have been made but not yet committed.

Worktree: A repository can be either a bare repository with no worktrees, or it can have one or multiple worktrees associated with it. Each "worktree" comprises a "working tree" and repository metadata, with the majority shared among other worktrees within the same repository. Some elements, such as the index, HEAD, and pseudorefs like MERGE_HEAD, per-worktree refs, and per-worktree configuration file, are managed independently for each worktree.

Write Access: A permission level on a repository that grants the user the ability to push or make changes to the repository.

Guide to Install Git and GitHub

Ready to dive into using Git and GitHub? Ensure you have Git installed correctly by following these detailed installation guides and GitHub installation by following these tailored to different distros.

With these installation guides, you'll be up and running with Git and GitHub in no time!

Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to DevOps Tutorials - VegaStack.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.