Skip to main content

Basic Concepts

Git basic concepts

Git Objects​

Git utilizes four distinct objects to represent information. These objects are arranged in a graph for easy retrieval and manipulation operations.

Git objects

  • Blob​

    A blob object represents the contents of the file added under the current commit, except for the name and attributes of this file. They’re stored in tree objects.

  • Tree​

    A tree object resembles file system directories. This object stores a listing of directory entries. Each entry is represented with its object type (tree or blob), name, file access mode, and a reference to any corresponding tree or blob object. Tree objects may refer to other tree objects, forming a folder hierarchy.

  • Commit​

    A commit object points to the tree object in the working directory root. This object stores information about the author’s or committer’s identity along with the commit message. Subsequent commit objects refer to previous commit objects by their hashes to represent the commit history.

  • Tag​

    A tag object is created for annotated tags. Tag assigns a meaningful name with a specific version in the repository. Tags are very similar to branches, but the difference is that tags are immutable. It means, tag is a branch, which nobody intends to modify. Once a tag is created for a particular commit, even if you create a new commit, it will not be updated. Usually, developers create tags for product releases.

Git Repository​

A repository in git is the directory that stores all the files of a project (including documentation) with stores each file’s revision history. In other words, it’s the object database of the project, storing everything from the files themselves to the versions of those files, commits, deletions, etc. The file history appears as snapshots in time called commits, and the commits exist as a linked-list relationship and can be organized into multiple lines of development called branches. Because git is a DVCS, repositories are self-contained units, and anyone who owns a copy of the repository can access the entire codebase and its history.

Using the command line or other ease-of-use interfaces, a git repository also allows for: interaction with the history, cloning, creating branches, committing, merging, comparing changes across versions of code, and more.

Git Workflow​

Git introduce a promotional model workflow where content moves up through the levels as it matures.

git Workflow

Let’s take a look at the 4 different environments.

  1. Working directory​

The working directory, also called working tree, consists of files you are currently working on. You can think of a working directory as a file system where you can view and modify files. A working directory can have any number of subdirectories that form an overall workspace.

  1. Staging Area​

The staging area is where you prepare your commit. Files in the staging are marked as modified. Once you initiate a commit, the repository notices that the staging area has marked modified files and asks if you want to apply changes.

  1. Local Repository​

The local repository is the final piece of the set of Git levels that exist on a user’s local machine (the local environment). Once content has been created or updated and then staged, it is ready to be committed into the local repository. Local repository is physically stored inside a separate (normally hidden) subdirectory normally within the root of the working directory. It is created in one of two ways: via a clone (copy) of a repository from a remote, or through telling Git to initialize a new environment locally.

  1. Remote Repository​

The remote repository is the level of Git that hosts and serves up content for wider consumption. It’s the place where multiple Git users sync up the changes from their respective local repositories. It corresponds to what you would traditionally think of as the server in other source management systems.

The basic Git workflow goes something like this:

  1. You modify files in your working tree.

  2. You selectively stage just those changes you want to be part of your next commit, which adds only those changes to the staging area.

  3. You perform commit operation that moves the files from the staging area. After push operation, it stores the changes permanently to the Git repository.

If a particular version of a file is in the Git directory, it’s considered committed. If it has been modified and was added to the staging area, it is staged. And if it was changed since it was checked out but has not been staged, it is modified.