Beej की Git गाइड

• Git सीखने या संदर्भ के तौर पर देखने वाले पाठकों के लिए HTML·PDF वितरण संस्करण कई फॉर्मैट में उपलब्ध कराने वाला गाइड पेज
• गाइड खुद गलतियों की संभावना मानकर चलती है, और Git से जुड़ी गलत सामग्री के लिए ईमेल के जरिए सुधार सुझाव स्वीकार करती है
• HTML वितरण संस्करण में पढ़ने के माहौल के अनुसार split version, single page, widescreen, ZIP आदि विकल्प चुने जा सकते हैं
• PDF को US Letter·A4, single-sided·double-sided, syntax highlighting version·black and white version के संयोजन में डाउनलोड किया जा सकता है
• अनुवादक और लेखक पूरा material GitHub से clone करने के बाद README का पालन करके काम कर सकते हैं

---

पढ़ने के लिए वितरण फॉर्मैट

• HTML

  • HTML
  • HTML, widescreen
  • HTML, single page
  • HTML, single page, widescreen
  • HTML ZIP
  • HTML ZIP, widescreen

• PDF

  • US Letter, one sided, syntax highlighting
  • US Letter, two sided, syntax highlighting
  • A4, one sided, syntax highlighting
  • A4, two sided, syntax highlighting
  • US Letter, one sided, black and white
  • US Letter, two sided, black and white
  • A4, one sided, black and white
  • A4, two sided, black and white

सुधार सुझाव और मूल कार्य सामग्री

• गाइड गलतियां होने की संभावना को खुला मानती है, और सुधार सुझाव ईमेल से स्वीकार करती है
• अनुवादक और लेखक GitHub repository को clone करके README का पालन कर सकते हैं

[GN⁺]

Hacker News की राय

• अगर कोई गलती मिले तो भेज दें। मैं खुद व्यवस्थित करके ठीक कर दूंगा — Beej

  • गलती तो नहीं है, लेकिन Git के संदर्भ में vim को कवर कर रहे हैं तो :cq भी शामिल किया जा सकता है। यह non-zero exit status के साथ बाहर निकलता है, जिससे Git commit या task पूरा नहीं कर पाता
  • सच में शानदार काम है, और इतना comprehensive resource बनाने के लिए धन्यवाद। मैंने पूरा नहीं पढ़ा, लेकिन सेक्शन 5.1 की wording पर ध्यान गया
    https://beej.us/guide/bggit/html/split/branches-and-fast-for... में कहा गया है कि “default branch main है” और “पहले यह master था, और पुराने repositories में अभी भी master है”, लेकिन यह सही नहीं है। Git अभी भी master को default के रूप में इस्तेमाल करता है, और बस भविष्य में git init के लिए git config --global init.defaultBranch से इसे बदलने की सुविधा देता है
    स्रोत: https://github.com/git/git/blob/bc204b742735ae06f65bb20291c9...
    साथ ही “पुराने repositories” वाला phrase गलत message देता है। यह बदलाव GitHub ने तय किया और बाकी जगहों ने follow किया; Git ने भी ऊपर वाली setting allow कर दी। यानी यह नए/पुराने repository का मामला नहीं, बल्कि preference का मामला ज्यादा है
  • मैं Lambda School में पढ़े अनगिनत students में से एक था, और उस समय की class मेरे लिए सबसे यादगार moments में से एक थी
  • मैंने teenage में C programming guide पढ़ी थी, और अब firmware developer के रूप में आज भी खुद को उसका बहुत ऋणी महसूस करता हूं
  • गलती तो नहीं है, लेकिन git worktree का भी जिक्र होना चाहिए। मेरे workflow में यह core रहा है, और कई लोगों को तो इसके existence के बारे में भी पता नहीं था
    stash से निपटने की झंझट के बिना branches को आपस में उलझने से बचाए रखने का यह अच्छा तरीका है

• Teenage में पढ़ी हुई Beej's Guide to Network Programming और Beej's Guide to Unix IPC accessible होने के साथ-साथ गहरी भी थीं, और आगे चलकर मैं कैसा programmer बना, इस पर उनका बड़ा असर पड़ा
  [0] https://beej.us/guide/bgnet/
  [1] https://beej.us/guide/bggit/

  • [1] असल में https://beej.us/guide/bgipc/ है
  • मेरे साथ भी कुछ ऐसा ही था। 90s के mid में मैं teenager था, और IRCd server code और bots से हैरान था
    मैंने second-hand Slackware Linux unleashed खरीदी थी, जिसके साथ CD-ROM था और उसमें C networking examples थे। वे code मुझे confusing लगे, तो मैं Beej की networking site तक पहुंचा। वहां से मैं और डूबता चला गया, एक गहरी rabbit hole में उतर गया, और programming books ढूंढने के लिए कई bookstores के चक्कर लगाया करता था
    Richard Stevens की बेहतरीन reference book खरीदने के बाद फिर पीछे मुड़कर नहीं देखा, और उस passion को संभव बनाने के लिए मैं आज भी Beej का आभारी हूं
  • select इस्तेमाल करना सीखने के दिनों में, किसी port scanner (शायद “grabb”?) को तेज़ बनाना चाहता था, इसलिए मैंने Beej की network guide का Italian में translation किया था—यह याद आज भी है। मजेदार दिन थे
  • मैं यह confirm करने आया था कि क्या यह वही व्यक्ति है, और हर page पर दिखने वाली पुराने web design वाली personality देखकर लगभग यकीन हो गया
    वह समय था जब पिता के phone bill पर नाराज़ न होने के लिए pages offline पढ़ने के लिए save किया करता था, और जब code चल जाता था तो लगता था जैसे जिंदगी की पिछली नाकामियों और rejections से ऊपर कोई validation मिल गया हो। एक computer से दूसरे computer पर message भेजने की खुशी बहुत बड़ी थी

• “पुराना command: git checkout” देखकर मुझे यह भी नहीं पता था कि git switch मौजूद है, और यह भी नहीं पता था कि git checkout को पुराना alternative माना जाने लगा है। खुद को बूढ़ा महसूस कर रहा हूं
  लगभग 10 साल पहले Git सीखना शुरू किया था, तो ठीक है, लेकिन यह अजीब लगता है कि आज Git सीखने वाला कोई व्यक्ति यह देखकर confuse हो सकता है कि मैं git checkout क्यों इस्तेमाल करता हूं। जैसे कोई outdated expression बोल रहा हूं
  लेख पर लौटें तो, जब मैं सीख रहा था तब यह guide होती तो वाकई बहुत उपयोगी होती। Follow करना आसान है और common questions को अच्छी तरह cover करती है
  मुझे यह भी अच्छे से याद है कि पहले merge conflict से डरकर रुक गया था, और फिर conflicts से बचने के लिए workarounds अपनाए थे

  • git switch काफी नया command है और पहली बार 2019 में release हुआ था
    2021 की discussion और कुछ हफ्ते पहले की discussion, दोनों मौजूद हैं; बाद वाली में यह भी आता है कि documentation में git switch को अभी भी experimental feature माना जाता है
    https://news.ycombinator.com/item?id=28024972
    https://news.ycombinator.com/item?id=42649858
  • मुझे नहीं लगता कि git checkout को अभी “पुराना alternative” माना जाता है। आखिरी बार जब मैंने check किया था, switch अब भी experimental था, और लगभग 15 साल पहले Git सीखते समय जो workflow और commands सीखे थे, उनसे हटने का मैंने सोचा भी नहीं
    जो भी काम करना चाहता हूं, सब अब भी वैसा ही चलता है, git checkout भी पहले जैसा ही काम करता है, और दूसरों के साथ Git पर collaborate करने में कोई दिक्कत नहीं आती—तो workflow बदलने की वजह ही क्या है

• Git इस्तेमाल करने का तरीका समझाने के लिए 30 से ज़्यादा हिस्सों वाली guide की ज़रूरत होना ही अपने-आप में ऐसा लगता है कि Git ने बड़ी तस्वीर कहीं खो दी है

  • programmers इतने भड़क क्यों जाते हैं इस बात पर कि जटिल data structures पर जटिल काम करने वाले जटिल tool में कुछ हद तक complexity होती है, यह समझ नहीं आता
  • अगर लोग Git की शिकायत करने में लगाई गई मेहनत का आधा भी Git सीखने में लगाते, तो manual pages में मिल जाने वाली बातों को समझाने के लिए 30 से ज़्यादा हिस्सों वाली guide बनाने की ज़रूरत शायद नहीं पड़ती
    commit tree का snapshot होता है, और उसके पास ancestors की list होती है. आम तौर पर एक, लेकिन हमेशा ऐसा नहीं. tag एक न बदलने वाला commit nameplate है, और branch बदलने वाला commit nameplate है. index एक छोटा-सा in-progress proto-commit है जिसे commit करने से पहले add से भरा जाता है
    यही Git है. और जानना हो तो guide पढ़ने के बजाय “tree को प्रभावित किए बिना किसी खास Git commit पर switch कैसे करें”, “बदली हुई files में से सिर्फ कुछ को commit कैसे करें”, “कहीं और के commit को current tree में copy कैसे करें” जैसी चीज़ें search कर लें
    बुनियादी abstraction minimalistic और आसान है. उस abstraction से जो काम आप करना चाहते हैं, वे sophisticated और जटिल हैं. पहले को सीखिए और दूसरे के लिए search कीजिए; guide पढ़ने की ज़रूरत नहीं
  • Git इस्तेमाल करने का तरीका HN comment की 5 lines में भी समझाया जा सकता है: git clone, git checkout, git pull, git add + commit + push, git reset / rebase
  • फिर भी आप अपने ही पैर पर कुल्हाड़ी मार सकते हैं
  • हाँ भी और नहीं भी. Git के user-facing commands शायद 95% users के लिए काफी अच्छे हैं
    rebase -i में यह guidance लगी होती है कि कौन-सा command क्या करता है, और git log output को अपनी पसंद और trade-offs के हिसाब से format करना कुछ paragraphs में समझाया जा सकता है. आम तौर पर user-facing commands में git gc, git fsck, git rev-parse जैसी काफी miscellaneous चीज़ें भी शामिल मानी जाती हैं
    low-level commands निश्चित रूप से ज़्यादा कठिन हैं, और वे अपने-आप में बहुत-से ऐसे काम करते हैं जिन्हें common use cases के लिए optimized user-facing commands से हमेशा आसानी से नहीं किया जा सकता
    संक्षेप में, Git बड़ा है, बल्कि बहुत बड़ा है, लेकिन ज़्यादातर developers के लिए इसकी काफी सारी capabilities mainstream path से बहुत दूर हैं

• डराने वाली बात यह है कि guide इतनी लंबी है
  मुझे पता है कि Beej की guides आम तौर पर comprehensive होती हैं, लेकिन Git की विशाल subtlety का सही अंदाज़ा इसे देखने से पहले नहीं था
  Jujutsu होता तो शायद guide काफी पतली होती, या कम-से-कम ऐसी guide होती जिसे इंसान ज़्यादा आसानी से खोजते-खोजते सीख सके

  • मैं अपनी ज़्यादातर guides ऐसी बनाने की कोशिश करता हूँ कि जब लगे कि आपने पर्याप्त पढ़ लिया है, तो पढ़ना बंद कर सकें. पूरी पढ़ना ज़रूरी नहीं है
    मुझे लगता है यह guide Git का सिर्फ करीब 10% cover करती है, लेकिन उम्मीद है कि common usage का 90% cover करे
  • यह guide comprehensive side पर है, और दूसरी extreme पर एक one-page material है जिसमें आगे आपको ज़रूरत पड़ने वाले Git commands के 90% हैं: https://wizardzines.com/git-cheat-sheet.pdf
  • यह इस बात का संकेत लगता है कि Git ज़्यादातर लोगों के लिए सही tool नहीं है, लेकिन किसी तरह standard जैसा जम गया है

• काम पर साल में एक-दो बार, 2 घंटे का Git data model introduction course चलाता हूँ
  असल में .git directory के अंदर जाकर files खोलकर दिखाता हूँ कि सब कुछ सिर्फ basic data structures की plain-text representation है. लोगों के दिमाग में अचानक बात बैठते हुए देखना सच में कमाल होता है
  नए joiners code commit करना शुरू कर सकें, इसलिए basic Git recipe document share करता हूँ, लेकिन ज़्यादातर लोग क्या हो रहा है यह समझे बिना बस उसे follow करते हैं
  इसके उलट, class लेने वाले लोग भले ही सारे commands अच्छी तरह न जानते हों, लेकिन Git में असल में क्या चल रहा है इसकी काफी reasonable working understanding हासिल कर लेते हैं. commands आसानी से search किए जा सकते हैं, इसलिए अगर mental model सही हो तो commands खुद कोई बड़ी समस्या नहीं हैं. फिर भी HN पर लगभग हर Git post की discussion command line की बातों पर चली जाती है
  दिलचस्प बात यह है कि यह class https://xkcd.com/1597/ के alt text जैसी सुनाई देती है. फर्क यह है कि technical readers के लिए यह सच में Git सिखाने का सही तरीका है, और एक बार समझ में आ जाए तो ऐसी foundational understanding मिलती है जिसे आप भूलते नहीं
  सच कहूँ तो इसका return on time इतना ज़्यादा है कि इसे न करना अजीब लगता है

  • मैंने भी एक बार ऐसा किया था और यह सच में अच्छा रहा, और उसके बाद की discussion भी बहुत शानदार थी
    presentation की आखिरी slide में Git data model के आधार पर colleagues के जवाब देने के लिए सवाल डाले थे. जैसे “क्या commit को दूसरी branch में ले जाया जा सकता है?”, “यह क्या guarantee करता है कि commit graph में cycle नहीं है?” जैसे सवाल
    यह देखकर सच में संतोष हुआ कि लोग सिर्फ Git इस्तेमाल करने तक सीमित नहीं रहे, बल्कि Git के बारे में सोचने लगे
  • “mental model सही हो तो commands बड़ी समस्या नहीं हैं” यह बात शुरुआत में 90s में अक्सर दिखने वाली “अगर आप Linux की हर layer और हर part समझ लें तो Linux इस्तेमाल करना आसान है” जैसी दलील लग सकती थी. theory में सही, लेकिन ज़्यादातर लोगों के लिए practically असंभव जैसी बात
    सौभाग्य से मैंने शुरू में Git के internal model का कुछ हिस्सा समझाने वाला video देखा था, और पता चला कि असल में internal knowledge बहुत ज़्यादा या गहरी न हो, तब भी बड़ा फर्क पड़ता है. Git कैसे काम करता है इसका लगभग 5% जान लेने से भी commands क्या करते हैं और उन्हें कैसे इस्तेमाल करना है, यह काफी बेहतर समझ में आने लगा
  • उत्सुक हूँ कि उस 2 घंटे के course material या recording में अगर कोई proprietary information या public करने से रोकने वाली restriction न हो, तो क्या आप share कर सकते हैं
    अगर यह public और 2 घंटे में fit होने लायक concise material पर आधारित था, तो अच्छा होगा अगर आप इसे इस thread या HN post के रूप में share करें. मेरा मानना है कि एक ही topic पर भी अलग premises, analogies और focus वाले learning materials जितने ज़्यादा हों उतना अच्छा
  • जानना चाहूँगा कि presentation की copy या video है या नहीं, या फिर recommend करने लायक कोई similar material है या नहीं
  • video share करें

• Git का general flow, merge, rebase वगैरह कुछ हद तक कर लेता हूँ, लेकिन Git में बेहतर होने की कोशिश करने के बजाय jujutsu पर switch करने के बारे में गंभीरता से सोच रहा हूँ. jj Git-compatible है, और colleagues के plain Git इस्तेमाल करते रहने के दौरान मैं अकेले इसे इस्तेमाल कर सकता हूँ

• मुझे लगता है कि एक तरकीब है जिसे कई गाइड और ज़्यादातर Git GUI मिस कर देते हैं। अपवाद के तौर पर magit इसे अच्छे से संभालता है
  upstream branch को feature/foo के origin/feature/foo पर नहीं, बल्कि उस target पर सेट करना जिससे आप merge करना चाहते हैं, यानी integration branch master या origin/master पर
  ऐसा करने से बहुत कुछ सरल हो जाता है। git status चलाने पर यह बताता है कि आप integration branch से कितना अलग हो गए हैं, इसलिए उपयोगी है, और बिना arguments के git rebase चलाने पर यह सीधे upstream के ऊपर rebase हो जाता है
  origin/feature/foo को upstream रखना कम उपयोगी है। Developers आम तौर पर remote पर अपनी branch को भी “own” करते हैं, इसलिए उससे आप कितना अलग हुए हैं, इसका ज़्यादा मतलब नहीं होता, और उस पर rebase करना चाहने की भी नौबत नहीं आती
  push.default को "current" पर सेट करने से git push भी उम्मीद के मुताबिक feature/foo को origin/feature/foo पर push करता है
  सोचता हूँ कि ऐसी setting ज़्यादा common क्यों नहीं है

• collaboration section में feature branches को बिल्कुल cover नहीं किया गया है। मुझे लगता है कि यह काफ़ी common workflow है
  Guide के “हर कोई अपनी branch इस्तेमाल करता है” वाले तरीके से तुलना की जाए तो उपयोगी होगा। साथ ही section 17 में GitHub pull requests के लिए branch reuse करने के तरीके और हर PR के लिए नई branch बनाने के तरीके पर बात की जा सकती है

• लेख अभी देखा नहीं है, लेकिन अच्छा लग रहा है। एक और recommendation के तौर पर Primeagen द्वारा पढ़ाया गया boot.dev का Git course है
  यह interactive है और .git directory के अंदर files को सीधे manipulate करने के स्तर तक गहराई में जाता है। वह course करने के बाद Git कैसे काम करता है, इसे लेकर मेरे पास एक बिल्कुल नया mental model बन गया