Git टिप्स और ट्रिक्स

• लंबे समय से Git इस्तेमाल कर रहे users भी कई कम-ज्ञात features चूक सकते हैं, जिससे यह धारणा कमजोर पड़ती है कि advanced command-line knowledge आम हो चुकी है
• SVN, CVS से आए दौर के लोगों के विपरीत, केवल Git इस्तेमाल करते आए developers को कुछ advanced usage सीखने के मौके कम मिले
• समय के साथ Git ने छोटी लेकिन उपयोगी features जोड़ना जारी रखा है, और ये बदलाव खास स्थितियों में व्यावहारिक महत्व रख सकते हैं
• intermediate से advanced users के लिए पुराने लेकिन उपयोगी features, हाल में जोड़े गए features, और बड़े repositories·monorepos के विषयों को 3 छोटे लेखों की series में बांटा गया है
• Git के परिचित usage habits से परे दिखने वाले features को फिर से देखने पर रोजमर्रा के repository कामों को अधिक कुशलता से संभाला जा सकता है

---

Git को फिर से देखने की वजह

• हाल में Git और GitButler से जुड़ी presentations देते समय यह देखा कि कई developers को Git के बारे में कई बातें नहीं पता हैं
• पहले advanced Git presentations दी जाती थीं, लेकिन पिछले लगभग 10 वर्षों से यह माना जाता रहा कि लोग advanced command-line features पहले से जानते हैं
• केवल Git इस्तेमाल करते आए developers की पीढ़ी को SVN, CVS जैसे tools से Git पर switch करने या पुराने concepts को फिर से सीखने की जरूरत नहीं पड़ी
• Git ने भी समय के साथ नए features सीखे हैं, और इनमें से ज्यादातर बदलाव सूक्ष्म या खास use cases के लिए हैं, लेकिन असल काम में मदद कर सकते हैं
• FOSDEM 2024 की presentation little known Git stuff के आधार पर blog series तैयार की गई है

3 हिस्सों में बंटी Git tips series

• target audience intermediate से advanced Git users हैं, और इसमें वे features शामिल हैं जो लंबे समय से Git इस्तेमाल करने वालों से भी छूटे हो सकते हैं
• सब कुछ एक ही लेख में रखने के बजाय, कुछ-कुछ topics में बांटकर 3 छोटे लेखों के रूप में तैयार किया गया है
• शामिल topics:
  • Oldies but Goodies: पुराने लेकिन अब भी उपयोगी Git features
  • Some Subtle New Things: हाल में Git में जोड़े गए सूक्ष्म बदलाव
  • Really Large Repositories and Monorepos: बहुत बड़े repositories और monorepos से जुड़ी सामग्री
• पहला लेख Oldies but Goodies से आगे बढ़ता है

[GN⁺]

Hacker News की टिप्पणियां

• लेखक के तौर पर, वे मानते हैं कि इनमें से काफी बातें उन्होंने काफ़ी हाल ही में सीखी हैं। बड़े repositories से जुड़ी सुविधाएं पिछले कुछ वर्षों में Microsoft और GitHub ने धीरे-धीरे Git core में जोड़ी हैं, इसलिए उन्होंने जो काम किया है उसे एक जगह समेटने वाला material ढूंढना मुश्किल है
  Mercurial वाले लोगों से भी दिलचस्प बातचीत हुई, और हाल में Hg के अंदरूनी हिस्सों में से कुछ को Rust में लिखते हुए उन्हें ज़बरदस्त speed improvements मिल रहे हैं
  वे Pro Git का तीसरा संस्करण भी सोच रहे हैं, इसलिए Git को मुश्किल तरीके से सीखते हुए आपको जो बातें पता चलीं या जिनके बारे में जानना चाहते हैं, वे बताने को कहते हैं
  • शायद आपको पहले से पता हो, लेकिन Git के diff की जगह difftastic इस्तेमाल करना अच्छा है: https://difftastic.wilfred.me.uk/
    अक्सर इस्तेमाल होने वाले gitconfig aliases के तौर पर fza, gone, root इस्तेमाल करता हूं। git fza modified/new files को fzf window में दिखाता है और चुनी हुई files को git add को भेजता है: https://github.com/junegunn/fzf
    git gone remote पर मौजूद न रहने वाली local branches हटाता है, और git root repository root print करता है, जिससे deep directory से root पर लौटना आसान होता है। आजकल zoxide इस्तेमाल करने की वजह से इसका इस्तेमाल कम हो गया है: https://github.com/ajeetdsouza/zoxide
  • whitespace differences वाले हिस्से में ignore-revs-file भी जोड़ना अच्छा होगा। repository में ignore-revs file commit करके रखें, और बड़ा reformat करने वाला व्यक्ति उसमें संबंधित SHA जोड़ दे ताकि git blame खराब न हो
    https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revltrevgt
  • Git में मुश्किल से सीखी गई बातों में से एक यह है कि merge, cherry-pick, rebase जैसे operations snapshots नहीं, बल्कि differences और patches, और अधिक सटीक रूप से 3-way merge के रूप में काम करते हैं। Pro Git, Git के snapshot storage model पर अच्छा ज़ोर देता है, लेकिन सिर्फ़ इसी model को सोचने पर खासकर rebase में confusion हो सकता है
    उदाहरण के लिए, rebase के दौरान केवल एक commit हटाया था, फिर भी उसके बाद के सभी commits क्यों बदल गए, यह समझ नहीं आया। आखिरकार जब यह समझ आया कि storage snapshot-based है लेकिन operations difference-based हैं, तभी rebase समझ में आया; training में भी इस हिस्से पर ज़्यादा ज़ोर देना मददगार होगा
• Git के करतब सीखने की इच्छा नहीं है, बस इसे जितना हो सके उतना सरल तरीके से इस्तेमाल करना चाहता हूं। code push करना है, Git को खत्म करके आगे काम करते रहना है
  Git पसंद करने वालों का सम्मान है, लेकिन मेरे लिए यह बस एक tool है जिसे इस्तेमाल करना पड़ता है
  • Git की complexity का एक हिस्सा इसलिए है क्योंकि Git मूल रूप से low-level plumbing के तौर पर design किया गया था। उम्मीद थी कि Git data model के ऊपर users के लिए ज्यादा friendly surface (porcelain) आएगी, इसलिए सरल और consistent UI पाने के लिए आज भी वही दिशा बेहतर हो सकती है। Jujutsu और Got (game of trees) इसके उदाहरण हो सकते हैं
  • वह भावना समझ में आती है, लेकिन Git इतना भी मुश्किल नहीं है। basic checkout/commit/push से आगे, खासकर history rewriting जैसी कुछ चीज़ें जान लेने से commit history की quality काफ़ी बेहतर हो जाती है, और project के दूसरे engineers के लिए flow समझना आसान होता है
    Git industry में लंबे समय तक रहने वाला लगभग एक constant लगता है, और daily development में सबसे ज़्यादा छुए जाने वाले tools में से एक है, इसलिए इसे थोड़ा समझना worth है
  • कुछ details समस्या में inherent होती हैं और कुछ नहीं। मुझे लगता है कि inherent difficulty को कम आंकने की प्रवृत्ति है
    इसलिए Git की complexity एक हद तक होना ठीक लगता है
  • यह वैसा लगता है जैसे कहना कि programming सीखनी नहीं है, और computer को जितना हो सके सरल तरीके से इस्तेमाल करना है। बस यह कहना है कि क्या करना है और बात खत्म
  • Git interface leaky abstraction जैसा लगता है। Git के करतब सीखना नहीं चाहता था, लेकिन आखिरकार जितना चाहता था उससे ज्यादा जानना पड़ा
• core.fsmonitor के बारे में नई बात सीखी। बड़े monorepo के नजरिए से git clone में resume option होना अच्छा होगा
  2000s में low-bandwidth connection पर kernel repository clone करने की कोशिश में यही समस्या झेली थी, और mailing list पर मदद मांगने के बाद ही किसी ने अपनी personal site पर पूरी repository compressed tar के रूप में upload की, तब जाकर download कर पाया
  आज भी company VPN थोड़ी देर के लिए टूट जाए तो बड़े repository clone में कभी-कभी वही समस्या आती है। कल्पना करें कि Windows repository के 300GB में से 95% download हो चुका हो और Wi‑Fi थोड़ी देर के लिए कट जाए
  modern development stack में bandwidth बहुत इस्तेमाल करने वाले दो बड़े tools, Git और Docker, download resume को ठीक से support नहीं करते—यह अजीब है
  • जो चाहिए वह git bundle के करीब लगता है। हालांकि शर्त यह है कि शुरुआत में किसी को bundle बनाना होगा
    https://git-scm.com/docs/git-bundle
  • shallow clone करने के बाद उसे कई बार expand करने के तरीके से शायद संभव हो। फिर भी fetch/push protocol मूल रूप से छोटे repositories या बहुत अच्छे internet connection और server की उम्मीद करता है
• बहुत दिलचस्प। कई लोग अलग-अलग releases, features, hotfixes में contribute कर रहे हों, releases को tag कर रहे हों, और पीछे जाकर bug ढूंढ रहे हों—इन समस्याओं को आसान interface से कौन हल कर पाता है, यह देखना चाहता हूं
  यह वैसा ही है जैसे कहना कि system complexity छिपाने वाली low-level language चाहिए; दोनों असल में लगभग mutually exclusive हैं। Git संतोषजनक है और सीखने में इतना कठिन नहीं, इसलिए कुछ हद तक बस Git सीखना ही पड़ेगा
  • इसी वजह से GitKraken की जोरदार recommendation करता हूं। paid product होने के कारण सावधानी से कह रहा हूं, लेकिन मैंने कई tools आज़माए हैं और GitKraken जितना power unlock करता है, वैसा कोई नहीं था
    terminal में कई developers को जो black box महसूस होता है उसे हटाता है, graph को सामने रखता है, और rebase operations को visually natural तरीके से दिखाता है, जिससे Git मज़ेदार हो जाता है
    CLI proficiency अब भी valuable है, लेकिन 10 साल के अनुभव वाले developers को basic problems सुलझाते हुए उलझते या “सच्चे engineer को सिर्फ़ Git CLI ही इस्तेमाल करनी चाहिए” वाली vibe के कारण project history बिगाड़ते देखना निराशाजनक है
    आजकल CLI इस्तेमाल करें तब भी, मैं कहता हूं कि दिन भर किसी दूसरे window में graph जरूर देखते रहें। यह VS Code, JetBrains, यहां तक कि CLI में भी मुफ्त में संभव है

जब टीम का कोई सदस्य PR merge करता है, तो मैं उसे तुरंत देखता हूँ और अपनी branch rebase कर देता हूँ, इसलिए branch हमेशा main पर आधारित up-to-date रहती है और merge hell या भयानक “fix conflicts” commit नहीं छोड़ने पड़ते

• कल बनाए जाने के बाद से सबसे ज़्यादा बदलाव वाले top 10 files खोजते हुए https://github.com/tj/git-extras/blob/main/Commands.md मिला
  इसमें काम के कई Git extra commands हैं

  • git-extras अच्छा है। एक और अच्छा tool git absorb है: https://github.com/tummychow/git-absorb

• GitKraken जैसे modern UI clients काफी usable और मददगार हैं, फिर भी समझ नहीं आता कि ज़्यादातर developers क्यों ज़िद करके Git CLI पर ही टिके रहते हैं: https://www.gitkraken.com/

  • CLI knowledge से scripts लिखना आता है, और scripts में सीखा Git knowledge फिर daily usage में काम आता है। Server के तौर पर इस्तेमाल होने वाले Raspberry Pi में SSH करके जाने पर सिर्फ इसलिए helpless नहीं होना चाहता कि वहाँ CLI इस्तेमाल करनी पड़ेगी
    मैं GUI के पूरी तरह खिलाफ नहीं हूँ, लेकिन अभी CLI ज़्यादा efficient है और ऐसा GUI खोजने में समय नहीं लगाना चाहता जो ये शर्तें पूरी करे
    अच्छा दिखे, पुराने web browser को embed किए हुए रूप में न होकर native app हो, telemetry न हो या default में off हो, पूरी तरह open source हो, और उम्मीद की जा सके कि 5 साल बाद भी गायब नहीं होगा
    साथ ही उसे और confusing नहीं बनाना चाहिए। पिछली company में Visual Studio इस्तेमाल करना पड़ता था, जहाँ एक button पर अशुभ तरीके से “Accept merge” लिखा था, जबकि उसका मतलब असल में “conflict resolved के रूप में mark करें” था
    जिन लोगों को पहले से लगता है कि किसी खास शब्द का एक खास अर्थ है, उन्हें confuse नहीं करना चाहिए, और “Commit changes” button का मददगार बनने के नाम पर remote push तक कर देना भी भरोसेमंद नहीं लगता
  • CLI भी पूरी तरह usable है। Editor plugins भी इस्तेमाल करता हूँ, लेकिन अगर पहले से command line में हूँ तो वहीं निपटा देता हूँ
    एक commit करने के लिए किसी दूसरे program में switch करना पड़े, तो बार-बार commit करने की इच्छा कम हो जाती है
  • जब तक कोई बहुत specific समस्या न हो, Git में किए जाने वाले कामों को न्यूनतम रखता हूँ। मेरे मामले में यह लगभग push, pull, checkout तक ही है, इसलिए GUI इस्तेमाल करना overkill लगता है
  • देखने में साफ-सुथरा लगता है, लेकिन graphical interface बहुत आसानी से ध्यान भटका देता है। आखिरकार यह personal preference का मामला लगता है, और CLI तेज़ है लेकिन learning curve बड़ा है
    CLI में Git इस्तेमाल करते समय भी ज़्यादातर कुछ खास नहीं, बस कुछ commands ही होते हैं, और जो tips या tricks अक्सर इस्तेमाल नहीं होते उन्हें text file में लिखकर रखता हूँ

• -committerdate के बारे में पता था, लेकिन इसे default sorting के रूप में set किया जा सकता है यह नहीं पता था, और यह बहुत useful है। कुछ notes हैं
  git columns अगर screen में पूरा नहीं आता और scroll करना पड़े तो काफी confusing हो जाता है, इसलिए numbers हों तो अच्छा होगा
  git maintenance अच्छा दिखता है, लेकिन मैं rebase बहुत करता हूँ इसलिए चिंता है। जानना चाहता हूँ कि क्या loose objects gc की तुलना में ज़्यादा जल्दी खो जाते हैं। gc off दिखता है, लेकिन साफ नहीं है
  git blame से जुड़ा एक बहुत प्रसिद्ध नहीं, लेकिन useful script https://github.com/gnddev/git-blameall है। यह इतना कम जाना जाता है कि मुझे खुद इसे Python 3 में port करना पड़ा, और मैं Python developer भी नहीं हूँ

  • Scheduled maintenance में gc disabled रहता है। जब maintenance run को explicitly run करते हैं, तो यह task के रूप में enabled होता है
    Loose objects को gc से ज़्यादा जल्दी collect नहीं करता। आखिर में यह बस gc चलाता ही है
  • सोच रहा हूँ कि reverse sorting संभव है या नहीं। Branches के screen से बाहर चले जाने की समस्या का सरल solution latest branches को अंत में रखना लगता है। मैं अपने user script में ऐसा ही करता हूँ
  • वे ज़्यादा जल्दी नहीं खोते। यह बस remote से data ज़्यादा बार fetch करता है और data को फिर से pack करता है। अगर GC off है तो data delete नहीं होता
    git-blameall ठीक लग रहा है, इसे एक बार आज़माना चाहिए

• कई environments में चलने वाले कुछ aliases से Git flow को काफी सरल बना दिया है
  git synced current branch को upstream हो तो उसके साथ, नहीं हो तो origin के साथ rebase करके sync करता है। master या main इस्तेमाल करता है और main को priority देता है
  git pub changes को remote origin पर publish करता है और lease के साथ force push इस्तेमाल करता है
  git pr GitHub पर सही PR URL खोलता है और GH client की ज़रूरत नहीं होती। अगर upstream defined है तो PR उसी तरफ भेजता है
  git hub repository का GitHub page खोलता है
  https://softwaredoug.com/blog/2022/11/09/idiot-proof-git-aliases.html

  • Separator के रूप में इस्तेमाल किए गए अजीब furry arrow को क्यों चुना, यह जानना चाहता हूँ

• क्या कर रहा हूँ यह जानने का दिखावा छोड़कर visual Git tools इस्तेमाल करता हूँ। SmartGit या IntelliJ में मौजूद tools जैसी चीज़ें। Git “command-line hero” होना मुझे ज़्यादातर दिखावे जैसा लगता है
  Users के लिए command layer परेशान करने की हद तक confusing हो सकती है। उदाहरण के लिए Yours और Theirs context के हिसाब से बिल्कुल उलटा अर्थ रख सकते हैं
  पूरे user interface में कोई common style या theme नहीं है, इसलिए लोगों को पागल होने से बचाने के लिए एक नई visual layer चाहिए

  • मेरे साथ भी यही है। हमेशा differences देख पाना, और क्या होने वाला है यह एक नज़र में visually confirm कर पाना अच्छा लगता है। कई extra commands चलाने की ज़रूरत भी नहीं होती
    App और पूरे Git को काम के लिए जितना चाहिए उतना ही जानता हूँ, और कभी-कभार ज़्यादा ज़रूरत पड़े तो खोज सकता हूँ। कई सालों के इस्तेमाल में ऐसा बस एक-दो बार ही हुआ है
  • Daily work के लिए हमेशा visual Git tool, खासकर Tortoise Git इस्तेमाल करता हूँ
    दूसरों की या अपनी गलती ठीक करने वाले complex कामों में भी पहले visual tool से history और commits, reflog, differences देखता हूँ और समझता हूँ कि क्या गड़बड़ हुआ है और क्या बचाया जा सकता है
    अगर सिर्फ एक commit पर वापस जाना हो तो reset --hard करता हूँ, और अगर कई commits से कुछ मिलाना हो तो आमतौर पर command line इस्तेमाल करता हूँ

• दोनों एक-दूसरे के विरुद्ध नहीं हैं। diff या conflict जैसी चीज़ों के लिए मैं सिर्फ़ visual tools का इस्तेमाल करता हूँ, लेकिन commit objects, reflog, rebase पर्दे के पीछे क्या करता है, interactive rebase, hard/soft reset वगैरह सीखकर मुझे बहुत कुछ मिला।