Understanding Git

A Git Project is represented by “repository”, which is collection of complete history in form of commits.

Commits are like snapshots of project content

Contents of Commit

  • A project content snapshot : Tree
  • Author
  • Committer
  • Commit Message
  • A list of zero or more “parent commits”


Commit graph of some Repository

  • Letters and numbers represents commits
  • Arrowhead : Commit to its parent commit
  • A root is the commit with no parent commit
  • Some commits have multiple parents which represents “merge:commits”
    • indicates commit reconciliation from different branches of commit graph
  • usually arrowheads are omitted since flow is usually represented left-right and down-top


  • “release”, “master” and “topic” denotes branches
  • Z, F and 4 tips of these branches
    • release = {A, B, C, X, Y , Z}
    • master = {A, B, C, D, E, F, 1, 2}
    • topic = {A, B, 1, 2, 3, 4}

Sharing Work

There are two contexts : Public and Private Repository

  • commit “early and often” to try out various ideas and make changes freely
  • you can reorganize your commits later before publishing

With Git, sharing work happens via operations called “push” and “pull” changes from and to the remote repository

  • first we clone the existing repository over a network via protocols like HTTP and SSH
  • this clone is full copy of the original, including all project history
  • this cloned repository maintains reference to original one using a “remote”
  • remote maintains state of branches using “remote tracking” branches indicated by name “origin/develop” or “origin/master”


  • when we ask to checkout some topic branch, git sees that there isn’t a local branch with that name (initially master/main is fetched) but since remote already has ‘origin/topic’.
  • it automatically creates a branch named topic and sets ‘origin/topic’ as its “upstream” branch
  • this process causes push/pull mechanism to maintain changes in sync
  • when we pull git updates remote-tracking branches with the current state of origin repository
  • when we push, it updates the remote with any changes you’ve made corresponding to local branches.
    • sometimes git will complain to merge conflicting changes before actually pushing

The Object Store

  • Blob : opaque chunk of data, a string of bytes with no further internal structure
    • content of file under VCS is represented as blob using sophisticated compression and transmission techniques
    • NOTE: every version of a file in Git is represented as a whole, with its own blob containing the file’s complete contents,
      • its different from many systems where changes are stored incrementally
      • Comes with its own benefits and drawbacks like “storage-saving” v/s reconstructing file back from history using diffs :)
      • blob design provides redundancy : corruption of one blob just affects some specific version rather than entire history of file
  • Tree : represents a single level of directory structure in repository content
    • it contains a list of each items with each containing
      • a filename and file type
      • a pointer to another object. If object is blob then this item represents file, if its a tree, a directory
    • git tree, represents a portion of the repository content at one point in time : a snapshot of a particular directory’s content, including all directories recursively beneath it
  • Commit : A VCS manaages content changes, commit is fundamental unit of change in Git
    • Commit consists of
      • A pointer to tree containing the complete state of repository content at one point in time
      • Ancillary information about this change: who was responsible for content(Author), who introduced the change into the repository(committer); and time/date for both changes
      • A list of zero or more other commit objects, called the “parents” of this commit
    • There is always atleast a root commit (infinite loops etc are not allowed so a DAG)
    • there can be several root commits using git checkout --orphan
  • Author vs Committer

    • These are initially same, but become distinct by use of certain git commands. For example git chery-pick replicates changes from existing commit by reapplying the changes introduced by that commit in another context.
    • other operation that may result in this are git filter-branch or git rebase
  • Cryptographic Signature : A commit may also be signed using GnuPG with git commit --gpg-sign[=keyid]
    • A cryptographic signature binds the commit to a particular real-world personal identity attached to the key used for signing.
  • Tag : tag serves to distinguish a particular commit by giving it a human-readable name in a namespace reserved for this purpose

Object IDs and SHA-1