Understanding Git: Implementation Principles, Data Model, and Common Commands

Author and Origin

"Talk is cheap. Show me the code." – Linus Torvalds, the creator of Linux and Git.

Git was born in 2005 when the Linux kernel team could no longer use the free version of BitKeeper. Linus decided to write his own system, and within ten days the first version of Git was released as a free, open‑source version‑control system.

Version Control Systems

Version control is something everyone has used, from multiple resume drafts to successive thesis revisions. Local version control is simple but only supports a single user. Two main types of centralized systems emerged:

Centralized Version Control Systems (CVCS) – e.g., CVS, Subversion, Perforce. A single server stores the latest version of all files; users connect to fetch or commit changes. The downside is a single point of failure.

Distributed Version Control Systems (DVCS) – e.g., Git, Mercurial, Bazaar. Each repository contains a full copy of the project, so any server failure can be recovered from another clone.

DVCS also enables easy collaboration across organizations because remote repositories can interact directly.

Git's Data Model

What Is a Snapshot?

Git tracks three object types:

blob – a single file.

tree – a directory.

commit – a snapshot of the top‑level tree.

A snapshot represents the entire tracked directory tree at a point in time. Each commit records its parent(s), author, message, and the snapshot tree.

class commit {
  array<commit> parents
  String author
  String message
  Tree snapshot
}

All objects (blob, tree, commit) are identified by a SHA‑1 hash and can be referenced by names such as HEAD . The local repository consists of objects and references (collectively called repositories ).

Common Commands

The commands are grouped into three sections: local operations, remote interaction, and branch collaboration.

Local Operations

Git works with three areas and three file states:

working directory – where you edit files ( modified ).

staging area – files marked for the next commit ( staged ).

local repository – committed history ( committed ).

$ git add

Add changes from the working directory to the staging area.

$ git commit -m "comment"

Create a new commit from the staged changes. Use git commit --amend to modify the most recent commit.

$ git log

Show commit history. git log --oneline prints a compact one‑line view. git reflog displays reference updates.

$ git reset

Move the current branch pointer to a specified commit. Options:

--hard – sync working directory, staging area, and repository.

--soft – only move the repository pointer.

--mixed – sync repository and staging area, leave working directory unchanged.

Remote Interaction

$ git push

Upload local commits to a remote repository.

$ git clone

Copy an entire remote repository to your machine.

$ git pull

Fetch from the remote and merge (default) or rebase the changes.

$ git fetch

Download remote objects without updating the working directory.

Branching and Merging

View branches

git branch lists local branches; git branch -v shows additional info.

Create a branch

git branch <branchName>

Switch branches

git checkout <branchName>

Merge branches

git merge <branchName> . Conflicts occur when the same part of a file is edited in both branches.

Learning Resources

git help

Use git help or git help <command> for quick reference and examples.

Pro Git

The free online book https://git-scm.com/book/en/v2 (English) and its Chinese translation https://git-scm.com/book/zh/v2 cover basics, advanced usage, and the underlying principles.

Playful Learning

Practice Git with the interactive game https://learngitbranching.js.org/ (source: https://github.com/pcottle/learnGitBranching ).

— End of article —