Code10x

Ek distributed version control system hai jo code ki har change track karta hai — history dekhna, purane versions par jaana, aur multiple logon ke saath ek hi project par kaam karna possible banata hai.

Linus Torvalds ne 2005 mein banaya tha — Linux kernel development ko manage karne ke liye ek fast, distributed version control system chahiye tha.

Har developer ke paas poori project history ki ek complete copy hoti hai apne local machine par, centralized systems ke unlike jahan sirf ek central server ke paas poori history hoti hai.

"user.name" aur "user.email" — ye info har commit ke saath attach hoti hai, batati hai ki changes kisne kiye.

Settings poore system ke liye apply hoti hain — specific projects ke liye alag config chahiye ho to --global hata kar usi repo mein command chalao.

Ek existing folder ko ek Git repository mein convert kar deta hai — ek hidden ".git" folder banata hai jisme poori version history store hoti hai.

Har cheez jo Git ko kaam karne ke liye chahiye — commits, branches, config aur poori history. Isse delete karne se poori version history permanently kho jaati hai.

Working Directory (actual files jo tum edit karte ho), Staging Area (changes jo next commit mein jaayenge), aur Repository (committed history).

Extra control deta hai — tum multiple files change kar sakte ho lekin sirf kuch specific files ko hi ek commit mein shamil kar sakte ho.

"git add <file>" ek specific file stage karta hai, "git add ." current directory ki saari changed files stage kar deta hai.

Git ek snapshot banata hai staged changes ka — har commit ka ek unique SHA-1 hash hota hai jo uske content aur parent commit se derive hota hai.

Add aur commit dono ek saath karta hai, lekin sirf already-tracked files ke liye kaam karta hai, nayi files ke liye nahi.

Ek short (50 characters se kam) summary line, phir ek blank line, aur detailed explanation (72 characters par wrap) jo "why" batati hai.

Convention hai kyunki Git ke apne auto-generated messages (jaise merge commits) bhi isi style mein hote hain — "Add feature" na ki "Added feature".

Ek compact, ek-line-per-commit view deta hai, poore log ke baad se.

Har line ke saath dikhata hai ki use kaunse commit ne aur kisne last edit kiya tha — bugs ke origin ko trace karne ke liye useful hai.

Working directory ke unstaged changes ko staging area se compare karta hai — dikhata hai ki kya naya hai jo abhi tak git add nahi hua.

Staging area ko last commit se compare karta hai — dikhata hai ki next commit mein kya jaayega.

Bas ek "pointer" hai ek specific commit ki taraf — kisi "copy" ki tarah heavy structure nahi, isi wajah se branches banana aur switch karna instant hota hai.

Ek special pointer hai jo batata hai ki tum abhi kaunse branch (aur isliye kaunse commit) par ho — branch switch karne par HEAD bhi move ho jaata hai.

git branch ek naya branch banata hai lekin uspar switch nahi karta. git switch us branch par move kar deta hai.

Agar target branch mein source branch ke baad koi naya commit nahi hua hai to Git ek fast-forward merge karta hai — sirf pointer ko aage move kar deta hai.

Agar dono branches mein independent changes hue hain to Git ek three-way merge karta hai — naya "merge commit" banata hai do parents ke saath.

Fast-forward hone ke baavjood ek explicit merge commit force karta hai — isse history mein clear dikhta hai ki ek feature branch mein develop hui thi.

Jab dono branches ne same line (ya nearby lines) ko different tareeke se change kiya ho — Git khud decide nahi kar sakta ki kaunsa version rakhna hai.

Conflict markers ko manually edit karke desired content rakhna padta hai, phir git add karke aur git commit (ya git merge --continue) se merge complete karna padta hai.

-d (lowercase) ek merged branch ko safely delete karta hai. -D (uppercase) force delete karta hai, chahe wo merged na ho.

Ek file ke unstaged changes ko discard kar ke use last commit ki version par wapas le aata hai — ye irreversible hai agar changes kahi aur save na hon.

Ek file ko staging area se hata deta hai — file ke actual changes working directory mein safe rehte hain, sirf wo "staged" nahi rehte agle commit ke liye.

--soft (changes staging area mein rakhta hai), --mixed (default, changes working directory mein laata hai), aur --hard (saari changes permanently discard karta hai).

Working directory ki saari uncommitted changes ko permanently mita deta hai bina koi warning ke — use se pehle hamesha git status se check karo.

Ek safety net hai — chahe reset --hard se commits kho jaayein, reflog mein unka record kuch din tak rehta hai jisse use recover kiya ja sakta hai.

Revert ek naya commit banata hai jo purane commit ke changes ko undo karta hai — reset history ko modify/rewrite karta hai.

Kyunki revert history ko modify nahi karta, sirf ek naya "undo" commit add karta hai — isse doosre developers ko koi problem nahi hoti.

Abhi ke uncommitted changes ko ek temporary storage mein rakh deta hai aur working directory ko clean bana deta hai — useful hai jab achanak doosri branch par switch karna pade.

pop stash ko apply karta hai aur use list se hata deta hai. apply apply karta hai lekin list mein hi rakhta hai agar dobara use karna ho.

Bas ek named reference hai ek doosre repository ki URL ki taraf — default remote ka naam "origin" hota hai jab tum git clone karte ho.

Jaise "origin" (tumhara own fork) aur "upstream" (original repository jisse tumne fork kiya tha) — open-source contributions ke liye common pattern hai.

Ek existing remote repository ki poori history (saare commits, branches, tags) ko local machine par download kar deta hai, automatically "origin" remote setup karke.

Sirf latest commit download hota hai, poori history nahi — large repositories ke liye clone time aur disk space kaafi bachata hai, CI/CD mein common hai.

Agar kisi aur ne meanwhile remote par naye commits kiye hain to push reject ho jaata hai jab tak pehle pull na karo.

Local branch ko remote branch se "link" kar deta hai, taaki aage se sirf "git push" (bina arguments) hi kaafi ho.

fetch naye commits download karta hai lekin current branch ko touch nahi karta. pull = fetch + merge (ya rebase) ek saath.

"git fetch" karke pehle changes review karte hain, phir manually merge/rebase karte hain — instead of blindly pull karne ke.

Pull karte waqt merge commit banane ke bajay local commits ko remote commits ke upar "replay" karta hai — linear history ke liye useful hai.

Current branch ke commits ko temporarily hata deta hai, target branch ko latest version par move karta hai, aur phir commits ko uske upar "replay" kar deta hai.

Merge ek "merge commit" banata hai jisme branching pattern dikhta hai. Rebase ek clean linear history banata hai.

Kabhi bhi ek public/shared branch ko rebase mat karo — kyunki rebase existing commits ke hashes change kar deta hai, jo doosre developers ki history se conflict kar sakta hai.

Ek editor kholta hai jahan commits ki list dikhti hai — har commit ke saamne ek action (pick, reword, squash, drop) likha ja sakta hai.

Multiple small commits ko ek hi commit mein combine kar deta hai — messy "WIP" ya "fix typo" commits ko ek clean commit banane ke liye useful hai.

Ek specific commit (kisi bhi doosre branch se) ko lekar current branch par apply kar deta hai, bina poori branch ko merge kiye.

Hotfixes — ek critical bug fix jo "develop" branch mein kiya gaya tha use "production" branch mein bhi apply karna, bina develop ki doosri unrelated changes laye.

Last commit ko modify kar deta hai — ya to uska message change karke ya usme nayi staged changes add karke — ek naya commit nahi banata, purane ko replace karta hai.

Jab commit already push ho chuka ho — kyunki amend commit ka hash change kar deta hai, jo doosre developers ke saath conflict create kar sakta hai.

Git ek version control tool hai jo kisi bhi computer par run hota hai. GitHub ek website/service hai jo Git repositories ko cloud mein host karta hai aur extra collaboration features (issues, PRs) add karta hai.

GitHub 2008 mein launch hua tha — Microsoft ne 2018 mein ise acquire kiya tha.

GitLab aur Bitbucket — sab Git ko hi underlying technology ki tarah use karte hain.

Public repositories kisi bhi ko dikh sakti hain aur clone ki ja sakti hain — Private repositories sirf invited collaborators ko hi dikhti hain.

GitHub par repository ke home page par automatically render ho jaata hai — first impression hai jo koi bhi visitor dekhta hai.

Ek built-in issue tracker hai — bugs, feature requests ya tasks ko document karne ke liye use hota hai, labels/assignees/comments ke saath.

GitHub automatically us issue ko link kar deta hai, aur jab PR merge hota hai to issue automatically close ho jaata hai.

Ek doosre user ki repository ki ek complete copy hai tumhare apne GitHub account mein — useful hai jab tumhare paas original repository mein direct write access nahi hai.

Fork karo -> clone karo apne local machine par -> ek branch banao -> changes karo -> push karo apne fork mein -> ek Pull Request banao original repository ki taraf.

Ek proposal hai — "mere branch ke changes ko apni main branch mein merge kar do" — discussion, code review aur automated checks ke liye ek platform provide karta hai.

Ek PR banate ho jo abhi review ke liye ready nahi hai — early feedback ya CI checks chalane ke liye useful hai bina team ko "review karo" signal diye.

Reviewers ek PR ke diff mein specific lines par comments chhod sakte hain — suggestions, questions ya concerns raise karne ke liye.

Approve (merge ke liye ready), Request Changes (blocking feedback hai), aur Comment (general feedback bina explicit approve/reject ke).

Ek CI/CD platform hai jo directly GitHub ke andar built-in hai — YAML files (.github/workflows/) mein define kiya jaata hai ki kaunse events par kya workflows run honge.

Directly PR page par "status checks" ki tarah dikhta hai — teams ye enforce kar sakti hain ki failing checks waale PRs merge hi na ho sakein.

"main" jaisi important branches par direct push ko block karti hain — saari changes ko hamesha ek Pull Request ke zariye hi aana padta hai.

Ki ek PR ko merge hone se pehle kam se kam ek approved review chahiye aur saare CI checks pass hone chahiye.

Contributors ko accidentally "main" branch ko break karne se rokti hai — quality control ka essential layer hai.

Patterns (jaise "node_modules/", "*.log", ".env") define karti hai jo Git ko batate hain ki in files/folders ko ignore kar do.

Sirf .gitignore mein add karne se wo untrack nahi hogi — "git rm --cached <file>" bhi chalana padega.

Ek specific commit ko ek permanent naam dete hain (jaise "v1.0.0") — version releases ko mark karne ke liye use hote hain.

GitHub Releases ek tag ke upar extra info (release notes, binary attachments) add karta hai — users ko ek specific version download karne ka easy way deta hai.

Ek doosre Git repository ko ek specific commit par "pin" kar ke apne main repository ke andar ek subdirectory ki tarah include karne ka tareeka.

"git clone" karne par default mein submodules empty rehte hain — "--recurse-submodules" flag ya alag se "git submodule update --init" chalana padta hai.

Scripts jo automatically run hote hain specific Git events par (jaise "pre-commit" ya "pre-push") — .git/hooks/ folder mein rakhe jaate hain.

Kyunki .git/hooks/ folder Git history ka hissa nahi hota — "Husky" jaisi tools se hooks ko project ke andar define kiya ja sakta hai.

GitFlow mein main/develop/feature/release/hotfix branches ka structured system hota hai. Trunk-Based Development mein sirf ek main branch aur short-lived feature branches hote hain.