3. 🧭 Git for Everyday Development

Git is the most widely used version control system in software development.
It helps you track changes, collaborate safely, and recover mistakes.
This guide is written for beginners who want to understand why each Git step matters and when to use it in real projects.

3.1. ⚙️ 1. Setting Up Git (Once per Machine)

3.1.1. 🧩 Why this matters

Before using Git on any project, you must tell Git who you are and how it should behave.
This information will appear in every commit and helps collaborators know who made which changes.

3.1.2. 🕐 When to do this

Do it once after installing Git — it applies globally to all repositories on your computer.

3.1.3. 🧠 Commands

git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main
git config --global fetch.prune true
git config --global core.autocrlf input   # for mac/linux
# or on Windows:
# git config --global core.autocrlf true

3.1.4. 💡 Real-world tip

If you work with GitHub, set up SSH keys to avoid typing passwords every time:

ssh-keygen -t ed25519 -C "you@example.com"

Add your public key to GitHub under Settings → SSH and GPG keys.

3.2. 📁 2. Initialize a Local Repository

3.2.1. 🧩 Why this matters

A repository (repo) is where Git tracks your project’s files and their changes.
Initializing one tells Git, “start version control here.”

3.2.2. 🕐 When to use it

When you start a new project from scratch or want to version-control an existing folder.

3.2.3. 🧠 Commands

mkdir my-project && cd my-project
git init
echo "# My Project" > README.md
git add .
git commit -m "chore: initial commit"

3.2.4. 💡 Real-world tip

Use a .git folder (created automatically) to store all Git metadata.
Do not delete it — it’s your project history!

Check current status anytime:

git status

3.3. 🌐 3. Connect to a Remote Repository (GitHub, GitLab, etc.)

3.3.1. 🧩 Why this matters

A remote repository lives on the internet and allows team collaboration.
Connecting your local repo to a remote lets you share your code or back it up.

3.3.2. 🕐 When to use it

When you want to push your local work to GitHub (or clone from an existing repo).

3.3.3. 🧠 Commands

Case 1 — Push local repo to remote

git remote add origin git@github.com:yourname/my-project.git
git branch -M main
git push -u origin main

Case 2 — Clone an existing remote

git clone git@github.com:org/project.git
cd project

3.3.4. 💡 Real-world tip

Use git remote -v to check connected remotes.
You can rename or replace them later using:

git remote set-url origin <new-url>

3.4. 🌿 4. Branching — Working on Features Safely

3.4.1. 🧩 Why this matters

Branches let you work on new features without breaking the main code.
You can later merge tested changes back into the main branch.

3.4.2. 🕐 When to use it

Before starting a new feature, bug fix, or experiment.

3.4.3. 🧠 Commands

# Create and switch to a new branch
git switch -c feat/login-page

# View branches
git branch

# Push it to remote for collaboration
git push -u origin feat/login-page

3.4.4. 💡 Real-world tip

• Prefix branch names: feat/, fix/, chore/, docs/, etc.

• Delete branches after merging to keep your repo clean:

  git branch -d feat/login-page
  git push origin --delete feat/login-page
  

3.4.5. 🧪 Hands-on task

1. Create a branch feat/homepage

2. Edit files and commit changes

3. Push the branch to GitHub

4. Open a Pull Request from that branch

3.5. 🔄 5. Merging and Keeping Up-to-Date

3.5.1. 🧩 Why this matters

Merging combines work from different branches.
Keeping your feature branch updated avoids big conflicts later.

3.5.2. 🕐 When to use it

• When your teammate updates main, and you want those changes

• When you’ve finished your feature and want to merge it back

3.5.3. 🧠 Commands

Update your feature branch

git fetch origin
git switch main
git pull
git switch feat/homepage
git merge main

Merge feature into main

git switch main
git merge feat/homepage
git push

3.5.4. 💡 Real-world tip

If your team prefers clean, linear history, use rebase instead of merge:

git switch feat/homepage
git fetch origin
git rebase origin/main

Rebase rewrites commit order but avoids messy merge commits.

3.6. ⚔️ 6. Solving Merge Conflicts

3.6.1. 🧩 Why this matters

When two people edit the same file lines differently, Git can’t decide which one to keep.
That’s a merge conflict — you must resolve it manually.

3.6.2. 🕐 When to use it

During git merge or git rebase if Git reports conflicts.

3.6.3. 🧠 How to fix

1. Open conflicted file — you’ll see:

   <<<<<<< HEAD
   your code
   =======
   teammate's code
   >>>>>>> main
   

2. Manually edit to the correct version.

3. Then mark resolved:

   git add filename
   git merge --continue   # or git rebase --continue
   

3.6.4. 💡 Real-world tip

• Use IDE merge tools (VS Code, PyCharm, etc.) to make it visual.

• If it gets messy:

  git merge --abort
  

  and try again after pulling latest changes.

3.7. 🚫 7. Using .gitignore — Keep Unwanted Files Out of Git

3.7.1. 🧩 Why this matters

Some files (like build outputs, logs, or credentials) should never be tracked by Git.
.gitignore defines which files to exclude.

3.7.2. 🕐 When to use it

At the start of your project, or when adding new tools that generate temporary files.

3.7.3. 🧠 Example

# Dependencies
node_modules/
venv/
__pycache__/

# Builds
dist/
build/

# Logs
*.log

# Environment
.env

# System files
.DS_Store
Thumbs.db

3.7.4. 💡 Real-world tip

If you accidentally tracked ignored files:

git rm -r --cached .
git add .
git commit -m "chore: apply .gitignore"

3.8. 💾 8. Committing, Pushing, and Reviewing Changes

3.8.1. 🧩 Why this matters

Each commit represents a meaningful snapshot of your work.
Pushing uploads commits to the remote repo so teammates can review them.

3.8.2. 🕐 When to use it

After completing a small, testable unit of work (not too big, not too small).

3.8.3. 🧠 Commands

git status             # check what changed
git add file.js        # stage specific file
git add .              # stage all
git commit -m "feat: add login validation"
git push               # send to remote

3.8.4. 💡 Real-world tip

Write clear commit messages:

• ✅ fix: correct password validation regex

• ❌ update code or stuff fixed

To amend last commit (e.g., forgot a file):

git add missing.js
git commit --amend

3.9. 🧰 9. Undo, Recover, and Experiment Safely

3.9.1. 🧩 Why this matters

Git makes mistakes reversible — you can go back in time.
Understanding these tools helps you experiment confidently.

3.9.2. 🕐 When to use it

When you accidentally delete, break, or commit something wrong.

3.9.3. 🧠 Commands

git restore file.txt                # undo local changes
git reset HEAD~1                    # undo last commit (keep files)
git reset --hard HEAD~1             # remove last commit completely
git reflog                          # view all actions (time travel log)

Recover old versions:

git checkout <commit-id>

3.9.4. 💡 Real-world tip

Never use --hard on shared branches like main.
If you break something, look in git reflog — it’s your safety net.

3.10. 🪄 10. Handy Tools: Stash, Cherry-Pick, and Tags

3.10.1. 🧩 Why this matters

These are pro-level helpers for multitasking, copying commits, or marking versions.

3.10.2. 🕐 When to use them

• Stash: when you must switch branches but aren’t ready to commit.

• Cherry-pick: when you need one specific commit from another branch.

• Tags: when you release or mark milestones.

3.10.3. 🧠 Commands

# stash work in progress
git stash push -m "WIP: new feature"
git switch main
git stash pop

# copy a specific commit
git cherry-pick <commit-id>

# mark a release
git tag -a v1.0.0 -m "Version 1.0"
git push origin v1.0.0

3.10.4. 💡 Real-world tip

Use tags for versioning — they act as named snapshots for deployments.

3.11. 🔁 11. Typical Daily Git Workflow

3.11.1. 🧩 Why this matters

A clear daily routine prevents conflicts and keeps your repository organized.

3.11.2. 🕐 When to use it

Every workday — it’s your main habit loop.

3.11.3. 🧠 Example

# 1. Update main
git switch main
git pull

# 2. Create a feature branch
git switch -c feat/dashboard

# 3. Work & commit
git add .
git commit -m "feat: add dashboard layout"

# 4. Sync often
git fetch origin
git merge origin/main

# 5. Push and create a Pull Request
git push -u origin feat/dashboard

3.11.4. 💡 Real-world tip

Pull before starting work every day to reduce conflicts.
Always test before committing to keep history clean.

3.12. 🧠 12. Summary and Next Steps

Concept	Why it matters	When to use
git init	Start version control	Beginning of any project
git add / git commit	Save progress with history	After finishing a small unit of work
git branch / git switch	Work safely on new ideas	Before big feature or fix
git merge / git rebase	Combine work	When integrating changes
git push / git pull	Share work	With teammates / before PR
.gitignore	Exclude unwanted files	Always
git stash	Pause work temporarily	When switching tasks

3.12.1. ✅ You learned:

• How to set up and initialize Git

• How to connect with remote repositories

• How to branch, merge, and handle conflicts

• How to construct a .gitignore

• How to safely undo and recover work

Next steps: Learn about GitHub Pull Requests, rebasing strategies, and advanced history cleanup (rebase -i).

Git isn’t just about commands — it’s a safety net and collaboration tool.
The more you commit (both literally and figuratively), the easier it gets!