Introduction to Git Version Control

Introduction

Version control is essential for any development project, and for years SVN (Subversion) and CVS have been the standard choices. But there's a new player gaining serious traction: Git.

Created by Linus Torvalds in 2005 for Linux kernel development, Git takes a fundamentally different approach to version control. Instead of a central repository, Git is distributed – every developer has a complete copy of the repository. This might sound complicated, but it offers significant advantages.

Why Git?

If you're comfortable with SVN, you might wonder why you should switch. Here are the compelling reasons:

Speed: Git operations are blazing fast. Commits, diffs, and history browsing happen locally, so there's no network latency.

Distributed workflow: You can work offline and commit changes without needing access to a central server. This is perfect for working on planes, trains, or anywhere without reliable internet.

Branching and merging: Git makes branching incredibly cheap and easy. Creating a branch takes milliseconds, and Git's merging capabilities are far superior to SVN's.

Data integrity: Git uses SHA-1 hashes to identify all objects, making it virtually impossible to corrupt the repository without Git knowing about it.

Git vs SVN

Coming from SVN, here are the key differences:

Feature	SVN	Git
Architecture	Centralized	Distributed
Speed	Network dependent	Local operations are instant
Branching	Slow, heavyweight	Fast, lightweight
Working offline	Limited	Full functionality
Learning curve	Gentle	Steeper initially

Installing Git

On Linux (Ubuntu/Debian):

sudo apt-get install git-core

On Mac, you can use MacPorts:

sudo port install git-core

On Windows, download Git from git-scm.com and run the installer.

Verify installation:

git --version

Basic Configuration

Before using Git, set up your identity:

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

This information will be attached to your commits.

Creating Your First Repository

Let's create a new Git repository:

# Create a new directory
mkdir myproject
cd myproject

# Initialize Git repository
git init

# You'll see: Initialized empty Git repository in /path/to/myproject/.git/

That's it! You now have a Git repository. The .git directory contains all the version control information.

The Basic Workflow

Git has three main states for files:

Working directory: Your actual files
Staging area (index): Files marked to go into the next commit
Repository: Committed snapshots

Here's the basic workflow:

# Create a file
echo "Hello Git" > README.txt

# Check status
git status

# Add file to staging area
git add README.txt

# Commit to repository
git commit -m "Initial commit with README"

Understanding git status

The git status command is your best friend:

$ git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       README.txt
nothing added to commit but untracked files present

This tells you what Git sees in your working directory.

Making Changes

Let's modify a file and commit the changes:

# Edit the file
echo "More content" >> README.txt

# See what changed
git diff

# Stage the changes
git add README.txt

# Commit
git commit -m "Added more content to README"

Viewing History

See your commit history:

# Full history
git log

# Compact view
git log --oneline

# With file changes
git log --stat

Each commit has a unique SHA-1 hash that identifies it.

Branching Basics

This is where Git really shines. Branching is cheap and easy:

# Create a new branch
git branch experimental

# List branches
git branch

# Switch to the branch
git checkout experimental

# Make changes and commit
echo "Experimental feature" > feature.txt
git add feature.txt
git commit -m "Added experimental feature"

# Switch back to master
git checkout master

Notice that feature.txt disappears when you switch branches! Git changes your working directory to match the branch.

Merging Branches

When you're happy with changes in a branch, merge them:

# Make sure you're on master
git checkout master

# Merge experimental branch
git merge experimental

If there are no conflicts, Git will automatically merge the changes.

Working with Remote Repositories

While Git is distributed, you often want a central location for collaboration. GitHub is becoming popular for this (though it's still fairly new).

# Clone an existing repository
git clone git://example.com/project.git

# See remote repositories
git remote -v

# Fetch changes from remote
git fetch origin

# Pull changes (fetch + merge)
git pull

# Push your changes
git push origin master

Common Commands Cheat Sheet

# Initialize repository
git init

# Clone repository
git clone <url>

# Check status
git status

# Stage files
git add <file>
git add .              # Stage all changes

# Commit
git commit -m "message"

# View history
git log

# Create branch
git branch <name>

# Switch branch
git checkout <name>

# Merge branch
git merge <name>

# Update from remote
git pull

# Push to remote
git push

Tips for SVN Users

If you're coming from SVN:

git add is not svn add: In Git, you run git add not just for new files, but every time you want to stage changes. Think of it as "add this content to the next commit."

Commit locally, push remotely: In Git, committing is a local operation. Use git push to send commits to a remote repository.

Branching is different: Git branches are lightweight pointers, not directory copies like in SVN. Don't be afraid to create branches.

Understanding .gitignore

Tell Git to ignore certain files:

# Create .gitignore file
cat > .gitignore << EOF
*.log
*.tmp
build/
.DS_Store
EOF

git add .gitignore
git commit -m "Added gitignore file"

Now Git will ignore these files.

When Things Go Wrong

Made a mistake? Git has you covered:

# Unstage a file
git reset HEAD <file>

# Discard changes in working directory
git checkout -- <file>

# Amend the last commit
git commit --amend

Why I'm Switching

I've been using SVN for years, but I'm making the switch to Git for my projects. The ability to commit offline, the speed of operations, and the powerful branching model are game-changers.

The learning curve is steeper than SVN, but it's worth it. Once you understand Git's model (working directory, staging area, repository), everything clicks into place.

Learning Resources

To learn more:

Pro Git book: Available online for free
git-scm.com: Official Git website with documentation
man pages: man git-<command> for detailed help
Practice: The best way to learn is to use Git on a real project

Wrapping Up

Git represents a new way of thinking about version control. Instead of a central authority, you have a distributed system where every copy is equal. This enables new workflows and makes many operations faster and more flexible.

Is it perfect? No. The learning curve is real, and some concepts take time to grasp. But the benefits – speed, offline capability, powerful branching, and data integrity – make it worth learning.

If you're starting a new project, consider giving Git a try. You might find, like many developers are discovering, that there's no going back to centralized version control.