The difference between Git and other VCSs

Git is a distributed version control system (DVCS), while other common version control systems (such as SVN, CVS, Perforce, etc.) are mostly centralized (CVCS). The two differ significantly in architecture, workflow, branch management, performance, and other aspects. Below is a detailed comparison across multiple dimensions.

Distributed vs. Centralized Architecture

Git's distributed nature means each developer has a complete local copy of the repository, including all history and branches. In contrast, centralized systems like SVN rely on a central server to store the full version history.

// Git clones the entire repository
git clone https://github.com/user/repo.git

// SVN checks out only the latest version
svn checkout https://svn.example.com/repo/trunk

Advantages of distributed architecture:

• Offline work: Commits and branch operations require no network connection.
• No single point of failure: Each copy serves as a full backup.
• More flexible workflows: Local commits can be made before pushing to a remote.

Characteristics of centralized systems:

• Centralized permission control on the server.
• Less storage usage (clients do not save history).
• Most operations require an internet connection.

Differences in Data Storage Models

Git uses a content-addressable file system (SHA-1 hash) and stores file snapshots rather than differences. Each commit records the full state of the directory tree.

# Example of Git objects
.git/objects/
├── 12/3456789abcdef... # blob object (file content)
├── ab/cdef012345678... # tree object (directory structure)
└── cd/ef0123456789a... # commit object

Traditional VCS like SVN store file-based change lists (delta-based), recording only differences between versions. This results in:

• Git being faster at viewing historical versions (directly reading snapshots).
• Git branches being lighter to create (only requiring a new pointer).
• SVN potentially saving more space when handling large file histories.

Branching and Merging Mechanisms

Git branches are mutable pointers to commits, making them very lightweight to create:

# Create and switch to a branch
git branch feature-x
git checkout feature-x
# Equivalent shortcut
git switch -c feature-x

SVN branches are essentially directory copies and require server-side operations:

svn copy ^/trunk ^/branches/feature-x -m "Create branch"
svn switch ^/branches/feature-x

Regarding merging:

• Git uses a three-way merge algorithm (common ancestor + two branches).
• SVN requires explicit merge tracking (via the svn:mergeinfo property).
• Git's rebase operation can linearize history (SVN has no equivalent feature).

Working Directory and Staging Area

Git's unique staging area (stage/index) design:

# Working directory → staging area → repository
git add file.txt        # Add to staging area
git commit -m "msg"     # Commit staged content

Traditional VCS typically commit changes directly from the working directory:

svn commit -m "msg"  # Directly commit working directory changes

The staging area allows:

• Partial commits (only adding specific changes).
• Staging changes without immediately committing.
• More precise control over commit content.

Modifying and Undoing History

Git supports non-destructive history modification:

# Amend the last commit
git commit --amend

# Interactive rebase (modify multiple commits)
git rebase -i HEAD~3

Systems like SVN typically prohibit modifying pushed history, requiring new versions to undo changes:

svn merge -c -123 ^/trunk  # Undo changes from revision 123

Performance Comparison

Git has weaker support for large binary files (e.g., videos, design drafts) and requires the Git LFS extension:

# Configure LFS to track PSD files
git lfs track "*.psd"

Collaboration Workflow Differences

Git supports multiple collaboration models:

• Centralized workflow (similar to SVN).
• Feature branch workflow.
• Forking workflow (commonly used on GitHub).
• Layered repositories (Gerrit's parent/child repositories).

SVN typically only has:

• Trunk-based development.
• Branch release models.

Example of typical Git team collaboration:

# Contributor actions
git fork upstream-repo
git clone my-fork
git checkout -b feature
git push origin feature
# Create PR/MR

# Maintainer actions
git fetch origin feature
git merge --no-ff feature

Metadata Management

Git stores minimal metadata:

• User information (name/email).
• Commit timestamps.
• Optional GPG signatures.

Enterprise VCS like Perforce support:

• File attribute systems.
• Change list descriptions.
• Integration with ticketing systems.
• Fine-grained permission controls.

Submodules and External References

Git submodules are essentially independent repositories:

git submodule add https://github.com/lib/library.git

SVN's external references (svn:externals) can be:

• Directories within the same repository.
• Paths to external repositories.
• Fixed or floating versions.

Configuration and Hooks

Git's configuration hierarchy (system/global/local/repository):

git config --global alias.st status

SVN's hook scripts are server-side:

repo/hooks/
├── pre-commit.tmpl
└── post-commit.tmpl

Git's client-side hooks are more extensive:

• pre-commit (checks before committing).
• prepare-commit-msg (edits commit messages).
• post-receive (triggers CI after pushing).

Migration and Interoperability

Tools for migrating from SVN to Git:

# Using git-svn for bidirectional bridging
git svn clone -s http://svn.example.com/repo

Collaboration solutions in hybrid environments:

• Git as an SVN frontend (git-svn).
• SubGit server-side mirroring.
• Manual patch exchange (git format-patch).