..

git-moc

Commit types

Commit Type Title Description Emoji Release Include in changelog
feat Features A new feature ✨ minor true
fix Bug Fixes A bug Fix 🐛 patch true
docs Documentation Documentation only changes 📚 patch if scope is readme true
style Styles Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) 💎 - true
refactor Code Refactoring A code change that neither fixes a bug nor adds a feature 📦 - true
perf Performance Improvements A code change that improves performance 🚀 patch true
test Tests Adding missing tests or correcting existing tests 🚨 - true
build Builds Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) 🛠 patch true
ci Continuous Integrations Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs) ⚙️ - true
chore Chores Other changes that don’t modify src or test files ♻️ - true
revert Reverts Reverts a previous commit 🗑 - true

Version Control System

Notes for this lecture

  • Used for keep track of the changes made to src code
  • VCS achieve this through a set of snapshots
  • In addition to this VCS also store metadata about the files such as, but not limited to, author, date etc…

Uses

  • The obvious - Access to older versions
  • Ability to work parallelly using branches.
    • Example: One branch can be used to fix bugs while another is used to test new features
  • Collaboration

Git’s Data structures

In git folders are known as trees and files are known as blobs. A simple way of modelling history is through a linear sequence of snapshots. But this model is very limiting. Git uses a different, rich model. It models the snapshots as a Directed Acyclic Graph. Each snapshot has a parent(s). In git each snapshot in git is known as a commit. We can write these as pseudocode to understand them better

typedef byte blob[];

typedef union {
    tree,
    blob
} tree_obj;

typedef map(string, tree_obj[]) tree;

/* Each commit only has the references.
* In git objects are stored separtely in an object store and are
* referenced using their hashes
*/
typedef struct{
    commit *parent[],
    string author,
    string msg,
    // snapshot is the reference to the root folder
    tree *snapshot
} commit;

typedef union{
    tree,
    blob,
    commit
} object;

typedef string ID;

typedef map(ID, object) object_map;

/* This is for human identification. Since ID, which is a SHA1 hash doesn't
* have any semantic meaning it is attached with a human readable message.
*/
typedef map(ID, msg) ref;

void store(object o, object_map m)
{
    string id = sha1(o);
    object_map[id] = o;
    return;
}

object load(ID id, object_map m)
{
    return m[id];
}

Git hash example

The above example has one file and one commit. There are three objects in the .git/objects folder. One is for foo.txt, one for bar commit and the last is for the root tree.

Another important terminology is branches. Branches can be thought as a reference to a commit. There two special references in git.

  1. master
    • master refers to the main line of development of a project
  2. HEAD
    • HEAD refers to the commit that we are actually viewing as our current working directory

Git commands

git init
Create an empty git repository
git status
Shows the current status
git log --all --graph --decorate
Shows a diagram resembling the underling ADAG structure
git diff [COMMIT] [FILE]
Show the modifications between HEAD or the COMMIT given to the FILE
git checkout -b BRANCH
Creates a new branch and switches to it
git merge COMMIT
Merges HEAD with COMMIT