Fundamentals of Distributed Version Control with Git

This article introduces the design ideas behind distributed version control systems (DVCS) and contrasts them with traditional centralized systems such as CVS or Subversion, highlighting how each developer works with a local repository that contains the full project history.

It describes several types of repositories used in a DVCS environment, including blessed (official), shared, workflow, and fork repositories, and explains why local operations are fast, offline work is possible, and data integrity is ensured through cryptographic hash identifiers.

The internal structure of a Git repository is detailed: blobs store file contents, trees represent directories, and commits capture snapshots of the entire project state, each identified by a unique SHA‑1 hash.

Key advantages of Git are enumerated, such as high performance, efficient branching, offline capabilities, flexible development processes, built‑in backup, and easy refactoring.

Basic workflow commands are demonstrated with examples. To configure a user, run:

> git config --global user.email "[email protected]"
> git config --global user.name "Hans Mustermann"

To start a new project, initialize a repository:

> cd /projects/first-steps
> git init
Initialized empty Git repository in /projects/first-steps/.git/

Files are added and committed:

> git add foo.txt bar.txt
> git commit --message "Sample project imported."
master (root-commit) 2f43cd0 Sample project imported.
2 files changed, 2 insertions(+), 0 deletions(-)

The git status command shows modified, deleted, and untracked files, while git diff displays line‑by‑line changes. After staging changes with git add (or removing with git rm), a new commit is created using git commit.

History can be inspected with git log (or git log --graph for a visual branch view). Branches are created implicitly by committing on separate lines of development and can be merged with git merge. The article also covers cloning a repository, pulling updates, and pushing changes to a shared (bare) repository:

> git clone /projects/first-steps /projects/first-steps-clone
> git pull
> git push /projects/first-steps-bare.git master

Finally, a concise summary lists the main points: working directory and repository relationship, committing changes, inspecting status and logs, cloning for independent work, and using push/pull to share updates across developers.