Lesson 5 — Beginner

Git & Collaboration

Git sirf backup nahi — wo tumhara project ka time machine aur team ka coordination tool hai. Is lesson mein repos, commits, staging aur diffs se shuru karke branches, remotes, PR workflow, commit messages, merge conflicts, .gitignore aur README tak jayenge — end mein doosra developer tumhara repo padh kar chala le, yahi target hai.

Git kya hai — snapshot ka khel

Chaar jagah yaad rakho: working directory (jahan edit karte ho), staging area (jis change ko next commit mein daalna hai), commit (snapshot + message), aur remote (GitHub jaisa copy jahan push/pull karte ho). Git ka poora khel in chaar ke flow mein hai.

Staging, commits aur history

git status                  # kya badla, kya staged hai
git diff                    # staged se pehle ka difference — padho
git add app/routes/orders.py
git diff --staged           # jo abhi commit hone ja raha hai — yahi review hota hai
git commit -m "orders: reject past start time with 422"

git log --oneline -5        # history chhoti rakho
git show --stat HEAD        # last commit mein kya badla

• Flow: edit -> git add (staging) -> git commit. Staging ka matlab "ye changes is commit mein jaane hain" — ek file ke do hisse alag-alag bhi stage ho sakte hain.
• Diff hi review material hai — commit se pehle hamesha git diff --staged padho. Jo file aap sochte ho wahi nahi badli, aksar kuch aur bhi badal jaata hai.
• Commit message: "fix" ya "update" nahi — kya kiya aur kyun. Format: scope: change, jaise "orders: reject past start time with 422".
• History padhna: git log --oneline, git show, git blame (line kisne kab likhi). Bug aaye toh blame se culprit commit milta hai.

Branches, remotes aur PR workflow

git switch -c feature/booking-clash     # nayi branch
# ... kaam karo, add, commit ...
git push -u origin feature/booking-clash

# Remote (GitHub) pe PR kholo -> review -> CI green -> merge
# Merge ke baad:
git switch main
git pull                                # main ka latest lo
git branch -d feature/booking-clash      # kaam khatam, branch delete

• Branch = feature ka scratch space. Main hamesha chalne layak rehni chahiye — isliye direct commit nahi, PR se hi merge.
• Remote aur origin: GitHub repo ka naam origin hota hai. Push = wahan bhejo, pull = wahan se lo (aur local tracking branch update).
• PR workflow: branch -> commit -> push -> pull request -> review -> CI -> merge. Pull request ka matlab "mera change review kar lo".
• Protected main: merge sirf reviewed PR se, force-push disabled — team ke liye safety net. Chhoti PRs hi sach mein padhi jaati hain.

Merge conflicts — darr nahi, normal cheez

<<<<<<< HEAD
    if starts_at < datetime.now():
        raise HTTPException(status_code=422, detail="Past time")
=======
    if starts_at <= datetime.now(timezone.utc):
        raise ValueError("start must be in the future")
>>>>>>> feature/booking-clash

# 3 steps: dono versions padho -> sahi wala rakho (ya dono ka behtar merge) -> markers hatao
git add bookings.py
git commit                                  # merge complete

• Conflict ka matlab: do branches ne ek hi jagah ko alag tarike se badla. Git decide nahi kar sakta — insaan chunta hai. Ye error nahi, normal collaboration signal hai.
• Resolve: markers (<<<<<<< ======= >>>>>>>) ke beech dono padho, sahi rakho, markers delete, file save, git add, git commit. Bas.
• Conflict chhota rakho: chhote diffs, chhote commits, jaldi merge — lambi chalti branches ek dusre se door hoti jaati hain aur conflict badhta hai.
• Tools: VS Code markers highlight karke resolve karwa deta hai — lekin markers padhna zaroori hai, blind "accept theirs" kabhi nahi.

.gitignore, README aur code review

# .gitignore — env, secrets, generated sab bahar
.env
.env.*
!.env.example

__pycache__/
*.pyc
.venv/
.pytest_cache/
.mypy_cache/

.idea/
.vscode/
.DS_Store

# README.md skeleton — 5 headings kaafi hain

# Bookings API

Chhoti room-booking REST service — FastAPI + PostgreSQL.

## Install & run
uv sync
cp .env.example .env      # apne values daalo
uv run uvicorn app.main:app --reload

## Test
uv run pytest -q

## API
GET    /health     200
POST   /rooms      201 | 422
POST   /bookings   201 | 409, 422

## Config
.env.example dekho — DATABASE_URL zaroori hai.

• .gitignore ka rule: generated, local aur secret — teeno bahar. Virtual env, caches, .env — ye sab repo mein gaye toh repo bhaari aur dangerous dono.
• Ek baar secret commit ho gaya toh gitignore aage se rok nahi payega — history mein pada rahega. Fix: rotate + history se hatana padta hai. Prevention sasta hai.
• README = pehla impression. Kya karta hai, install, configure, run, test, API — yehi5 headings interview mein bhi kaafi hain.
• Code review: diff dekh kar poochho — kya ye sahi hai, tests hain, error handling hai. Niraasha ki jagah sawaal karo; PR chhota ho toh review sach mein hota hai.

Exercise

Common mistakes

• .env aur .venv ko commit kar lena: Secrets history mein chale jaate hain aur repo bhaari ho jaata hai. Fix: gitignore pehle din, secrets rotate, .env.example sirf names ke liye commit.
• Vague commit messages: "fix" ya "update" se do saal baad pata nahi chalta kya hua. Fix: scope + change + why, jaise "orders: reject past start time with 422".
• Main pe direct commit aur force push: Team ki history mit jaati hai aur review ka raasta khatam. Fix: feature branch -> PR -> merge. Force push protected branches par kabhi nahi.
• Conflict ka darr aur andha accept: Do versions mein se bina padhe koi bhi choose karna ek side ka kaam mita deta hai. Fix: dono padho, sahi merge karo, phir markers hata kar commit.

git switch -c page-4-booking      # naya page khola
git add . && git commit -m "page-4: 3 bookings added"   # entry likhi
git push origin page-4-booking    # register office bheja
git switch main && git pull       # master ka latest liya