Git & GitHub Masterclass: Version Control Ka Complete Practical Guide

A Beginner-Friendly, Hands-On Guide to Git & GitHub — In Hinglish

By Prabhat Upadhyay · Reading time: ~60 minutes (4–5 hours with hands-on practice)

Is Guide Mein Kya Milega?

Agar aapne kabhi final.js, final_v2.js aur final_REAL_v3.js naam ki files banayi hain, toh yeh guide aapke liye hai. Yahan hum Git aur GitHub ko zero se seekhenge: har concept simple Hinglish mein, real commands, demo output aur practice exercises ke saath. Goal sirf commands ratna nahi hai. Goal hai andar ka logic samajhna, taaki aap interview mein bhi confidently bol sako aur company project mein bhi kaam kar sako.

Yeh guide kiske liye hai?

• Jinhone kabhi Git use nahi kiya (first timer).
• Jo bas git add aur git commit ratte hain, par andar ka logic nahi pata.
• Jo internship, interview ya team project ke liye Git ready karna chahte hain.

Roadmap

Is guide ko kaise padhein

1. Har chapter padhte time terminal khol ke saath-saath commands chalao. Sirf padhne se Git nahi aata.
2. Ek sandbox folder banao (jaise git-masterclass) aur saare experiments usi mein karo.
3. Har chapter ke end ka Mini Task zaroor karo, aur Chapter 15 ke exercises ke baad Chapter 16 mein answers se check karo.
4. VS Code mein Git Graph extension install kar lo. Git ko dekhna usse samajhne ka sabse aasaan tareeka hai.

Pro tip: Git mein galti se kuch bhi tootne ka darr mat rakho. Jab tak aap sandbox folder mein ho, jitna chahe experiment karo.

Is guide ke symbols

• Bold points yaad rakhne layak hain, interview mein bhi kaam aate hain.
• Code blocks mein jo bhi hai, woh aap terminal mein seedha type karke try kar sakte ho.
• <angle brackets> ka matlab hai wahan apni value daalni hai, jaise <branch-name>.
• Mini Task = chhota practice. Exercise = chapter ke end ka bada practice.
• Text-based diagrams aur command outputs concepts ko samajhne mein help karte hain; unhe terminal mein khud run karke verify karein.

Windows users ke liye note: Git install karte waqt Git Bash bhi aa jaata hai. Is guide ke saare commands (ls, cat, mkdir) Git Bash mein seedhe chalte hain. Mac aur Linux par normal Terminal use karo.

PART 1: FOUNDATIONS

Chapter 1: Version Control System (VCS) Kya Hota Hai?

Is chapter ke baad aap jaanoge: VCS kya hai, source control kise kehte hain, aur bina VCS ke bade projects mein kya dikkat aati hai.

1.1 Ek chhote example se shuru karte hain

Maan lo aapke paas ek code file hai, index.js. Shuru mein usme sirf ek line hai:

const a = 24; 

Yeh code bilkul sahi chal raha hai. Ab time ke saath kya hota hai? Jab hum bade project par kaam karte hain, toh code mein bahut saare changes aate hain. Naye features add hote hain, code refactor hota hai, purana code badla jaata hai.

Din 1 (aaj): aapne ek variable add kiya.

const a = 24; const name = "Aman"; 

Din 2 (kal): ek doosre developer ne ek function add kar diya.

const a = 24; const name = "Aman"; function getName() { return name; } 

Din 3: kisi ne name ka naam badalkar name1 kar diya.

const a = 24; const name1 = "Aman"; function getName() { return name; // BUG: name ab exist hi nahi karta! } 

Yahan ek bug aa gaya, kyunki function name dhundh raha hai, jabki variable ka naam ab name1 hai.

1.2 Asli problem kya hai?

Hamara code time ke saath badal raha hai aur badhta ja raha hai. Sawaal yeh uthte hain:

• Hum yeh track kaise karein ki kab, kisne, kya badla?
• Agar kuch toot jaye toh purani working state par wapas kaise jayein?
• Agar 10 log ek saath kaam karein toh sab kuch manage kaise karein?

Agar koi system hi nahi hai, toh yeh sab possible nahi hoga. Bade code bases mein code manage karna bahut mushkil ho jayega.

1.3 Solution: Version Control System

Is poore track aur manage karne ke system ko kehte hain Version Control System (VCS). Isko Source Control bhi kaha jaata hai.

Definition: VCS ek aisa system hai jisse hum apne software code ke changes ko track aur manage kar sakte hain.

VCS aapko teen powers deta hai:

1. Timeline banana: pehle sirf ek line thi, phir doosri aayi, phir function aaya. Har state ek version ban jaati hai.
2. History dekhna: kaun si state se kaun si state mein code gaya, yeh saaf dikhta hai.
3. Revert karna: kisi bhi point of time par wapas ja sakte ho. Upar waali bug wali state kharab hai? Pichli sahi state par laut jao.

Version 1 Version 2 Version 3 (bug) [ a = 24 ] ---> [ a, name ] ---> [ a, name1, getName ] | "Revert" karke wapas Version 2 par 

1.4 Kaun-kaun se VCS hote hain?

Bazaar mein bahut saare VCS hain: Git, SVN (Subversion), Mercurial, Perforce. Lekin aaj duniya mein sabse zyada use hone wala VCS Git hai. Zyadatar service-based aur product-based companies apne source control ke liye Git hi use karti hain. Isliye hum bhi isi ko seekhenge.

1.5 Bahut zaroori fark: Git vs GitHub

Is baat ko Chapter 9 mein detail mein samjhenge. Abhi bas yaad rakho: VCS = Git. GitHub = Git ka online ghar.

Chapter 1 Recap

• Code time ke saath badalta hai, isliye usko track karna zaroori hai.
• VCS (Source Control) code ke changes ko track aur manage karta hai.
• Git sabse popular VCS hai. GitHub alag cheez hai.

Quick Check

1. VCS ka full form kya hai?
2. Bina VCS ke kaun-si 2 problems aati hain?
3. Git aur GitHub mein basic fark kya hai?

Chapter 2: Git Kya Hai Aur Kaise Install Karein?

Is chapter ke baad aap jaanoge: Git ki official definition, apni machine par Git install karna aur uska version check karna.

2.1 Git ki definition

Git ki official website par definition kuch aisi hai:

Git ek free aur open source distributed version control system hai.

Yaani Git ek VCS hai, bilkul wahi cheez jo humne Chapter 1 mein padhi. Yeh free hai, koi paisa nahi lagta.

2.2 Git kahan install hota hai?

Git ke saath kaam karne ke liye sabse pehle aapki local machine (aapka laptop) par Git install hona chahiye.

Dhyan rakho: yahan hum Git install kar rahe hain, GitHub nahi. GitHub ke liye koi installation nahi hoti, woh ek website hai.

2.3 Install kaise karein? (Step by step)

1. Browser mein git search karo. Official site hai git-scm.com.
2. Wahan Download button milega. Aapke OS (Windows, Mac, Linux) ke hisaab se option dikhega.
3. Windows: ek installer download hoga. Usko kholke Next, Next, Next karte jao aur install kar do. Isme Git Bash bhi aa jaata hai.
4. Mac: installer se ya package manager (jaise Homebrew) se install kar sakte ho.
5. Linux: apne package manager se, jaise Ubuntu par sudo apt install git.

2.4 Check karo ki Git install hua ya nahi

Apna Terminal kholo (Windows par Git Bash) aur yeh type karo:

git 

Enter dabate hi screen par commands ki lambi list print hogi. Iska matlab: haan, Git aapki machine par installed hai.

2.5 Version check karna

git --version 

Example output:

git version 2.43.0 

Version ka rule yaad rakho:

• Aapka exact version alag ho sakta hai (2.39, 2.43, 2.4x). Yeh sirf minor/patch ka fark hai, fikr ki baat nahi.
• Git ka installed version is example se alag ho sakta hai. Aam commands ke liye version number 2 hona compulsory nahi hai; agar kisi command ka output alag aaye, toh apne installed Git version ki documentation check karein.

2.6 Cheat sheet ka bookmark

Git ki ek cheat sheet hoti hai jisme har useful command likhi hoti hai. Is guide ke Chapter 14 mein ek poori cheat sheet di gayi hai. Usko apne paas rakho.

Chapter 2 Recap

• Git = free aur open source VCS.
• Git ko apni local machine par install karna padta hai (git-scm.com se).
• git aur git --version se install check karte hain.
• Git ka version alag ho sakta hai; commands ka behavior version aur configuration ke hisaab se vary kar sakta hai.

Mini Task

git --version 

Yeh command chalao aur apna version kisi note mein likh lo.

Chapter 3: Git CLI Aur Pehla Setup (git config)

Is chapter ke baad aap jaanoge: CLI kya hota hai, Git ko apna naam aur email kaise batate hain, aur yeh kyun zaroori hai.

3.1 CLI kya hota hai?

CLI = Command Line Interface. Jab hum Terminal mein commands likhkar computer se baat karte hain, usko CLI kehte hain. Is guide ki saari Git commands hum terminal (CLI) se hi chalayenge.

3.2 Setup kyun zaroori hai?

Sabse pehle Git ko local machine par setup karna hota hai. Is setup ko global config kehte hain. Isme hum Git ko batate hain:

• Mera naam kya hai?
• Meri email kya hai?

Kyun? Socho aap ek badi company mein kaam kar rahe ho jahan lakhon lines of code hain. Aapne ek line add ki. Ab Git ko pata hona chahiye ki yeh line kisne likhi. Isliye har commit ke saath author ka naam aur email store hota hai.

Example: koi line const d = "01/01/2000" likhi gayi. Git bata sakta hai: yeh line Prabhat Upadhyay ne likhi, is email id se, is waqt par.

3.3 Naam set karna

git config --global user.name "Prabhat Upadhyay" 

--global ka matlab: is machine par jitne bhi commits honge, sabme yahi naam dikhega.

3.4 Email set karna

git config --global user.email "prabhat@example.com" 

Aap apni khud ki email yahan daalna. (Agar GitHub use karoge, toh wahi email rakho jo GitHub account mein hai, taaki commits aapke profile se link hon.)

3.5 Check karo ki set hua ya nahi

git config --global user.name git config --global user.email 

Output mein aapka naam aur email aana chahiye. Agar pehle se set hai toh bhi aap dobara upar waali commands chalake overwrite kar sakte ho.

Saari config ek saath dekhni ho toh:

git config --list 

3.6 (Optional) Colors on karna

Colored terminal output chahiye toh:

git config --global color.ui auto 

Chapter 3 Recap

• CLI = terminal se commands chalana.
• git config --global user.name aur user.email se Git ko aapki pehchaan milti hai.
• Har commit mein author ka naam, email aur time save hota hai.

Mini Task

Apna naam aur email set karo, phir git config --list chalao aur dekho tumhari values dikh rahi hain ya nahi.

Chapter 4: Pehla Git Repository (git init)

Is chapter ke baad aap jaanoge: repository kya hota hai, git init kya karta hai, hidden .git folder kya hai, aur tracked/untracked ka matlab.

4.1 Ek sandbox folder banao

Terminal mein yeh karo:

mkdir git-masterclass cd git-masterclass code . 

• mkdir = folder banata hai.
• cd = us folder ke andar jaata hai.
• code . = us folder ko VS Code mein khol deta hai.

Abhi yeh folder bilkul khali hai.

4.2 Ek chhoti code file banao

VS Code mein ek nayi file banao, naam rakho index.js. Code kisi bhi language mein ho sakta hai (JS, C, C++, ya text file bhi). Hum JS lete hain:

const a = 24; 

Abhi hum is file mein changes kar rahe hain, lekin Git isko track nahi kar raha, kyunki humne Git ko bola hi nahi ki isko track karo.

4.3 Git ko initialize karo

Is project ko track karwane ke liye Git ko initialize karna padta hai:

git init 

Output kuch aisa aayega:

Initialized empty Git repository in C:/Users/prabhat/coding/git-masterclass/.git/ 

Repository (repo) kya hota hai? Repository ka matlab hai basically ek project. git init ne is folder mein Git enable kar diya. Ab Git is folder ko track kar sakta hai.

VS Code mein ab index.js ke aage ek U likha dikhega. U = Untracked. Yaani Git ko file ka pata hai, lekin abhi woh isko track nahi kar raha.

4.4 Hidden .git folder

git init ke baad ek hidden .git folder ban gaya. Dekhne ke liye:

ls -a 

Output:

. .. .git index.js 

(Windows File Explorer mein View → Hidden items on karo. Mac Finder mein Command + Shift + . dabao.)

.git folder ke andar Git yeh sab store karta hai:

• Aapke saare objects (files ki history)
• Saari configuration
• Kaise-kaise aapki files badli, uska poora record

Golden Rule: .git folder ko kabhi touch mat karo, kabhi delete mat karo, kabhi manually edit mat karo. Agar kisi project mein .git folder hai, iska matlab Git us project ko track kar raha hai. Delete kiya toh poori history chali jaayegi.

4.5 Ek must-have VS Code extension

VS Code mein Git Graph extension install kar lo. Isse aap poori commit history ko graph ki tarah dekh paoge. Beginners ke liye yeh bahut helpful hai.

Chapter 4 Recap

• Repository = ek project jisko Git track karta hai.
• git init = Git ko current folder mein enable karta hai.
• .git = hidden folder, jisme Git ka saara data hai. Isse chhedna nahi.
• VS Code mein U ka matlab untracked file.

Mini Task

1. Ek naya folder banao aur git init chalao.
2. ls -a se .git folder dekho.
3. Ek index.js banao aur check karo ki uske aage U dikh raha hai ya nahi.

Chapter 5: Files Ko Track Karna (git add, git diff, git rm, git status)

Is chapter ke baad aap jaanoge: git add se file track kaise karte hain, git add . ka matlab, git diff se changes kaise dekhte hain, git rm se file kaise hatate hain, aur git status kyun sabse zaroori command hai.

5.1 Ek file ko track karna: git add

Abhi index.js untracked (U) hai. Isko track karwane ke liye:

git add index.js 

Enter dabate hi Git ne is file ko track karna shuru kar diya. VS Code mein ab A (Added) dikhega.

Ab is file mein jo bhi changes karoge woh track honge. Example:

const a = 24; const name = "Aman"; 

VS Code mein naye add hui lines ke paas green line dikhegi (kuch add hua). Kuch hatate ho toh red marker dikhega (kuch remove hua).

5.2 Changes dekhna: git diff

git diff 

Yeh batata hai ki aapki file mein exactly kya badla hai:

• + se shuru hone wali lines = add hui lines
• - se shuru hone wali lines = remove hui lines

Example: agar aap name ko name1 karte ho toh diff aisa dikhega:

-const name = "Aman"; +const name1 = "Aman"; 

Yaani Git ne dikhaya ki purani line hati aur nayi line aayi.

5.3 Naya file aur uska add karna

Maan lo aapne ek aur file banayi, script.js:

function hello() { console.log("hello"); } 

Yeh file bhi pehle untracked hogi. Isko add karne ke liye wahi command:

git add script.js 

5.4 Saari files ek saath add karna: git add .

Real projects mein hazaaron files hoti hain, kayi folders ke andar. Har file ke liye alag git add karna possible nahi hai. Isliye:

git add . 

Yahan . (dot) ka matlab hai sab kuch. Yeh current directory ki saari files (folders ke andar ki bhi) ko track karwa deta hai.

Example se samjho. Ek utils folder banao aur uske andar utils.js:

function add(a, b) { return a + b; } 

Phir sirf ek command:

git add . 

Sab files tracked ho gayi. VS Code ka Source Control panel dikha dega ki index.js, script.js, aur utils/utils.js mein changes hain.

5.5 Track hatana: git rm

Agar galti se aapne koi file add kar di aur usko track nahi karna tha:

git rm <file-path> 

Dhyan se: git rm file ka tracking hatata hai aur file ko disk se delete bhi kar deta hai. Agar file ko apne paas rakhna hai aur sirf Git se hatana hai, toh git rm --cached <file-path> use karo.

5.6 Sabse zaroori command: git status

git status 

Yeh batata hai ki kaun-si file modified hai, kaun-si staged hai aur kaun-si untracked hai. Yeh Git ki sabse zyada use hone wali commands mein se ek hai. Iska poora upyog Chapter 7 mein samjhenge.

Sample output:

On branch main Changes to be committed: new file: index.js new file: script.js new file: utils/utils.js 

Chapter 5 Recap

Mini Task

1. index.js, script.js aur utils/utils.js banao.
2. git add . chalao.
3. git status se dekho kaun-si files add hui.
4. index.js mein ek line badlo aur git diff chalao.

Chapter 6: Commits Aur History (git commit, log, show, blame)

Is chapter ke baad aap jaanoge: commit kya hota hai, usko kaise banate hain, history kaise dekhte hain, aur clean commits kyun zaroori hain.

6.1 Commit kya hota hai?

Ab tak humne seekha ki files ko Git mein add kaise karte hain. Ab sawaal: time ke saath hone wale changes ko kaise save karein?

Pehle wala example yaad karo, jahan code ki 3 states thi:

1. Pehli state: sirf const a = 24;
2. Ghante baad: ek aur variable add hua.
3. Agle din: ek function add hua.

In teeno snapshots mein se har ek ko kehte hain commit.

Definition: Jab hum apne code mein changes karte hain aur lagta hai ki ek chhota kaam (changes ka ek set) poora ho gaya, toh hum usko commit karte hain. Commit = code ki us waqt ki saved state (snapshot).

6.2 Pehla commit banana

Pehle files ko add karo, phir commit karo:

git add . git commit -m "initial code added" 

• git commit = commit banao.
• -m = message dene ke liye.
• "initial code added" = commit message. Yeh ek user-friendly note hota hai jo batata hai ki is commit mein kya kiya.

Sample output:

[main (root-commit) 7d2f9b1] initial code added 3 files changed, 9 insertions(+) create mode 100644 index.js create mode 100644 script.js create mode 100644 utils/utils.js 

Commit ban gaya. Is waqt hamare code ki state: index.js, script.js, utils/utils.js teeno files. VS Code mein ab har line ke upar dikhta hai ki kisne yeh code add kiya (kyunki humne config mein naam daala tha) aur kitni der pehle.

6.3 Commit history dekhna: git log

git log 

Output kuch aisa dikhega:

commit 7d2f9b1e4a6c0d3f5b8a1c2e9d7f4b6a3c5e8d10 (HEAD -> main) Author: Prabhat Upadhyay <prabhat@example.com> Date: Tue Oct 27 10:30:00 2026 +0530 initial code added 

Isme hum dekh sakte hain:

• Commit ID (SHA hash): har commit ki ek unique ID hoti hai.
• Message: initial code added.
• Author: kisne kiya (humari config se aaya).
• Date: kab kiya.

6.4 History ko chhota karke dekhna

git log --oneline 

Isse har commit sirf ek line mein dikhta hai (chhoti ID + message). Bahut neat aur padhne mein aasaan:

3f9a1c2 added isAbove18 function 7d2f9b1 initial code added 

Chhoti ID kyun chalti hai? Poori SHA ID bahut lambi (40 characters) hoti hai, lekin uske shuruaati 7 characters bhi commit ko pehchanne ke liye kaafi hote hain.

6.5 Doosra commit banate hain

index.js mein ek function add karo:

function isAbove18(age) { return age >= 18; } 

Phir git diff se dekho ki kya badla, aur commit karo:

git diff git add . git commit -m "added isAbove18 function" git log --oneline 

Ab do commits ho gaye. Pehle commit se doosre commit mein code ne transition kiya, aur hum saare changes dekh sakte hain.

6.6 Kisi commit mein kya badla: git show

git show <commit-id> 

Example: git show 3f9a1c2. Yeh us particular commit ke andar jo bhi changes hue the (kaun-si file, kaun-si lines add/remove hui), woh dikha deta hai. Isse aap visualize kar sakte ho ki kis commit mein kya hua.

6.7 Kisne kaunsi line likhi: git blame

git blame index.js 

Yeh line by line dikhata hai ki kaun-si line kis author ne, kitne baje, kis commit mein badli. Bade projects mein jab ek bug aaye aur pata karna ho ki yeh line kisne likhi, tab blame bahut kaam aata hai. Format:

git blame <file-path> 

VS Code mein agar kisi line par hover karo toh bhi yahi blame info dikhti hai.

6.8 Clean commits kyun zaroori hain?

Naye students aksar kya karte hain? Poora ka poora code ek hi commit mein daal dete hain. Isse tracking kharab ho jaati hai.

Sahi tareeka:

1. Ek functionality par kaam karo → uska commit banao.
2. Doosri functionality par kaam karo → alag commit banao.
3. Teesri functionality → alag commit.

Saara code ek hi commit mein push nahi karna chahiye. Experience ke saath samajh aayega ki clean commit history kaise maintain karte hain. Yeh habit highly recommended hai.

Achhe commit message ka tip: message ko aisa likho ki 6 mahine baad padhkar bhi samajh aaye. Jaise "fix login button not responding", na ki "changes" ya "abc".

6.9 Ek aur commit: code hatana

isAbove18 function ko hata do, phir:

git add . git commit -m "remove isAbove18 function" git log --oneline 

Ab 3 commits hain. Har commit ka ek message, ek ID aur ek author hota hai. Isko hi kehte hain commit history.

Chapter 6 Recap

Mini Task

3 alag commits banao (ek function add, ek variable add, ek function remove) aur git log --oneline se unko dekho.

Chapter 7: Staging Area (Git Ka Internal Flow)

Is chapter ke baad aap jaanoge: staging area kya hai, git status kaise padhte hain, aur kyun git add ke bina git commit kuch nahi karta.

7.1 Pehle ek situation dekho

Maan lo aapne index.js mein ek naya function add kiya aur utils.js mein bhi ek change kiya. Ab git status chalao:

git status 

Changes not staged for commit: modified: index.js modified: utils/utils.js 

Git batayega ki yeh do files modified hain. Matlab: pichle commit ke baad yeh do files badli hain. Yeh aapka work in progress (WIP) hai.

Ab agar is point par aap seedha git commit -m "abc" karoge toh kuch bhi nahi hoga. Kyun? Kyunki commit karne ke liye kuch chahiye jo staging area mein ho, aur abhi staging area khali hai.

7.2 Teen jagah (Three Areas)

Git mein aapki file teen jagahon se guzarti hai:

1. Working Directory (local changes): jahan aap files edit karte ho. Yahan files modified dikhti hain.
2. Staging Area: ek taiyaari ka area. Jo changes aap agle commit mein daalna chahte ho, unko yahan laate ho.
3. Repository (commit history): jahan commits save hote hain.

Flow hamesha yeh hota hai:

 Working Directory Staging Area Repository (modified files) ---> (staged files) ---> (commits) git add git commit 

Staging area beech ki jagah hai: git add se file wahan jaati hai, aur git commit sirf wahi cheez repository mein save karta hai.

7.3 Ek file ko stage karna

Sirf index.js ko staging mein bhejna hai:

git add index.js git status 

Ab git status mein dikhega:

Changes to be committed: modified: index.js Changes not staged for commit: modified: utils/utils.js 

Yaani: jo changes staging mein gaye aur jo abhi local mein hi hain, dono alag dikh rahe hain.

7.4 Sirf staged changes commit karna

git commit -m "abc commit" git log --oneline 

Yeh command sirf wahi changes commit karegi jo staging area mein hain. Yani sirf index.js. Ab git show <commit-id> karo toh dikhega ki sirf index.js is commit mein gayi hai. Staging area ab khali ho gaya.

7.5 Baaki changes ka commit

utils.js abhi bhi modified hai. Ab usko bhi commit karte hain:

git add . git commit -m "changes in utils" git log --oneline 

Is tarah humne do alag commits banaye.

7.6 Staging area kyun banaya gaya?

Basically: aap control kar sako ki kaunsa change kis commit mein jaye. Aap ek hi baar mein 10 files badal sakte ho, par unko 3 alag, saaf-suthre commits mein baant sakte ho. Yeh clean commit history ka base hai.

7.7 Shortcut: git commit -a

git commit -am "message" 

-a already tracked files ko add + commit ek saath kar deta hai. Dhyan rahe: yeh naye (untracked) files ko add nahi karta.

Chapter 7 Recap

• Modified → Staged → Committed: yeh Git ka core flow hai.
• git add = file ko staging mein bhejta hai.
• git commit = sirf staging area ki cheezein commit karta hai.
• git status hamesha pehle chalake dekho ki state kya hai.

Mini Task

1. Do alag files mein changes karo.
2. Sirf ek file ko git add karo, git status dekho.
3. Commit karo, git show se verify karo ki sirf ek hi file gayi.
4. Phir doosri file ko commit karo.

Chapter 8: Wapas Jaana (HEAD, git reset, git revert)

Is chapter ke baad aap jaanoge: HEAD kya hota hai, kharab commit ko hatane ke 2 tareeke (reset aur revert), aur dono mein asli fark.

8.1 Revert back kyun zaroori hai?

Version control ka ek bada fayda: agar kuch galat ho jaye toh hum kabhi bhi history mein wapas ja sakte hain. Maan lo aapka build pehle sahi chal raha tha, phir ek change ke baad code toot gaya. Technically aapke paas koi mechanism hona chahiye jisse aap wapas ja sako. Isi ko kehte hain reverting back.

Reverting ke liye hamare commits hi kaam aate hain. Agar commits achhe (clean) hain, toh revert karne mein koi problem nahi hogi.

8.2 HEAD kya hota hai? (Linked List jaisa)

College mein Linked List padha hoga: ek node ke baad doosra node, har node ke paas next ka address, aur sabse latest node ko hum head kehte the.

Git ke commits bhi bilkul ek linked list ki tarah hote hain:

[Commit 1] <-- [Commit 2] <-- [Commit 3] <-- [Commit 4] (base) ^ HEAD 

HEAD hamesha latest commit ko point karta hai. Jab bhi aap koi naya commit banate ho, ek naya node judta hai aur HEAD aage khisak kar us naye commit ko point karne lagta hai. git log --oneline mein sabse upar (HEAD -> main) likha hota hai, wahi aapka HEAD hai.

8.3 Setup: ek kharab commit banate hain

Maan lo hamari history aisi hai:

a1b2c3d Changes in utils (sahi) 9e8f7a6 abc commit (sahi) 

Ab hum jaan-boojhkar bug daalte hain: utils.js mein num1 aur num2 ki jagah b ka naam badal dete hain, aisa ki code toot jaye. Phir:

git add . git commit -m "code changes" git log --oneline 

5c4d3e2 code changes <- HEAD (kharab) a1b2c3d Changes in utils 9e8f7a6 abc commit 

HEAD ab is kharab commit par hai. Humein is commit ki zaroorat hi nahi.

8.4 Tareeka 1: git reset (HEAD ko peeche le jaana)

Idea: agar hum HEAD ko ek commit peeche le jayen, toh woh kharab commit history se hat jayega.

git log --oneline git reset --hard <good-commit-id> 

Example:

git reset --hard a1b2c3d 

HEAD is now at a1b2c3d Changes in utils 

Ab git log --oneline karo toh kharab commit gayab hai. Code bhi wapas sahi ho gaya (num1/num2 wapas aa gaye). Humne HEAD hi reset kar diya.

Dhyan rakho: --hard aapke local (uncommitted) changes bhi uda deta hai. Isko soch samajh ke use karo.

Reset ka khatra: agar aap galti se bahut peeche ka commit chun lo, toh beech ke saare commits history se hat jayenge, kyunki hum HEAD ko hi peeche le gaye. Yeh linear flow hai.

8.5 Tareeka 2: git revert (sirf ek commit ko undo karna)

Ab maan lo aapko history ke beech ke ek particular commit ko hatana hai, lekin uske baad ke commits (features) rakhne hain. Reset karoge toh sab kuch hat jayega. Yahan kaam aata hai git revert.

Step 1: us commit ki ID lo:

git log --oneline 

Step 2: revert chalao:

git revert <commit-id> 

Example: us commit mein humne ek function remove kiya tha. git revert kya karta hai? Us commit ka ulta (inverse) kaam karta hai: jo cheezein add hui thi unko remove kar deta hai, aur jo remove hui thi unko wapas add kar deta hai.

Kabhi-kabhi yahan merge conflict aa sakta hai (Chapter 12 mein detail mein). Conflict resolve karke:

git add . git commit -m "revert: undo function removal" git log --oneline 

Ab history mein ek naya commit dikhega jo purane commit ko undo kar raha hai. Purani history mitai nahi gayi.

8.6 Reset vs Revert: asli fark

Aasaan yaad rakhne ka tareeka:

• Reset = time machine, jahan purane kal ke baad ka sab kuch mit jaata hai.
• Revert = ek naya "undo" commit jo history ko saaf-suthra rakhta hai.

Companies mein 99% time git add, git commit, git push, git checkout, git branch, git merge hi use hote hain. Reset aur revert kam use hote hain, lekin pata hona zaroori hai.

Chapter 8 Recap

• Commits ek linked list hain. HEAD = latest commit ka pointer.
• git reset --hard <id> = HEAD ko peeche le jaata hai.
• git revert <id> = us commit ka ulta commit banata hai.
• Shared code par revert zyada safe hai.

Mini Task

Ek jaanbujh kar kharab commit banao, pehle reset se hatao. Phir dobara banao aur revert se hatao. Dono ke baad git log --oneline compare karo.

PART 2: COLLABORATION

Chapter 9: Collaboration, Central Server Aur Git vs GitHub

Is chapter ke baad aap jaanoge: team mein kaam karte waqt kya problem aati hai, "single source of truth" kya hota hai, aur Git aur GitHub ka asli fark.

9.1 Ab tak kya seekha?

Ab tak humne dekha ki apni akeli local machine par Git se version control kaise karte hain: Git install kiya, commits banaye, history dekhi, aur revert kiya. Lekin real duniya mein hum akele kaam nahi karte. Bade projects mein hum team ke saath kaam karte hain.

9.2 Problem: do developers, do alag copies

Maan lo mere ek friend (Riya) ko bhi mere saath is project par kaam karna hai.

Bina server ka tareeka: main apna project zip karke pen drive ya email se de deta hoon. Ab dono ke paas same code hai aur dono ke paas Git bhi hai.

Problem kahan hai?

• Meri machine par const age = 24; hai.
• Riya ne apni machine par const age = 28; kar diya.

Dono ka code independently chal raha hai. Ab main dono changes ko consistent kaise rakhun? Kaise sync karun? Koi tareeka nahi.

9.3 Solution: Single Source of Truth

Humein chahiye ek single source of truth: ek aisi jagah jo sabhi developers ke code ko consistent rakhe.

Yeh ek remote server ho sakta hai. Yeh AWS par ho sakta hai, Azure par, DigitalOcean par, ya kahin bhi. Basically ek server jo kisi ek jagah chal raha hai. Local machine bhi ek machine hai, aur remote server bhi ek machine hi hai. Is remote server par bhi Git install kar sakte hain. Is server ka ek public IP ya domain hota hai, jaise central-git-server.example.com.

 Prabhat's laptop Riya's laptop (local repo) (local repo) | ^ | ^ push | | pull push | | pull v | v | +--------------------------------------------------+ | CENTRAL SERVER (GitHub / GitLab) | | single source of truth | +--------------------------------------------------+ 

9.3.1 Push aur Pull ka flow

• Jo bhi changes hum apni local machine par karte hain, unko hum is server par push karte hain (apne commits ko bhejte hain).
• Baaki sab developers isi server se changes pull karte hain (commits ko apni machine par laate hain).

Ek example timeline:

1. 12 PM: Prabhat ne age = 24 ka ek commit banaya aur server par push kiya.
2. Riya ne pull kiya toh uske paas bhi age = 24 aa gaya. Dono ka code consistent.
3. 2 PM: Riya ne age = 28 kiya, commit banaya aur server par push kiya.
4. Ab server par 2 commits hain: ek 12 PM wala (age = 24), ek 2 PM wala (age = 28