Mastering Git Basics | Tutorials

What You’ll Learn in This Tutorial

Initializing a Git repository (init)
Staging changes (add)
Creating commits (commit)
Pushing to remote (push)

Prerequisites: Git must be installed. If git --version displays a version, you’re good to go.

What is Git? Why Was It Created?

Git’s Origin

Git was developed by Linus Torvalds (creator of the Linux kernel) in 2005.

At the time, Linux kernel development used a commercial version control system called “BitKeeper.” However, when licensing issues made BitKeeper unavailable, Linus created a new version control system in just two weeks. That was Git.

“The name Git is British slang for ‘unpleasant person.’ Linus tends to give his projects self-deprecating names.”

Problems Git Solved

Distributed version control: Each developer has a complete history without depending on a central server
Fast operations: Most operations complete locally, making them very fast
Lightweight branching: Branches can be created and switched instantly
Data integrity: All changes are cryptographically protected with SHA-1 hashes

Git Today

Today, Git is the most widely used version control system in the world. According to Stack Overflow’s 2022 survey, over 93% of developers use Git.

Understanding Git’s Internal Structure

To use Git effectively, it’s important to understand its internal mechanisms.

The Three Areas

Git has three main areas:

flowchart LR
    WD["Working Directory<br/>(Working Dir)"]
    SA["Staging Area<br/>(Index)"]
    Repo["Repository<br/>(.git)"]

    WD -->|git add| SA
    SA -->|git commit| Repo

Working Directory: Where you actually edit files
Staging Area (Index): Where you prepare changes for the next commit
Repository (.git): Where committed history is stored

Git Object Model

Git manages data with four types of objects:

blob: File contents
tree: Directory structure
commit: Snapshot + metadata
tag: Reference to a specific commit

All objects are identified by SHA-1 hash (40-character hexadecimal).

Step 1: Repository Initialization

First, create a project directory and initialize it as a Git repository.

# Create project directory
mkdir my-first-repo
cd my-first-repo

# Initialize as Git repository
git init

When you run git init, a hidden folder called .git is created. This is where Git’s management information is stored.

Inside the .git Directory

$ ls -la .git/
├── HEAD          # Reference to current branch
├── config        # Repository-specific settings
├── hooks/        # Git hook scripts
├── objects/      # All Git objects
└── refs/         # References to branches and tags

Official Documentation: git-init

Step 2: Creating and Staging Files

Create a new file and add it to Git’s management.

# Create README file
echo "# My First Repository" > README.md

# Check status
git status

# Stage the file
git add README.md

# Check status again
git status

git add adds changes to the staging area. This is the operation of selecting “changes to include in the next commit.”

Why is the Staging Area Needed?

“The staging area is a buffer for organizing commits into logical units. You don’t have to commit everything at once.” — Pro Git Book

The staging area allows you to:

Partial commits: Select only some changes from multiple modifications
Review: Confirm what to include before committing
Atomic commits: Group only related changes together

Common add Patterns

# Add specific file
git add filename.txt

# Add all changes
git add .

# Add specific extension
git add *.js

# Add interactively (select partial changes)
git add -p

Official Documentation: git-add

Step 3: Creating a Commit

Record staged changes as a commit.

# Create commit
git commit -m "Initial commit: Add README"

# Check commit history
git log

Writing Good Commit Messages

Conventional Commits is a widely adopted convention:

<type>(<scope>): <subject>

<body>

<footer>

Type examples:

feat: New feature
fix: Bug fix
docs: Documentation
style: Formatting changes
refactor: Refactoring
test: Adding/modifying tests
chore: Build configuration, etc.

Examples of good commit messages:

# Good examples
git commit -m "feat: Add user authentication"
git commit -m "fix: Resolve login button not working on mobile"
git commit -m "docs: Update API documentation"

# Bad examples
git commit -m "fix"
git commit -m "Update"
git commit -m "changes"

Best Practice: Write in the format “Applying this commit will [do something].” Use imperative mood in present tense.

Official Documentation: git-commit

Step 4: Pushing to Remote Repository

Create a remote repository on GitHub etc., and push local changes.

# Add remote repository
git remote add origin https://github.com/username/my-first-repo.git

# Push main branch
git push -u origin main

The -u option sets the upstream branch so you can just use git push next time.

Checking Remote

# Check configured remotes
git remote -v

# Example output:
# origin  https://github.com/username/my-first-repo.git (fetch)
# origin  https://github.com/username/my-first-repo.git (push)

Official Documentation: git-push

Basic Workflow Summary

# Daily workflow
git status              # Check current status
git add .               # Stage changes
git commit -m "message" # Create commit
git push                # Push to remote

Visualizing Git Operations

flowchart LR
    WD["Working Directory"]
    SA["Staging Area"]
    Repo["Repository"]

    WD -->|git add| SA
    SA -->|git commit| Repo
    Repo -->|git checkout| WD
    Repo -->|git reset --soft| SA

Common Mistakes and Anti-Patterns

1. Huge Commits

# Bad example: Commit everything at once
git add .
git commit -m "Add all features"

# Good example: Split into logical units
git add src/auth/
git commit -m "feat: Add authentication module"

git add src/api/
git commit -m "feat: Add API endpoints"

2. Committing Sensitive Information

# Files that should be added to .gitignore
.env
*.pem
config/secrets.yml
node_modules/

3. Skipping Commit Messages

Commit messages are documentation for your future self and other developers. Write meaningful messages.

Common Troubles and Solutions

Wrong Commit Message

# Fix the previous commit message
git commit --amend -m "new message"

Note: Avoid modifying commits that have already been pushed. Rewriting history affects other developers.

Undo add

# Unstage (keep file changes)
git reset HEAD filename.txt

# New command from Git 2.23+
git restore --staged filename.txt

Undo the Previous Commit

# Undo commit, return changes to staging
git reset --soft HEAD~1

# Undo commit, return changes to working directory
git reset HEAD~1

# Completely delete commit and changes (dangerous)
git reset --hard HEAD~1

Restore a Specific File to Previous State

# Restore file from specific commit
git checkout <commit-hash> -- filename.txt

# Git 2.23+
git restore --source=<commit-hash> filename.txt

Configuration Best Practices

If you’re using Git for the first time, configure these settings:

# Set username and email (required)
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

# Set default branch name to main
git config --global init.defaultBranch main

# Auto-convert line endings (macOS/Linux)
git config --global core.autocrlf input

# Set editor
git config --global core.editor "code --wait"

# Enable color output
git config --global color.ui auto

Next Steps

Once you’ve mastered basic operations, learn how to use branches. It’s an essential skill for team development.

Resources for continued learning:

Learn branching strategies → Practicing Git Branch Strategies
Learn interactively → Learn Git Branching

Reference Links

Official Documentation

Git Official Documentation - Official reference
Pro Git Book - Free comprehensive Git guide

Tools

GitHub Desktop - GUI for Git
GitLens (VS Code extension) - Visualize Git history in VS Code
Learn Git Branching - Interactive Git learning site

← Back to list