25 पॉइंट द्वारा GN⁺ 2025-04-09 | 6 टिप्पणियां | WhatsApp पर शेयर करें
  • Git एक version control system है, जिसकी शुरुआत 20 साल पहले Linus Torvalds के पहले commit से हुई थी
  • यह मूल रूप से एक साधारण personal project था, लेकिन बाद में दुनिया भर में सबसे व्यापक रूप से इस्तेमाल होने वाला version control system बन गया
  • लेखक GitHub के सह-संस्थापक हैं और Git से जुड़ी किताबों व community के निर्माण के जरिए Git के विकास में गहराई से शामिल रहे हैं
  • शुरुआत में यह सिर्फ directory content management का एक साधारण टूल था, लेकिन आज यह software development के तरीके को बदल देने वाला एक मुख्य टूल बन चुका है

Git का दर्शन और इसकी ज़रूरत

  • Git का जन्म Linux kernel community में मौजूदा version control tools की सीमाओं से असंतोष के बीच हुआ
  • उस समय सहयोग का प्रचलित तरीका mailing list, tarball और patch files के ज़रिए distributed और local-आधारित collaboration था
  • उस दौर के SCM tools धीमे, केंद्रीकृत और अक्षम थे, इसलिए tarball/patch आधारित तरीका ज़्यादा बेहतर माना जाता था
  • Bitkeeper नाम का एक टूल विकल्प था, लेकिन licensing समस्याओं की वजह से Git का विकास शुरू हुआ
  • Git को शुरू से "version control system" के रूप में नहीं, बल्कि patch और tarball को बेहतर तरीके से संभालने वाली data structure के रूप में डिज़ाइन किया गया था

Git का पहला commit

  • पहला commit directory contents को ट्रैक करने वाला एक बेहद बुनियादी टूल था
  • उस समय के टूल git commit जैसे commands नहीं थे, बल्कि write-tree, commit-tree जैसे low-level database tools थे
  • Git में शुरू से ही ये क्षमताएँ थीं:
    • working directory को cache में सेव करना (update-cache), उसे tree object में बदलना (write-tree) और database में रिकॉर्ड करना
    • changes को commit के रूप में सेव करना (commit-tree) ताकि history बन सके
    • cat-file, read-tree, show-diff से database objects को पढ़ना और तुलना करना
  • Linus, Git को सिर्फ backend "plumbing tool" मानते थे और चाहते थे कि UI बाहर से बनाया जाए

Git का इस्तेमाल करके content distribution का एक उदाहरण

  • लेखक ने 2005 में Reactrix नाम की एक startup में digital advertising content distribution के लिए Git का इस्तेमाल किया
  • सैकड़ों digital displays को अलग-अलग ad combinations चाहिए थे, और Git की content-addressing क्षमता ने इसे कुशलतापूर्वक हल किया
  • यह Git को code management नहीं, बल्कि content distribution tool के रूप में इस्तेमाल करने का एक रचनात्मक उदाहरण था
  • शुरुआती Git project के प्रमुख contributor Nick Hengeveld ने SSL, parallel HTTP transfer जैसी सुविधाएँ जोड़ीं
  • इसी अनुभव ने Git से जुड़े documentation, website और किताबें बनाने की प्रेरणा दी, जो आगे चलकर GitHub तक पहुँची

Git commands और user tools का विकास

  • शुरुआती Git commands सभी low-level script-आधारित tools थे और आज के रूप से काफी अलग थे
  • git log, git rebase, git commit जैसे commands भी शुरुआत में साधारण shell scripts थे, और बाद में धीरे-धीरे विकसित होकर अपने मौजूदा रूप में पहुँचे

git log का शुरुआती संस्करण

  • git log एक साधारण script था, जिसका रूप git-rev-list --pretty HEAD | less जैसा था
  • rev-list एक ऐसा टूल है जो आज भी commit ID आउटपुट करने के लिए मौजूद है

git rebase का आगमन

  • rebase की अवधारणा 2005 में Linus और Junio Hamano के बीच email बातचीत से पैदा हुई
  • Junio का काम करने का तरीका यह था कि मौजूदा HEAD को छोड़कर नए HEAD के आधार पर काम जारी रखा जाए, और इसे "rebase" कहा गया
  • यही आगे चलकर आज के git rebase command में विकसित हुआ

Octocat की उत्पत्ति

  • GitHub का प्रतीक Octocat, Git की "octopus merge" strategy से प्रेरित है
  • कई branches को एक साथ merge करने की strategy को "octopus" कहा जाता था, और GitHub के शुरुआती दौर में इसी शब्द से प्रेरित होकर Octocat character बना

Git का वर्तमान और भविष्य

  • लेखक आज भी Git को उसके मूल उद्देश्य के अनुसार एक "stupid content tracker" की तरह इस्तेमाल करते हैं
  • GitButler project में Git का उपयोग project history को ट्रैक और रिकॉर्ड करने के लिए किया जा रहा है
  • Git आज भी एक शक्तिशाली content tracking और distributed system है, और आगे भी इसके अलग-अलग तरीकों से इस्तेमाल होने की संभावना है
  • जन्मदिन मुबारक हो, Git। अब भी अजीब, अब भी शानदार टूल

6 टिप्पणियां

 
aobamisaki 2025-04-13

Git के 20वें जन्मदिन की शुभकामनाएँ।

 
bobross0 2025-04-10

बधाई हो

 
girr311 2025-04-10

जन्मदिन मुबारक। बड़ों की बात मानो और लंबे समय तक स्वस्थ रहो।

 
kaistj 2025-04-09

जन्मदिन मुबारक हो ^^

 
crawler 2025-04-09

यह पोस्ट अजीब तरह से जोश भर देने वाली है।

 
GN⁺ 2025-04-09
Hacker News राय
  • Git की उत्पत्ति की कहानी में अक्सर Linus को किसी भविष्यवक्ता की तरह पेश किया जाता है

    • ब्लॉग पोस्ट Linus के मानवीय पक्ष पर ज़ोर देती है और शुरुआती trial-and-error का ज़िक्र करती है
    • Mercurial ने भी महत्वपूर्ण भूमिका निभाई, लेकिन उसे अक्सर नज़रअंदाज़ किया जाता है
    • Mercurial में शुरू से ही UI था, और Subversion जैसे UI की वजह से वह user-friendly था
    • Git की data structure बड़े files के लिए उपयुक्त नहीं है
    • मुझे नहीं लगता कि Git का आना अपरिहार्य था, और मैं उम्मीद करता हूँ कि नए विकल्प आएँ
  • 2002 के आसपास मेरे पास प्रोजेक्ट के हर हिस्से को एक unique hash code से tag करने का विचार था

    • मैंने इसे software companies को प्रस्तावित किया, लेकिन किसी ने रुचि नहीं दिखाई
  • मैंने Git को ClearCase के विकल्प के रूप में इस्तेमाल करना शुरू किया

    • 2007 के आसपास Git इस्तेमाल करना शुरू किया, और ClearCase की असुविधाओं को दूर करने के लिए scripts लिखीं
    • 2008 में Git के लिए patches देना शुरू किया, और open source contribution के बारे में बहुत कुछ सीखा
    • Git के जटिल CLI के बावजूद, इसे इस्तेमाल करने में मुझे कोई खास कठिनाई नहीं हुई
    • अगली नौकरी में मैंने Chromium के एक fork पर आधारित काम किया, और Git का उपयोग करके merge conflicts सुलझाने में निपुण हो गया
    • यह देखकर निराशा हुई कि GitHub, Git का मुख्य code review tool बन गया, लेकिन फिर भी मुझे लगता है कि Mercurial की तुलना में Git बेहतर विकल्प था
  • यह चौंकाने वाला है कि Git सिर्फ 20 साल पुराना है

    • GitHub का 20 साल से कम पुराना होना इतना हैरान नहीं करता, लेकिन यह कि Git 2005 से पहले मौजूद ही नहीं था, वाकई झटका देने वाला है
    • मैंने कभी कोई दूसरा source control option इस्तेमाल नहीं किया, और सोचता हूँ कि क्या आगे कभी करूँगा
  • ऐतिहासिक संदर्भ जानना दिलचस्प था

    • ClearCase भी "rebase" शब्द का इस्तेमाल करता था, और यह देखा जा सकता है कि यह 1999 से इस्तेमाल हो रहा था
    • ClearCase में rebase में बहुत समय लगता था, लेकिन Git का तुरंत होने वाला rebase चकित करने वाला था
  • मेरा इरादा एक efficient tarball history database tool बनाने का था, version control system बनाने का नहीं

  • मुझे पता चला कि commits को ssh key से sign किया जा सकता है

    • OpenBSD की समस्याएँ हल करने के लिए मैंने ssh signing का तरीका इस्तेमाल किया
    • CVS से Git में work items ले जाए हुए 20 साल हो गए हों, ऐसा लगता ही नहीं
  • उपयोगी लेख के लिए धन्यवाद, और Git की आंतरिक संरचना का परिचय देने वाली repository की सिफारिश करता हूँ

  • mailing list collaboration पर ब्लॉग पोस्ट लिखने की इच्छा वाली बात दिलचस्प लगी

  • कई source control systems में Git की usability सबसे खराब है, फिर भी यही मेरा पसंदीदा system है