Git क्या है?

docs.scrimba.com

आप लगभग निश्चित रूप से हाथ से संस्करण नियंत्रण कर चुके होंगे। एक फ़ोल्डर जिसमें report.docx, report_final.docx, report_final_v2.docx, और report_final_ACTUAL.docx है, यह संस्करण नियंत्रण है, सबसे बुरे संभावित तरीके का। आप यह नहीं बता सकते कि इन दोनों फ़ाइलों के बीच क्या बदला, आप दो लोगों द्वारा एक ही समय में किए गए संपादन को मर्ज नहीं कर सकते, और आप निश्चित रूप से उस अच्छे पैराग्राफ को वापस नहीं ला सकते जिसे आपने तीन प्रतियां पहले हटाया था।

Git इस समस्या को सही तरीके से हल करता है। यह एक ऐसा उपकरण है जो समय के साथ आपकी परियोजना के स्नैपशॉट रिकॉर्ड करता है, इसलिए आपका पूरा इतिहास एक जगह पर रहता है बजाय प्रतियों के ढेर के। यह उपकरण एक छोटा प्रोग्राम है जो आपके अपने कंप्यूटर पर रहता है: आप टर्मिनल में git से शुरू होने वाली कमांड टाइप करते हैं, और यह पाठ में उत्तर देता है।

Git आपके लिए क्या करता है

मूल रूप से, Git आपकी परियोजना का एक समयरेखा रखता है। हर बार जब आप सहेजने के योग्य किसी बिंदु तक पहुंचते हैं, तो आप एक commit रिकॉर्ड करते हैं: हर फ़ाइल का एक स्नैपशॉट, साथ ही एक छोटा संदेश जो बताता है कि क्या बदला और क्यों। बाद में आप उस समयरेखा पर वापस देख सकते हैं और देख सकते हैं कि परियोजना वहां कैसे पहुंची। यहाँ एक वास्तविक समयरेखा है, git log द्वारा मुद्रित, जो कमांड है जो एक परियोजना की commits को सूचीबद्ध करता है (--oneline flag प्रत्येक को एक लाइन तक छोटा करता है):

$ git log --oneline
a1b2c3d Add password strength meter
9f8e7d6 Fix signup form validation
5c4b3a2 Set up project structure

ये एक परियोजना के इतिहास में तीन सहेजे गए बिंदु हैं, शीर्ष पर सबसे नए, प्रत्येक के साथ एक छोटा ID और इसके लेखक द्वारा लिखा संदेश। (इस जैसे हर उदाहरण में, $ से शुरू होने वाली लाइन एक टर्मिनल में टाइप की गई कमांड है, $ स्वयं को छोड़कर, और नीचे की लाइनें Git की प्रतिक्रिया हैं।) आप अगले कुछ अध्यायों में हर कमांड सीखेंगे जो इस इतिहास को बनाती और पढ़ती है। अभी के लिए विचार यह है कि Git आपके काम को स्नैपशॉट की एक श्रृंखला के रूप में रिकॉर्ड कर रहा है जिस पर आप हमेशा वापस जा सकते हैं।

एक बार जब आपकी परियोजना के पास इस तरह का इतिहास होता है, तो बहुत कुछ संभव हो जाता है। आप देख सकते हैं कि क्या बदला और किसने बदला। आप किसी जोखिम भरे विचार को अलग से आज़मा सकते हैं और यदि यह काम नहीं करता है तो इसे साफ तरीके से फेंक सकते हैं। आप पूरी परियोजना, इसके पूरे इतिहास के साथ, किसी और को सौंप सकते हैं। और जब दो लोग एक ही कोड को संपादित करते हैं, तो Git उनके काम को जोड़ सकता है और उन स्थानों को चिह्नित कर सकता है जहां वे असहमत हैं ताकि कोई इंसान उन्हें हल कर सके। ये चार क्षमताएं, इतिहास, सुरक्षित प्रयोग, साझाकरण, और काम को जोड़ना, वह पूरा कारण हैं कि Git लगभग हर पेशेवर codebase के तहत चलता है।

व्यावहारिक रूप से एक टीम उस समयरेखा पर लगातार निर्भर रहती है। किसी भी आकार का हर परिवर्तन अपनी स्वयं की branch पर शुरू होता है, इतिहास की एक अलग लाइन जहां आप मुख्य कोड को परेशान किए बिना काम कर सकते हैं। जब परिवर्तन तैयार हो जाता है, तो कोई इसकी समीक्षा करता है, और फिर इसे मुख्य branch में मर्ज किया जाता है। समीक्षा, branching, और merging Git में काम करने की दैनिक लय है, और वे सभी ऊपर दिए गए स्नैपशॉट समयरेखा पर निर्भर करते हैं। यह handbook का बाकी हिस्सा उस लय के प्रत्येक टुकड़े को उस क्रम में चलाता है जिसमें आप इसका सामना करते हैं।

एक विवरण बाद में सब कुछ के लिए महत्वपूर्ण है: हर commit आपकी tracked files की पूरी स्थिति को संग्रहीत करता है, उस पल का एक पूर्ण स्नैपशॉट। लोग अक्सर Git को केवल संस्करणों के बीच अंतर सहेजने की कल्पना करते हैं, लेकिन हुड के तहत हर commit पूरी परियोजना रखता है। Git इसे सस्ता रखता है प्रत्येक अद्वितीय फ़ाइल सामग्री को एक बार संग्रहीत करके, इसलिए एक commit जो एक अपरिवर्तित फ़ाइल को फिर से उपयोग करता है केवल पहले से सहेजी गई copy को इंगित करता है, और एक हजार फ़ाइलों का एक स्नैपशॉट जहां एक बदल गया है अन्य 999 को डुप्लिकेट नहीं करता है। हर commit उस commit का ID भी रिकॉर्ड करता है जो इससे पहले आया था, इसका parent, जो है कि Git स्नैपशॉट को एक इतिहास में कैसे जोड़ता है जिसे वह पिछड़ी ओर चल सकता है। वह parent link लगभग हर चीज की रीढ़ है: branches, merges, और history browsing सभी इन pointers को follow करने पर बनी हैं। आप History और Branches अध्यायों में पूरे object model को देखेंगे।

JunoGit आपके लिए क्या करता है Git आपकी परियोजना को commits नामक स्नैपशॉट की एक श्रृंखला के रूप में रिकॉर्ड करता है, प्रत्येक के साथ एक संदेश जो कहता है कि क्या बदला। एक बार जब वह इतिहास मौजूद होता है तो आप इसके ऊपर देख सकते हैं, सुरक्षित रूप से प्रयोग कर सकते हैं, इसे साझा कर सकते हैं, और अन्य लोगों के साथ काम को जोड़ सकते हैं। final_v2_ACTUAL प्रतियों का ढेर वह समस्या है जिसे Git खत्म करने के लिए बनाया गया था, और मैं वादा करता हूं कि पहली बार जब आप एक को हटाते हैं तो यह शानदार महसूस होता है।

JunoGit आपके लिए क्या करता है एक commit एक स्नैपशॉट और एक संदेश है, और इतिहास उनकी एक समयरेखा है। दिन-प्रतिदिन आप उस समयरेखा से एक परिवर्तन करने के लिए branch बनाते हैं, इसे समीक्षा के लिए प्राप्त करते हैं, और इसे वापस मर्ज करते हैं। स्नैपशॉट के बढ़ते समयरेखा का मानसिक मॉडल अपने सिर में रखें; आप जो हर कमांड सीखते हैं वह या तो इसमें जोड़ रहा है या इससे पढ़ रहा है।

JunoGit आपके लिए क्या करता है हर commit पूरी परियोजना स्थिति को संग्रहीत करता है और अपने parent को इंगित करता है, जो है कि Git इतिहास को कैसे चलाता है। समान फ़ाइल सामग्री एक बार संग्रहीत की जाती है और commits के बीच साझा की जाती है, इसलिए स्नैपशॉट सस्ते रहते हैं। parent-pointer विचार को पकड़ें, क्योंकि branches और merges एक ही विचार है जो विभिन्न मुखौटे पहन रहा है।

Git और GitHub अलग-अलग चीजें हैं

यह शुरुआत में लगभग हर किसी को भ्रमित करता है, इसलिए यहाँ यह स्पष्ट शब्दों में है। Git संस्करण-नियंत्रण उपकरण है। यह आपके अपने कंप्यूटर पर चलता है, यह आपकी commits को रिकॉर्ड करता है, और इसे काम करने के लिए कोई internet कनेक्शन और कोई खाता नहीं चाहिए। GitHub एक वेबसाइट है जो Git repositories को online संग्रहीत करता है और उनके चारों ओर चीजें जोड़ता है: अपना कोड साझा करने, एक-दूसरे के परिवर्तनों की समीक्षा करने, समस्याओं की रिपोर्ट करने, और सहयोग करने के लिए एक जगह।

अंतर को महसूस करने का सबसे स्पष्ट तरीका: आप हर दिन Git का उपयोग कर सकते हैं, अपने laptop पर committing और branching कर सकते हैं, कभी भी एक GitHub खाता बनाए बिना। GitHub केवल तभी चित्र में आता है जब आप अपनी repository को कहीं साझा स्थान पर रखना चाहते हैं ताकि अन्य लोग, या अन्य मशीनें, इसे पहुंच सकें। Git इंजन है; GitHub एक जगह है जहां इसकी पैदावार को host करते हैं। अन्य मौजूद हैं, जैसे GitLab और Bitbucket, और वे सभी नीचे एक ही Git repositories को host करते हैं।

दोनों एक-दूसरे में धुंधले होने का कारण यह है कि अधिकांश लोग Git और GitHub को एक ही समय में मिलते हैं, अपने पहले दिन GitHub से एक परियोजना को clone करते हुए। बहुत से लोग सोचकर दूर जाते हैं कि git push का मतलब "GitHub को भेजें" है, जबकि इसका वास्तव में मतलब है "जो भी remote आपने कॉन्फ़िगर किया है उसे भेजें", और वह remote अधिकांश समय GitHub होता है। अपने सिर में दोनों को अलग रखना तब भुगतान करता है जब आप पहली बार Git को एक अलग host के साथ उपयोग करते हैं, या कोई host बिल्कुल नहीं।

JunoGit और GitHub अलग-अलग चीजें हैं Git आपके कंप्यूटर पर एक उपकरण है जो आपकी commits को रिकॉर्ड करता है। GitHub एक वेबसाइट है जो Git projects को online संग्रहीत करता है ताकि लोग उन्हें साझा और समीक्षा कर सकें। आप Git को बिना किसी GitHub खाते के उपयोग कर सकते हैं। अगर आप इस पृष्ठ से एक चीज को याद रखते हैं, तो यह बनाएं, क्योंकि उन्हें मिलाना शुरुआत में बहुत भ्रम पैदा करता है।

JunoGit और GitHub अलग-अलग चीजें हैं Git आपके मशीन पर संस्करण-नियंत्रण इंजन है; GitHub GitLab और Bitbucket के साथ इसकी पैदावार को host करने के लिए एक लोकप्रिय जगह है। git push जो भी remote आपने सेट किया है उसे भेजता है, जो आमतौर पर आदत से GitHub होता है। विभाजन को रखें और आप भ्रमित नहीं होंगे जब कोई परियोजना कहीं और रहती है।

JunoGit और GitHub अलग-अलग चीजें हैं Git commits, branches, और refs के बारे में जानता है; GitHub एक hosted copy के ऊपर pull requests, issues, और merge button को layer करता है। कुछ भी GitHub जोड़ता है एक Git कमांड नहीं है, इसी लिए आप एक वेबसाइट पर pull request खोलते हैं और कभी git के साथ नहीं। दोनों को अपने सिर में अलग रखें और ज्यादातर चीजें जो GitHub magic की तरह दिखती हैं वे सादे refs में वापस आ जाती हैं।

Git कहाँ से आया

Git का इतिहास बहुत कुछ समझाता है कि यह क्यों इस तरह काम करता है। इसे 2005 में Linus Torvalds द्वारा लिखा गया था, वही व्यक्ति जिसने Linux शुरू किया था। Linux kernel हजारों volunteers द्वारा दुनिया भर में बिखरे हुए द्वारा बनाया जाता है, और कुछ सालों के लिए उन्होंने एक commercial tool BitKeeper नामक का उपयोग करके सभी काम को समन्वित किया था, जिसे इसके पीछे की कंपनी open-source projects को मुक्त में उपयोग करने देती थी।

2005 में वह मुक्त व्यवस्था टूट गई, और kernel community के पास अचानक अपने विशाल, तेजी से चलने वाले codebase को प्रबंधित करने का कोई उपकरण नहीं था। उस समय कुछ भी उपलब्ध नहीं रखा जा सकता था। तो Torvalds ने kernel काम से कुछ हफ्तों के लिए पीछे हटते हुए अपना स्वयं का संस्करण-नियंत्रण उपकरण लिखा, बिल्कुल उसी समस्या द्वारा आकार दिए गए कुछ दृढ़ लक्ष्यों के साथ।

वह चाहते थे कि यह distributed हो, ताकि हर योगदानकर्ता के पास अपनी मशीन पर पूरी परियोजना का इतिहास हो और एक केंद्रीय सर्वर के साथ जांच किए बिना काम कर सके। वह चाहते थे कि यह fast हो, kernel के आकार की परियोजना को संभालने के लिए काफी तेज़ ताकि लोगों को इंतज़ार न करना पड़े। और वह चाहते थे कि यह integrity की गारंटी दे, ताकि कोई भी चुपचाप इतिहास को बदल न सकता और कोई disk error परियोजना को ख़राब न कर सकता बिना इसे देखे।

ये लक्ष्य हैं कि Git आज क्यों इस तरह व्यवहार करता है। जब आप एक परियोजना को clone करते हैं तो आप इसके पूरे इतिहास को काम करने के लिए पाते हैं, जो distributed लक्ष्य कार्य में है: आप कोई wifi के बिना एक विमान पर commit, branch, और browse history कर सकते हैं। और हर commit को एक fingerprint के साथ stamped किया जाता है जो इसकी सटीक सामग्री से परिकलित होता है, इसलिए अगर एक single byte कभी बदलता है तो fingerprint मेल खाना बंद करता है और Git देखता है। Design decisions जो Torvalds ने 2005 में जल्दबाजी में किए थे वे हैं जिन पर आप हर बार Git का उपयोग करते हैं।

Integrity guarantee पूरे डिज़ाइन को चलाता है। हर commit एक hash द्वारा identified होता है, एक fixed-length fingerprint जो commit की पूरी सामग्री से compute किया जाता है, जिसमें इसके parent का ID भी शामिल है। क्योंकि parent का ID child के hash में feeds होता है, hashes एक chain बनाते हैं: एक पुरानी commit में कुछ भी बदलें और इसका hash बदल जाता है, जो इसके बाद हर commit के hash को बदल देता है। यह है कि Git इतिहास को tamper-evident बनाता है। इसका मतलब यह भी है कि एक commit का ID इसकी सटीक सामग्री का एक fingerprint है, जो है कि आप a1b2c3d जैसे hex की उन तारों को देखते हैं बजाय एक orderly commit number 42 के।

JunoGit कहाँ से आया Linus Torvalds ने 2005 में Linux kernel के लिए Git लिखा था, जब परियोजना जो उपयोग कर रही थी वह उपकरण मुक्त होना बंद हो गया। उसने इसे distributed, fast, और corruption के खिलाफ सुरक्षित होने के लिए बनाया। यह है कि clone आपको offline काम करने के लिए पूरा इतिहास देता है, और क्यों हर commit को एक fingerprint मिलता है। एक उपकरण के लिए उपयोगी संदर्भ जिसे आप वर्षों तक उपयोग करेंगे।

JunoGit कहाँ से आया Git 2005 में Linux kernel से निकला था, हजारों योगदानकर्ताओं के लिए कोई केंद्रीय सर्वर के बिना बनाया गया था, जो है कि इसका पूरा मॉडल distributed क्यों है। हर clone पूरा इतिहास carries करता है, इसलिए आप locally branch और commit करते हैं और sync करते हैं जब आप चुनते हैं। जब एक Git default अजीब महसूस होता है, "यह kernel के लिए डिज़ाइन किया गया था" आमतौर पर इसे समझाता है।

JunoGit कहाँ से आया Git 2005 में Torvalds द्वारा एक दो-सप्ताह की sprint से निकला था जब kernel को BitKeeper तक access खो गया, तीन लक्ष्यों के साथ: distributed, fast, integrity-checked। हर commit का hash इसकी सामग्री और इसके parent के hash से compute किया जाता है, इसलिए IDs एक tamper-evident chain बनाते हैं। जब आप सोचते हैं कि Git ने कुछ choice क्यों किया, "यह Linux kernel के लिए बनाया गया था" आमतौर पर उत्तर है।

यह handbook अगले कहाँ जाता है

Mental model के साथ, बाकी track काम के बारे में है। Your first repository शून्य से शुरू होता है: एक terminal खोलना, Git को install करना अगर आपकी मशीन के पास नहीं है, और एक फ़ोल्डर को एक repository में बदलना जिसे आप commit कर सकते हैं। वहाँ से आप परिवर्तन को सहेजने, फिर branches, merging, और GitHub पर collaboration flow की रोज़मर्रा की लय सीखेंगे। अगर कोई term कभी आपको खो देता है, तो Glossary में इन docs में Git vocabulary का हर टुकड़ा के लिए एक संक्षिप्त परिभाषा है।