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 "[email protected]"

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 <[email protected]>
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).
5. Prabhat dekhta hai ki server par 2 commits hain par uske paas ek hi hai. Woh pull karta hai. Ab dono ke paas latest code (age = 28) hai.

Is tarah commit history maintained rehti hai, pata chalta hai kab kisne kya badla, aur sabke paas same code rehta hai. Isi ko kehte hain Git Collaboration.

Ek hi requirement hai: ek central server hona chahiye jahan sab push/pull karein.

9.4 Central server kahan se laayein?

Sach mein hume khud ka server setup karne ki zaroorat nahi, kyunki bahut saare publicly available Git servers hain:

Hum khud ka Git server bhi bana sakte hain, woh mushkil task nahi hai.

9.5 Git vs GitHub: ab clear ho jayega

• Asli version controlling kaun kar raha hai? Git.
• Public server jahan hum changes push/pull karte hain, usko kya kehte hain? GitHub (ya GitLab, Bitbucket).

GitHub internally ek Git server hi hai. Lekin GitHub ne Git ke upar bahut saare extra features bana diye hain: ek achhi UI, task management, issues, pull requests, stars/watch, social-media jaisa profile aur contribution graph, aur code review.

Yaad rakho: Git = engine. GitHub = engine ke upar bana hua poora car showroom (UI, features).

Chapter 9 Recap

• Team mein kaam karne ke liye ek central (remote) server chahiye.
• Developers apne commits push karte hain aur doosron ke commits pull karte hain.
• Git = VCS. GitHub/GitLab/Bitbucket = Git servers.
• Issues, pull requests, UI wagairah GitHub ke features hain, Git ke nahi.

Quick Check

1. Single source of truth kya hota hai?
2. Push aur pull mein kya fark hai?
3. Pull request Git ka feature hai ya GitHub ka?

Chapter 10: GitHub, Remote, Push Aur SSH Authentication

Is chapter ke baad aap jaanoge: GitHub par repository kaise banate hain, local Git ko remote se kaise jodte hain, git push kaise karte hain, aur SSH key se authentication kaise hoti hai.

10.1 GitHub account aur repository

1. Browser mein github.com kholo aur account banao (free aur bahut aasaan).
2. Apni profile par jaao. Wahan aapko followers, following, README, contribution graph (ek heat map jisme dikhta hai kis din kitna kaam kiya) aur Repositories tab milega.
3. Repositories → New par click karo.
4. Repository name do, jaise git-masterclass.
5. Public (sabko dikhega) ya Private (sirf aapko ya jisko access do) chuno. Abhi ke liye Private theek hai.
6. Baaki kuch mat chhedo aur Create repository dabao.

Repo ban gaya. Uska ek URL hoga, jaise:

[email protected]:prabhat-demo/git-masterclass.git

Isko copy kar lo. Yeh us server par us repository ka address hai.

Yaad rakho: git init local machine par repository banata hai. GitHub par hum UI se repository banate hain.

10.2 Local Git ko batana ki remote kaunsa hai: git remote

Abhi tak meri local machine ko pata hi nahi ki koi server hai. Pehle check karo:

git remote -v

Kuch bhi print nahi hua, matlab abhi koi remote setup nahi hai.

Remote add karo:

git remote add origin <repo-url>

Example:

git remote add origin [email protected]:prabhat-demo/git-masterclass.git

origin = remote ka user-friendly naam. Convention (sab log yahi rakhte hain) yahi hai ki default remote ka naam origin hota hai. Aap kuch bhi naam de sakte ho, jaise friends-server, par origin best practice hai.

Ab dobara check karo:

git remote -v

origin  [email protected]:prabhat-demo/git-masterclass.git (fetch)
origin  [email protected]:prabhat-demo/git-masterclass.git (push)

Local Git ko ab pata hai ki ek server origin hai jiska yeh address hai. Pull, fetch, push sab usi se hoga. Multiple remotes bhi ho sakte hain (jaise open-source contribution mein).

10.3 Push karna

git push

Pehli baar git push chalane par upstream error aayega. Fikr nahi, pehli baar yeh command chalao:

git push -u origin main

• git push = commits server par bhejo.
• -u = upstream set karo (local branch ko remote branch se jodo).
• origin = kaunse server par.
• main = kaun si branch mein.

Output mein dikhega: objects counting, compressing, writing, total... Kaam ho gaya.

Enumerating objects: 9, done.
Counting objects: 100% (9/9), done.
Writing objects: 100% (9/9), 812 bytes | 812.00 KiB/s, done.
To github.com:prabhat-demo/git-masterclass.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.

Ab GitHub par jaake page refresh karo. Aapki files (index.js, script.js, utils/) aur commit messages wahan dikh jayenge. Commits par click karke sabhi commits aur unki IDs dekh sakte ho.

Bonus: GitHub UI aapko yeh sab deta hai: language percentage (jaise 100% JavaScript), description, activity, stars, watchers, Issues tracker, Pull Requests. Yeh sab GitHub ke features hain, Git ke nahi.

10.4 Push ke baad naye changes ka flow

Ab jab bhi aap commit karo:

git add .
git commit -m "your message"
git push

Pehli baar ke baad bas git push kaafi hai.

Example: index.js mein console.log("Hello " + name) ko template literal mein badlo:

console.log(`Hello ${name}`);

Phir: git status, git diff, git add ., git commit -m "replace concat with template literal", git push. GitHub par naya commit ek achhi UI mein dikhega, jisme purani aur nayi line ka comparison hoga. GitHub par aap commits par comment bhi kar sakte ho.

10.5 Local reset ke baad force push (advanced)

Agar aapne local par git reset --hard <old-id> kiya hai aur remote ka HEAD aage hai, toh normal git push fail hoga. Tab:

git push --force-with-lease

Yeh remote ke HEAD ko bhi reset kar deta hai. (Purani style git push -f bhi yahi karta hai, par --force-with-lease zyada safe hai kyunki agar kisi aur ne beech mein push kiya ho toh yeh ruk jaata hai.)

Warning: Shared repo par force push bahut soch samajh ke use karo, kyunki yeh doosron ke commits mita sakta hai.

10.6 Authentication: kya koi bhi mere server par push kar sakta hai?

Nahi. Sirf URL hona kaafi nahi, authentication chahiye. Agar kisi aur ke repo par push karoge toh error aayega: aapke paas access nahi hai.

To main apni machine se kyun push kar paaya? Kyunki maine SSH key setup kar rakhi hai. SSH = Secure Shell (secure tareeke se remote machine se baat karne ka protocol).

10.7 SSH key kaise kaam karti hai?

Hum apni local machine par ek SSH key pair banate hain: ek private key aur ek public key.

• Public key ko hum GitHub account mein daal dete hain.
• Jab bhi hum push karte hain, private key se authenticate hota hai, aur GitHub public key se match karke dekhta hai: haan, yeh user authenticated hai.

  Aapka laptop                          GitHub
  [private key]  -- challenge/response --> [public key]
   (kabhi share                           (account mein add
    nahi karni)                            ki hui)

Sabse zaroori: private key kabhi kisi ko mat do, kabhi copy-paste mat karo, kabhi GitHub par upload mat karo. Sirf public key share hoti hai.

10.8 SSH key banane ke steps

Step 1: Key generate karo

ssh-keygen -t ed25519 -C "[email protected]"

(-t ed25519 algorithm hai, -C mein aapki email.) Yeh kuch sawal poochega:

• Kahan save karein? Default ~/.ssh/id_ed25519 hai, Enter dabao.
• Passphrase? Optional hai. Aap rakh bhi sakte ho, na bhi.

Step 2: Keys dekho

cd ~/.ssh
ls

Do files dikhengi:

• id_ed25519 = private key (kabhi share nahi karni).
• id_ed25519.pub = public key (yeh share karni hai).

Step 3: Public key copy karo

cat id_ed25519.pub

Jo bhi output aaye (poori line), usko copy kar lo. Private key copy nahi karni.

Step 4: GitHub par add karo

1. GitHub → Profile photo → Settings.
2. Left side mein SSH and GPG keys.
3. New SSH key par click.
4. Title do (jaise "My Laptop") aur Key mein copy kiya hua public key paste karo.
5. Add SSH key dabao.

Ab aapki machine GitHub par authenticated hai. Aap multiple SSH keys (alag laptops ke liye) bhi add kar sakte ho.

Step 5 (optional): Connection test karo

ssh -T [email protected]

Hi prabhat-demo! You've successfully authenticated, but GitHub does not provide shell access.

Apne khud ke Git server par: wahan bhi SSH key manually server ke authorized_keys mein paste karni padti hai. GitHub ne ise UI se aasaan bana diya hai.

10.9 Collaborators ko invite karna

Repo → Settings → Collaborators mein jaake apne friends ko invite kar sakte ho. Unko bhi access mil jayega. Yeh GitHub ka feature hai, Git ka nahi.

10.10 Doosre developer ka flow

Aapka friend repo ko clone karta hai:

git clone <repo-url>

Phir woh bhi apne commits push karta hai aur aap unko pull karte ho:

git pull

Is tarah dono ke commits ek central remote server par aate-jaate hain.

Chapter 10 Recap

Mini Task

1. GitHub par ek private repo banao.
2. SSH key generate karke GitHub mein add karo.
3. Apne local repo ko origin se jodo aur git push -u origin main karo.
4. GitHub par commits dekho.

PART 3: ADVANCED WORKFLOW

Chapter 11: Branching (Alag Alag Railway Tracks)

Is chapter ke baad aap jaanoge: branch kya hoti hai, kyun zaroori hai, branch kaise banate aur switch karte hain, branch ko GitHub par push karna, Pull Request, aur branch naming convention.

11.1 Branch kya hoti hai?

Abhi tak hum ek hi branch par kaam kar rahe the, jiska naam hai main. (Purane projects mein isko master kehte the, ab default main hai. Purane code mein aapko master mil sakta hai.)

Branch ko aise samjho: ek single railway track, jiske upar commits ki stations hain. Abhi hamare paas ek hi track hai, main, aur uske upar kuch commits hain.

11.2 Ek hi track par sabka kaam: problem

Maan lo mere saath Riya bhi isi project par kaam kar rahi hai. Agar dono same track (main) par apne commits dalenge toh:

• Commits polluted (ganda) ho jayenge, ek dusre mein mix.
• Maan lo mujhe sirf Riya ke changes revert karne hain (kyunki uska code kharab tha). Lekin git reset ya revert use karne par mere changes bhi hat sakte hain. Reality mein 10–20 commits ho sakte hain, ek-ek ko revert karna possible nahi.

Isliye jab bhi collaboration mein har developer apna alag feature banaye, toh sabko same track par kaam nahi karna chahiye.

11.3 Solution: Branching

Kaam ka flow:

1. Main (Prabhat) main par kaam karta rehta hoon. HEAD latest commit par hai.
2. Riya ko main ek task deta hoon: Feature A banao.
3. Convention: Riya ek nayi branch banati hai, main ke latest commit se. Yeh ek alag railway track hai (jaise feat/feature-a).
4. Riya apne saare commits apni branch mein dalti hai. Yeh kisi se independent hai. Maan lo usne 4 commits kiye.
5. Meanwhile main apni main branch mein aur commits karta rehta hoon.
6. Riya bolti hai: mera kaam ho gaya. Ab usko apni branch ko main mein merge karna hai.
7. Merge hote hi Riya ke saare changes main mein aa jaate hain.
8. Ab purani branch delete kar sakte hain.

Fayda: agar mujhe Riya ke changes revert karne hain, toh ek hi merge commit ko revert karna hai. Yeh bahut clean hai.

main      o---o---o-----------o---o   (merge point)
                   \         /
feat/a              o---o---o        (Riya ke 3 commits)

Branch ke andar ke commits sirf us branch mein rehte hain, jab tak merge point par woh main mein nahi aate.

11.4 Branch dekhna

git branch

* main

Star (*) us branch par hai jisme hum abhi hain.

11.5 Nayi branch banana

Branch banane ke do tareeke hain.

Tareeka 1: do alag commands

git branch prabhat-feature
git checkout prabhat-feature

• git branch <name> = nayi branch banata hai.
• git checkout <name> = us branch par switch karta hai.

Tareeka 2: ek hi command mein (best)

git checkout -b prabhat-feature

-b ka matlab hai: branch banao aur uspar switch bhi karo. Dono ek saath.

Modern tip: Naye Git versions mein git switch -c prabhat-feature bhi chalta hai (aur existing branch par jaane ke liye git switch <name>). Kaam wahi hai, command ka naam zyada saaf hai.

Ab git branch chalao:

  main
* prabhat-feature

Star naye branch par hai. git log --oneline mein saare purane commits dikhenge, lekin ab hum prabhat-feature branch par hain.

11.6 Branch mein kaam karna

Branch ke andar ek function add karo:

function newFeature() {
  console.log("This is a new feature");
}

Phir:

git add .
git commit -m "new feature added"

Ek aur line add karke dobara commit:

git add .
git commit -m "new feature added again"
git log --oneline

Ab is branch mein 2 naye commits hain. Yeh main mein nahi hain, sirf prabhat-feature mein hain. Git Graph extension kholo toh dikhega: main se ek naya branch nikla, jisme 2 extra commits hain.

11.7 Branch ko GitHub par push karna

Yeh branch abhi sirf local par hai. Push karoge:

git push

Error aayega: is branch ka remote par koi upstream nahi hai. Sahi command:

git push --set-upstream origin prabhat-feature

Yeh pehle remote par naya branch banata hai aur phir code push karta hai. Ab GitHub par prabhat-feature branch dikhegi.

GitHub par is branch ko main ke saath compare kar sakte ho: banner dikhega "This branch is 2 commits ahead of main". Compare mein dikhega kaun-si new lines aayi (plus/minus).

11.8 Pull Request (PR)

Ab is branch ko main mein merge karwana hai. GitHub par Pull Request banate hain:

1. Branch → Compare & pull request (ya Pull requests → New pull request).
2. Base: main, Compare: prabhat-feature.
3. Title do (jaise "Feature B added"), Create pull request.

Pull request ka matlab: "Meri yeh branch main mein pull kar lo." Repo ka maintainer Files changed mein dekhega kya badla hai aur Conversation mein comment kar sakta hai. Sab theek lage toh Merge pull request → Confirm merge karta hai.

PR close ho jaata hai. Yeh merge server (GitHub) par hua. Local main ko abhi nahi pata. Local ko sync karne ke liye:

git checkout main
git pull

git pull server ke sabhi extra commits laata hai. Ab history mein dikhega: "Merge pull request #1 from prabhat-demo/prabhat-feature".

11.9 Branch ke naam kaise rakhein? (Naming Convention)

Company mein branch ka naam kaam batata hai. Pehle category (prefix), phir /, phir kaam ka naam.

Isse sabko pata chal jaata hai ki aap kis cheez par kaam kar rahe ho.

git checkout -b feat/add-chat-support
git checkout -b bug/login-not-working

11.10 Branch ke saath yeh bhi seekh lo

Chapter 11 Recap

• Branch = alag railway track, independent kaam ke liye.
• Har feature/bug ke liye alag branch banao.
• Kaam hone par PR banao aur main mein merge karo.
• Naming: feat/..., bug/..., wip/..., junk/....

Mini Task

1. git checkout -b feat/my-first-feature banao.
2. Do commits karo.
3. git push --set-upstream origin feat/my-first-feature karo.
4. GitHub par PR banao aur merge karo.
5. Local mein main par aake git pull karo.

Chapter 12: Merge vs Rebase

Is chapter ke baad aap jaanoge: ek branch ko main mein laane ke do tareeke (merge aur rebase), dono ka fark, merge conflict kaise solve karte hain, aur kab kya use karna chahiye.

12.1 Merge karna (Tareeka 1)

Maan lo main par kuch commits hain aur humne feature/feature-a branch nikali jisme 4 commits hain. Is branch ko main mein laana hai.

Merge ka seedha tareeka:

git checkout main
git merge feature/feature-a

Ispar Git feature-a ke changes main mein mila deta hai aur ek merge commit banata hai (jaise "Merge branch 'feature/feature-a'"). Yeh GitHub ke PR merge mein bhi dikhta hai ("Merge pull request from ...").

Technical note (important): Normal git merge mein branch ke saare commits history mein bane rehte hain aur upar se ek merge commit judta hai. Agar saare commits ko ek single commit mein compress karna ho, usko squash merge kehte hain (GitHub PR mein "Squash and merge" option). Dono mein faida yeh hai ki aap merge point par poori branch ko ek baar mein revert kar sakte ho.

Merge ka faida: poori branch ko ek hi jagah revert kar sakte ho. Ek merge commit ko revert karna aasaan hai.

Merge ka nuksaan:

• History branchy ho jaati hai (alag tracks mil rahe hote hain).
• Squash merge mein branch ki individual history kho jaati hai. Maan lo aapko sirf branch ke ek particular commit ko revert karna hai, par ab sab ek hi commit mein mil chuka hai, toh sirf poora ka poora revert ho sakta hai.

Company mein zyadatar merge hi use hota hai. Agar kuch problem aati hai toh poori branch ko hi revert kar dete hain.

12.2 Merge GitHub UI se bhi (PR)

Branching chapter mein humne feature-b ko PR se merge kiya tha. Yeh bhi merge hai:

git checkout -b feature/feature-b
# ... changes karo ...
git add .
git commit -m "feature b added"
git push --set-upstream origin feature/feature-b

GitHub par PR banao (Base: main, Compare: feature/feature-b) aur Merge dabao. Phir local par:

git checkout main
git pull

History mein dikhega: "Merge pull request #2 from prabhat-demo/feature-b".

12.3 Rebase karna (Tareeka 2)

Rebase mein hum branch ke commits ko ek ek karke main ke latest commit ke aage dobara laga dete hain. Commits ko merge karne ke bajaye hum unko main ke saath link kar dete hain, jisse ek linear (seedhi) flow ban jaata hai.

Pehle:
main      A---B---C
               \
feature         D---E

Rebase ke baad (feature par `git rebase main`):
main      A---B---C
                   \
feature             D'---E'      (D' aur E' naye commits hain)

Fayda: history seedhi aur saaf-suthri dikhti hai, aur har commit alag rehta hai. Aap branch ke sirf ek particular commit ko bhi hata sakte ho.

Nuksaan:

• Rebase commits ko dobara likhta hai (naye IDs milte hain). Isliye jo branch push ho chuki hai aur jispar doosre kaam kar rahe hain, usko rebase karna risky hai.
• Agar sab log har jagah rebase karenge toh confusion aur galtiyan badh jaati hain.

Isliye rebase tab use hota hai jab sach mein zaroorat ho, aur zyadatar apni local branch par.

12.4 Rebase ka example (step by step)

Step 1: Branch banao aur 3 commits karo

git checkout -b feature/feature-c

Phir 3 baar yeh karo:

# file mein ek function/line add karo
git add .
git commit -m "commit 1"

# dobara change
git add .
git commit -m "commit 2"

# teesri baar
git add .
git commit -m "commit 3"

Shortcut: git add aur commit ek saath: git commit -am "commit 1".

Git Graph mein feature-c mein 3 commits dikhenge.

Step 2: Branch ko latest main ke upar rebase karo

Agar main mein beech mein naye commits aa gaye hain, toh feature branch par jaake:

git checkout feature/feature-c
git rebase main

Ab feature-c ke 3 commits main ke latest commit ke aage dobara lag gaye.

Step 3: Ab main mein laao (fast-forward)

git checkout main
git merge feature/feature-c

Chunki branch main ke seedhe aage hai, Git bina merge commit banaye bas main ko aage khisaka deta hai. Isko fast-forward kehte hain.

git log --oneline

9a8b7c6 commit 3
6d5e4f3 commit 2
3c2b1a0 commit 1
7d2f9b1 initial code added

Teeno commits main mein alag-alag dikh rahe hain. History mil gayi, merge ki tarah ek alag merge commit nahi bana.

Step 4: Push karo

git push

GitHub refresh karne par teeno commits main mein aise ke aise dikhenge.

Golden rule: jo branch aap local par rebase kar rahe ho woh agar pehle se remote par push ho chuki hai, toh push ke waqt --force-with-lease lagega aur teammates ko bata dena. Shared branches (jaise main) ko kabhi rebase mat karo.

12.5 Merge vs Rebase: seedha comparison

MERGE:                         REBASE:
main  o---o---o-----M          main  o---o---o---D'---E'
           \       /
feat        D---E

Golden rule: by default merge karo. Rebase sirf tab karo jab aapko sach mein zaroorat ho.

12.6 Merge conflict kya hota hai?

Jab do branches ne same file ki same line badli ho, toh Git ko samajh nahi aata ki kaun-si sahi hai. Tab Git bolta hai: "conflict hai, aap khud decide karo."

git merge feat/conflict

Auto-merging app.js
CONFLICT (content): Merge conflict in app.js
Automatic merge failed; fix conflicts and then commit the result.

File khologe toh conflict markers dikhenge:

<<<<<<< HEAD
const city = "Mumbai";
=======
const city = "Pune";
>>>>>>> feat/conflict

• <<<<<<< HEAD ke neeche: aapki current branch ka code.
• ======= ke neeche: incoming branch ka code.
• >>>>>>> : incoming branch ka naam.

Aapko ek final version rakhna hai aur saare markers hata dene hain. Phir:

git add .
git commit -m "resolve merge conflict"

VS Code conflict resolve karne ke liye buttons deta hai: Accept Current Change / Accept Incoming Change / Accept Both Changes.

Chapter 12 Recap

• Merge = branch ko main mein milana. Company mein zyada use hota hai.
• Rebase = commits ko main ke aage seedhi line mein lagana, history linear rehti hai.
• Beginners ko merge hi use karna chahiye.
• Conflict = same line ke do versions; aap decide karte ho.

Mini Task

1. Ek branch feature/x se 3 commits karo aur git merge se main mein laao.
2. Ek aur branch feature/y se 3 commits karo aur rebase karke (git rebase main) phir main mein merge karo.
3. Dono ke baad git log --oneline --graph compare karo.

Chapter 13: Git Stash (Adhoora Kaam Chhupana)

Is chapter ke baad aap jaanoge: stash kya hota hai, kab kaam aata hai, aur git stash, git stash pop, git stash apply, git stash list kaise use karte hain.

13.1 Problem: pull nahi ho raha

Maan lo aapke local code mein kuch adhoore (WIP) changes hain. git diff karne par dikhta hai ki aapne index.js mein kuch badla hai.

Udhar remote (GitHub) par kisi doosre developer ne main mein kuch code badal diya aur commit kar diya. Aap GitHub par dekhte ho: "Update index.js" ka naya commit hai. Aapko wo code chahiye. Aap git pull karte ho. Git bolta hai:

error: Your local changes to the following files would be overwritten by merge:
        index.js
Please commit your changes or stash them before you merge.

Ab aapke dost ka phone aata hai: "Maine bahut important code change kiya hai, pull karo!" Lekin aap pull nahi kar paa rahe, kyunki aapke changes abhi complete nahi hue, aur aap unko git add . + git commit bhi nahi karna chahte.

Dikkat kya hai? Local machine par kuch changes hain jo complete nahi hue, aur remote par kisi ne nayi cheez daal di hai jo aapko chahiye.

13.2 Solution: git stash

git stash

Yeh aapke saare local (uncommitted) changes ko ek temporary jagah mein rakh deta hai. Aapka code ab pichle commit wali clean state par aa jaata hai (aapke changes chale gaye, lekin kho nahi gaye).

Ab safely pull karo:

git pull

Remote ke naye commits aa jayenge. Ab apne chhupaye hue changes wapas lao:

git stash apply

Aapke changes wapas aa gaye, aur ab woh phir se unstaged / uncommitted state mein hain. Aap unpar kaam jaari rakh sakte ho.

13.3 Stash ke commands

13.4 Stack ki tarah kaam karta hai

Agar aap teen baar git stash karte ho, toh ek stack ban jaata hai (LIFO: Last In, First Out).

stash@{0}  <- sabse naya (top)
stash@{1}
stash@{2}  <- sabse purana

Har git stash pop / git stash apply par hamesha top wala stash apply hota hai.

git stash list

stash@{0}: WIP on main: 7d2f9b1 initial code added
stash@{1}: WIP on main: 7d2f9b1 initial code added

13.5 Kab use karte hain?

• Aap kisi branch par kaam kar rahe ho aur beech mein doosri branch par jaana hai (checkout), par abhi aapke changes commit-layak nahi hain.
• Aapko git pull karna hai par local mein WIP changes hain.

Dhyan rahe: git stash by default tracked modified files ko stash karta hai. Naye (untracked) files ke liye git stash -u use karna padta hai.

13.6 Stash ka full flow

# 1. WIP changes hain
git status

# 2. Unko stash karo
git stash

# 3. Ab pull / branch change safely karo
git pull
# ya
git checkout other-branch

# 4. Wapas aao aur apne changes lao
git stash pop

Agar stash pop ke waqt conflict aaye (kyunki remote ne wahi line badli thi), toh Chapter 12 ki tarah conflict resolve karo.

Chapter 13 Recap

• git stash = adhoore changes ko temporarily chhupa deta hai.
• git stash pop / git stash apply = changes wapas laata hai.
• Stash ek stack hai: top wala pehle apply hota hai.
• Branch badalne ya pull karne se pehle bahut kaam aata hai.

Mini Task

1. Kisi file mein WIP change karo (commit mat karna).
2. git stash karo aur check karo git status clean hai.
3. git stash list dekho.
4. git stash pop karke changes wapas lao.

PART 4: PRACTICE & REFERENCE

Chapter 14: Git Cheat Sheet (Saari Commands Ek Jagah)

Yeh poori guide ki commands ka ek-page summary hai. Isko print karke ya bookmark karke rakh lo.

14.1 Setup aur shuruaat

14.2 Roz ka kaam (Daily workflow)

14.3 History dekhna

14.4 Undo karna

14.5 Remote

14.6 Branching

14.7 Stash

14.8 Git ke teen zone (yaad rakhne ka formula)

Working Directory --(git add)--> Staging Area --(git commit)--> Local Repository --(git push)--> Remote (GitHub)

14.9 Branch naming cheat

14.10 99% time yeh hi commands kaam aati hain

git add · git commit · git push · git pull · git branch · git checkout · git merge

Chapter 15: Practice Exercises (Haath Se Karo, Tabhi Seekhoge)

Rule: pehle khud try karo, phir Chapter 16 mein answers dekho. Har exercise ek sandbox folder mein karo, aur pehle git status / git log --oneline se pata rakho ki aap kahan ho.

Level 1: Basics (Chapters 1 se 3)

Exercise 1.1: Setup check

1. git --version chalao. Version likh lo.
2. Git mein apna naam aur email set karo.
3. git config --list se verify karo.

Exercise 1.2: Short answers

1. VCS kya hota hai? Ek line mein likho.
2. Git aur GitHub mein 2 fark likho.
3. Agar Git version 3.x ho toh kya dikkat ho sakti hai?

Level 2: Pehla repo (Chapters 4 aur 5)

Exercise 2.1: Repo banao

mkdir practice-repo
cd practice-repo
git init

1. ls -a se .git folder dekho.
2. Ek file app.js banao jisme yeh likho:

const city = "Delhi";
console.log(city);

1. VS Code mein U dikha ya nahi? Phir git add app.js karo aur dobara dekho.

Exercise 2.2: Diff padhna

app.js mein city ki value "Mumbai" kar do aur git diff chalao. Output mein kaun-si line - se aur kaun-si + se shuru hui?

Exercise 2.3: Folder ke saath

mkdir helpers

helpers/math.js banao:

function multiply(a, b) {
  return a * b;
}

Phir ek hi command mein saari files add karo aur git status dekho.

Level 3: Commits (Chapter 6)

Exercise 3.1: 3 clean commits

1. Pehla commit: app.js aur helpers/math.js ke saath, message "initial code added".
2. app.js mein yeh function add karo, phir commit karo (message: "added greet function"):

function greet(name) {
  return `Hello ${name}`;
}

1. Ek aur function isEven add karo, commit karo:

function isEven(n) {
  return n % 2 === 0;
}

1. git log --oneline se teeno commits dekho.

Exercise 3.2: Detective kaam

1. git show <id> se dekho ki doosre commit mein exactly kya add hua.
2. git blame app.js chalao. Kaun-si line kis commit se aayi?

Level 4: Staging area (Chapter 7)

Exercise 4.1: Alag alag commits

1. app.js mein ek comment add karo, aur helpers/math.js mein ek naya function subtract add karo.
2. Sirf app.js ko git add karo. git status mein dekho kya staged hai, kya nahi.
3. Commit karo: "comment added".
4. Ab git show se verify karo ki sirf app.js gayi.
5. Phir math.js ka alag commit karo.

Sawaal: agar staged nahi kiya aur seedha git commit -m "x" kiya toh kya hoga?

Level 5: Undo (Chapter 8)

Exercise 5.1: Reset

1. helpers/math.js mein jaan-boojhkar galat code likho (jaise return a + undefinedVar;) aur commit karo.
2. git log --oneline se us commit ki pehle wali (sahi) commit ID dhundho.
3. git reset --hard <good-id> karo.
4. git log --oneline aur file dono check karo. Kya galat commit gaya?

Exercise 5.2: Revert

1. Ek naya function divide add karke commit karo. Phir ek aur commit karo (koi bhi chhota change).
2. Pehle wale (divide wale) commit ko git revert <id> se undo karo.
3. git log --oneline mein kya naya commit dikha? divide function ka kya hua? Aakhri commit (chhota change) bacha ya nahi?

Challenge: reset aur revert mein kaun-sa shared branch par safe hai aur kyun?

Level 6: GitHub (Chapters 9 aur 10)

Exercise 6.1: Pehla push

1. GitHub par practice-repo naam ka private repo banao.
2. SSH key banao: ssh-keygen -t ed25519 -C "[email protected]".
3. ~/.ssh/id_ed25519.pub ka content GitHub ki SSH keys mein add karo.
4. Repo jodo aur push karo:

git remote add origin [email protected]:<username>/practice-repo.git
git remote -v
git push -u origin main

1. GitHub par page refresh karke commits dekho.

Exercise 6.2: Clone aur pull

1. Kisi doosre folder mein repo ko git clone <url> se clone karo (maan lo woh aapka dost hai).
2. Wahan ek change karke commit + push karo.
3. Original folder mein git pull karo. Change aaya?

Level 7: Branching (Chapter 11)

Exercise 7.1: Feature branch

git checkout -b feat/add-greeting

1. Branch mein 2 commits karo (app.js mein ek-ek function).
2. git branch aur git log --oneline check karo.
3. git push --set-upstream origin feat/add-greeting karo.
4. GitHub par Pull Request banao, Merge karo.
5. Local mein git checkout main aur git pull karo. Merge commit dikha?

Exercise 7.2: Naming

Neeche ke kaamo ke liye sahi branch names likho:

1. Login button kaam nahi kar raha.
2. Payment integration add karni hai.
3. Ek aise experiment par kaam ho raha hai jo kabhi bhi merge nahi hoga.
4. Ek bada dashboard hai jo kai hafte mein banega.

Level 8: Merge vs Rebase (Chapter 12)

Exercise 8.1: Merge

1. feat/one branch banao, 3 commits karo.
2. git checkout main aur git merge feat/one karo.
3. git log --oneline --graph dekho.

Exercise 8.2: Rebase

1. feat/two branch banao, 3 commits karo.
2. (Optional) pehle main par ek naya commit karo, taaki rebase ka asar dikhe.
3. git checkout feat/two aur git rebase main karo, phir git checkout main aur git merge feat/two (fast-forward).
4. git log --oneline --graph dekho. Merge se kya fark laga?

Exercise 8.3: Conflict banao aur solve karo

1. main aur feat/conflict dono mein app.js ki same line alag tarah se badlo aur dono jagah commit karo.
2. git merge feat/conflict karo. Conflict aayega.
3. File kholkar resolve karo, phir git add . aur git commit.

Level 9: Stash (Chapter 13)

Exercise 9.1: Stash cycle

1. app.js mein ek WIP change karo (commit mat karo).
2. GitHub UI se app.js mein koi change karke commit karo.
3. git pull chalao. Kya error aaya?
4. git stash karo, phir git pull, phir git stash pop.
5. WIP change aur remote change dono file mein hain ya nahi?

Exercise 9.2: Stack test

1. 3 baar alag-alag change karo aur har baar git stash karo.
2. git stash list dekho.
3. git stash pop karo. Kaun-sa change pehle aaya?

Final Project: Mini Library System

Ek naya repo mini-library banao aur yeh sab Git se karo:

1. git init, name/email config.
2. book.js, member.js, index.js banao. Har file ka alag commit.
3. GitHub par push karo (SSH key ke saath).
4. feat/search-book, feat/borrow-book, bug/duplicate-isbn naam ki 3 branches banao, har ek mein 2 commits.
5. Har branch ko PR banakar main mein merge karo.
6. Ek branch ke saath rebase try karo.
7. Beech mein WIP change ke saath git stash ka use karo.
8. Ek commit ko git revert se undo karo.
9. VS Code Git Graph se poori history ka screenshot lo.

Chapter 16: Answers, Common Mistakes Aur Aage Ka Roadmap

16.1 Quick Check ke answers

Chapter 1

1. VCS = Version Control System.
2. Bina VCS ke: (a) pata nahi chalta kab, kisne, kya badla; (b) kuch toot jaye toh purani working state par wapas nahi ja sakte. (Teesri problem: team mein code manage karna.)
3. Git ek VCS tool hai jo local machine par chalta hai. GitHub ek website/server hai jahan Git repos online rakhte hain.

Chapter 9

1. Single source of truth = ek central jagah (remote server) jahan sabka code consistent rehta hai.
2. Push = apne commits server par bhejna. Pull = server ke naye commits apni machine par laana.
3. Pull request GitHub ka feature hai, Git ka nahi.

16.2 Exercise answers

Level 1

• 1.1: git --version ka output jaise git version 2.43.0. Naam/email ke liye git config --global user.name "..." aur git config --global user.email "...".
• 1.2 (1): VCS ek system hai jo code ke changes ko track aur manage karta hai.
• 1.2 (2): (a) Git ek VCS tool hai, GitHub ek server/website. (b) Git local machine par install hota hai, GitHub ke liye sirf account chahiye.
• 1.2 (3): Major version 3 mein kuch commands ka behavior alag ho sakta hai, isliye tutorials thode alag chal sakte hain.

Level 2

• 2.1: ls -a se .git folder dikhta hai. git add app.js ke baad VS Code mein U badalkar A dikhta hai.
• 2.2:

-const city = "Delhi";
+const city = "Mumbai";

- wali line purani, + wali line nayi.

• 2.3: git add . saari files (folder ke andar ki bhi) track kar deta hai. git status mein app.js aur helpers/math.js dono "to be committed" dikhenge.

Level 3

git add .
git commit -m "initial code added"
# greet function add karke
git add .
git commit -m "added greet function"
# isEven function add karke
git add .
git commit -m "added isEven function"
git log --oneline

• 3.2: git show <id> mein sirf us commit ke + wale function dikhenge. git blame app.js mein har line ke saamne commit ID, author aur time aayega.

Level 4

git add app.js
git status        # app.js staged, math.js not staged
git commit -m "comment added"
git show          # sirf app.js
git add helpers/math.js
git commit -m "subtract function added"

Sawaal ka jawab: agar kuch stage nahi kiya aur seedha git commit kiya, toh Git bolta hai "no changes added to commit". Kuch nahi hota, kyunki staging area khali hai.

Level 5

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

• 5.1: Galat commit history se hat jaata hai aur file wapas sahi ho jaati hai.
• 5.2: git revert <divide-commit-id> ek naya revert commit banata hai jo divide function ko hata deta hai. Aakhri commit (chhota change) bacha rehta hai.
• Challenge: shared branch par revert safe hai, kyunki woh history nahi mitata, sirf ek naya "undo" commit jodta hai. reset history badalta hai aur force push chahiye hota hai, jisse teammates ke commits kho sakte hain.

Level 6

• 6.1: Agar Permission denied (publickey) aaye toh SSH key GitHub mein sahi add nahi hui. Dobara cat ~/.ssh/id_ed25519.pub karke poori line copy karo. ssh -T [email protected] se connection test kar sakte ho.
• 6.2: git pull karte hi doosre folder ka commit aa jaana chahiye.

Level 7

• 7.1: git branch mein * feat/add-greeting par hona chahiye. PR merge ke baad main par git pull se history mein "Merge pull request #1 ..." dikhega.
• 7.2:
  1. bug/login-button-not-working
  2. feat/payment-integration
  3. junk/experiment
  4. wip/new-dashboard

Level 8

• 8.1: git log --oneline --graph mein branch ka path aur merge point alag dikhta hai.
• 8.2: Rebase mein saare 3 commits main ki seedhi line mein aate hain, koi alag branch nahi dikhti. Commit IDs bhi badal jaate hain.
• 8.3: Conflict markers aise dikhte hain:

<<<<<<< HEAD
const city = "Mumbai";
=======
const city = "Pune";
>>>>>>> feat/conflict

Aapko ek final line rakhni hai aur markers hata dene hain, phir git add . aur git commit.

Level 9

• 9.1: git pull ne error diya (local changes would be overwritten). git stash → git pull → git stash pop ke baad dono changes file mein aa jaate hain.
• 9.2: git stash pop sabse naye (top) stash ko pehle apply karta hai (stack, LIFO).

16.3 Common mistakes aur unke fix

16.4 Self-test: kya aap master ho gaye?

• [ ] Main VCS, Git, GitHub ka fark samjha sakta/sakti hoon.
• [ ] Main git init, add, commit, log, status, diff bina dekhe chala sakta/sakti hoon.
• [ ] Main staging area aur uska flow explain kar sakta/sakti hoon.
• [ ] Main reset aur revert ka fark bata sakta/sakti hoon.
• [ ] Main SSH key bana kar GitHub par add kar sakta/sakti hoon.
• [ ] Main branch banakar PR ke through merge kar sakta/sakti hoon.
• [ ] Main merge aur rebase ka fark bata sakta/sakti hoon.
• [ ] Main merge conflict resolve kar sakta/sakti hoon.
• [ ] Main git stash ka sahi use jaanta/jaanti hoon.

16.5 Interview mein puche jaane wale sawaal (bonus)

1. Git aur GitHub mein fark? Git VCS tool hai, GitHub us tool par bani hosting service.
2. Staging area kyun hota hai? Taaki aap decide kar sako ki kaun-se changes kis commit mein jayein.
3. reset vs revert? Reset history badalta hai (HEAD peeche), revert naya undo-commit banata hai.
4. merge vs rebase? Merge branches ko merge commit se jodta hai; rebase commits ko dobara latest main ke upar lagakar linear history banata hai.
5. git pull kya karta hai? Remote se naye commits laata hai (fetch) aur unhe current branch mein mila deta hai (merge).
6. Stash kab use karte ho? Jab WIP changes hon aur branch badalni ho ya pull karna ho.
7. Merge conflict kab aata hai? Jab do branches ne same file ki same line alag tarah se badli ho.
8. Force push kab nahi karna chahiye? Shared branch par, kyunki doosron ke commits mit sakte hain.

16.6 Aage kya seekhein?

1. Merge conflicts ko detail mein practice karo.
2. Open-source contribution: fork karna, multiple remotes (origin aur upstream), phir PR bhejna.
3. .gitignore file banana (jaise node_modules, .env ko ignore karna).
4. Tags aur releases (versions mark karna).
5. GitHub Actions / CI (har push par automatic tests).
6. Interactive rebase (git rebase -i) se commits ko saaf karna.
7. git cherry-pick se ek commit doosri branch mein lana.

Aakhri Baat

Git practice se aata hai, ratne se nahi. Jitna zyada commit, branch aur merge karoge, utna hi comfortable hoge. Sandbox mein galtiyan karo, unhe reset aur revert se theek karo, aur dheere-dheere yeh commands aapki muscle memory ban jayengi.

Agar yeh guide helpful laga, toh doston ke saath share karo, aur comment mein batao ki aapko kaun-sa chapter sabse zyada pasand aaya. Happy coding!

— Prabhat Upadhyay