Git — यह क्या है, काम करने के सिद्धांत और कमांड

Git क्या है?

Git एक वितरित संस्करण नियंत्रण प्रणाली (VCS) है जो फ़ाइलों में परिवर्तनों को ट्रैक करती है और कई डेवलपर्स को एक साथ एक ही प्रोजेक्ट पर काम करने की अनुमति देती है। केंद्रीकृत प्रणालियों के विपरीत, Git में प्रत्येक डेवलपर के पास संपूर्ण परिवर्तन इतिहास सहित रिपॉजिटरी की पूरी प्रतिलिपि होती है, जो सिस्टम को डेटा हानि के प्रति प्रतिरोधी बनाती है और केंद्रीय सर्वर से निरंतर कनेक्शन की आवश्यकता नहीं होती है।

Git का इतिहास 2005 में शुरू हुआ जब लिनस टॉर्वाल्ड्स ने BitKeeper द्वारा लिनक्स कर्नेल डेवलपर्स के लिए अपना मुफ़्त लाइसेंस रद्द करने के बाद एक नई VCS बनाई। लक्ष्य थे: गति, आर्किटेक्चर की सरलता, ब्रांचिंग के माध्यम से गैर-रेखीय डेवलपमेंट का समर्थन और पूर्ण वितरण। 3 महीने में टॉर्वाल्ड्स ने Git का कोर लिखा, और एक साल के भीतर परियोजना जूनियो हमानो के नेतृत्व में स्व-प्रबंधित हो गई।

Stack Overflow सर्वेक्षण (2024) के अनुसार, Git का उपयोग 93.9% पेशेवर डेवलपर्स द्वारा किया जाता है, जो इसे उद्योग में प्रमुख संस्करण नियंत्रण प्रणाली बनाता है। निकटतम प्रतिद्वंद्वी — Subversion (SVN) — का उपयोग केवल 5.2% परियोजनाओं में होता है, मुख्य रूप से केंद्रीकृत प्रक्रियाओं वाले बड़े कॉर्पोरेट वातावरण में।

Git कैसे काम करता है: रिपॉजिटरी और कमिट

Git रिपॉजिटरी एक निर्देशिका है जहाँ Git सभी फ़ाइलों में परिवर्तनों को ट्रैक करता है। निर्देशिका के अंदर एक छिपा हुआ फ़ोल्डर .git होता है जो सभी सिस्टम ऑब्जेक्ट्स: कमिट, ट्री, ब्लॉब और रेफरेंस संग्रहीत करता है। जब कोई डेवलपर कमिट बनाता है, Git फ़ाइलों को पूरी तरह से कॉपी नहीं करता — वह एक स्नैपशॉट बनाता है और उसका रेफरेंस सहेजता है।

प्रत्येक कमिट में शामिल होता है: एक अद्वितीय SHA-1 हैश (40 अक्षर), पिछले कमिट का रेफरेंस (parent), लेखक, तारीख, कमिट संदेश और एक ट्री का रेफरेंस जो कमिट के समय फ़ाइलों की स्थिति का वर्णन करता है। कमिट की श्रृंखला एक निर्देशित चक्रहीन ग्राफ़ बनाती है जहाँ प्रत्येक कमिट एक या अधिक पैरेंट की ओर इशारा करता है।

# रिपॉजिटरी आरंभीकरण
git init my-project
cd my-project

# कमिट बनाना
echo "नमस्ते, Git" > README.md
git add README.md
git commit -m "Initial commit"

# इतिहास देखना
git log --oneline --graph --all

Git तीन मुख्य क्षेत्रों का उपयोग करता है: working directory (डिस्क पर फ़ाइलें), staging area (इंडेक्स जहाँ तैयार फ़ाइलें जाती हैं) और repository (कमिट इतिहास)। git add कमांड वर्किंग डायरेक्टरी से स्टेजिंग में परिवर्तन ले जाता है, और git commit स्टेजिंग की सामग्री को रिपॉजिटरी में रिकॉर्ड करता है। यह अलगाव डेवलपर को प्रत्येक संपादन को अलग से कमिट किए बिना परिवर्तनों के सेट से एक सार्थक कमिट बनाने की अनुमति देता है।

Git के बुनियादी कमांड

Git के बुनियादी कमांड डेवलपर के दैनिक कार्यों के 90% को कवर करते हैं। git clone कमांड रिमोट रिपॉजिटरी की स्थानीय प्रतिलिपि बनाता है, git pull सर्वर से परिवर्तन लाकर उन्हें वर्तमान ब्रांच में मर्ज करता है, और git push स्थानीय कमिट को सर्वर पर भेजता है। ये तीन कमांड Git के साथ काम करने का मुख्य चक्र बनाते हैं।

स्थिति देखने के लिए git status का उपयोग किया जाता है — यह दिखाता है कि कौन सी फ़ाइलें संशोधित हैं, कौन सी स्टेजिंग में जोड़ी गई हैं और कौन सी अनट्रैक की गई हैं। git diff स्टेजिंग में जोड़ने से पहले फ़ाइलों में विशिष्ट परिवर्तन प्रदर्शित करता है। नीचे सबसे अधिक उपयोग किए जाने वाले कमांड की तालिका दी गई है:

परिवर्तनों को पूर्ववत करने के लिए, Git कई विकल्प प्रदान करता है। git reset ब्रांच पॉइंटर को निर्दिष्ट कमिट पर ले जाता है और स्टेजिंग या वर्किंग डायरेक्टरी को रीसेट कर सकता है। git revert एक नया कमिट बनाता है जो निर्दिष्ट कमिट के परिवर्तनों को पूर्ववत करता है — यह साझा ब्रांच के लिए पूर्ववत करने का एक सुरक्षित तरीका है क्योंकि इतिहास फिर से नहीं लिखा जाता है।

Git में ब्रांचिंग: main, feature और release

Git में ब्रांच एक विशिष्ट कमिट के लिए हल्के गतिशील पॉइंटर हैं। नई ब्रांच बनाने से फ़ाइलों की प्रतिलिपि नहीं बनती, बल्कि केवल एक नया पॉइंटर बनता है, जो ब्रांचिंग को लगभग तत्काल बनाता है। main ब्रांच (पहले master) परियोजना की मुख्य ब्रांच है जिसमें स्थिर, रिलीज़-रेडी कोड होता है।

मानक अभ्यास Git Flow या GitHub Flow का उपयोग करना है। Git Flow ब्रांच का उपयोग करता है: main (रिलीज़ कोड), develop (एकीकरण ब्रांच), feature/* (नई सुविधाएँ), release/* (रिलीज़ तैयारी) और hotfix/* (तत्काल सुधार)। GitHub Flow सरल है: केवल main और फ़ीचर ब्रांच, और सभी परिवर्तन Pull Request के माध्यम से वितरित किए जाते हैं।

# ब्रanche बनाना और स्विच करना
git branch feature-auth
git checkout feature-auth
# या एक कमांड के साथ:
git checkout -b feature-auth

# ब्रांच की सूची
git branch --list
git branch -a  # सभी शाखाएं, जिनमें दूरस्थ शाखाएं शामिल हैं

# ब्रांच हटाना
git branch -d feature-auth

Git ब्रांचिंग की एक महत्वपूर्ण विशेषता cherry-pick है: git cherry-pick <hash> कमांड का उपयोग करके एक व्यक्तिगत कमिट को एक ब्रांच से दूसरी में स्थानांतरित करना। यह तब उपयोगी होता है जब आपको पूरी ब्रांच को मर्ज किए बिना किसी फ़ीचर ब्रांच से रिलीज़ में बग फिक्स स्थानांतरित करने की आवश्यकता होती है। Git कमिट को स्क्वैश करने, पुनर्क्रमित करने और संपादित करने के लिए रीबेस और इंटरैक्टिव रीबेस (git rebase -i) का भी समर्थन करता है।

Merge और Rebase

Merge (मर्ज) एक विशेष मर्ज कमिट बनाता है जिसके दो पैरेंट होते हैं। यह कमिट दो ब्रांच के विलय के तथ्य को रिकॉर्ड करता है और पूर्ण इतिहास संरक्षित करता है — देखा जा सकता है कि मर्ज कहाँ और कब हुआ। Merge इतिहास को उसी रूप में संरक्षित करता है जिसमें इसे बनाया गया था, जो ऑडिट को सरल बनाता है लेकिन कमिट ग्राफ़ को अधिक जटिल बनाता है।

Rebase (रीबेस) मर्ज कमिट बनाने के बजाय वर्तमान ब्रांच के कमिट को लक्ष्य ब्रांच के शीर्ष पर स्थानांतरित करता है। इतिहास रैखिक हो जाता है — यह धारणा बनाता है कि डेवलपमेंट अनुक्रमिक था। हालाँकि, रीबेस इतिहास को फिर से लिखता है, कमिट के SHA-1 हैश बदलता है, जो इसे साझा ब्रांच के लिए खतरनाक बनाता है जहाँ अन्य डेवलपर्स की पहुँच होती है।

अनुशंसा: सार्वजनिक ब्रांच के लिए merge का उपयोग करें जहाँ इतिहास अन्य डेवलपर्स को दिखाई देता है (feature → develop), और स्थानीय कार्य के लिए rebase का उपयोग करें जब आप Pull Request बनाने से पहले अपनी फ़ीचर ब्रांच में main से नए परिवर्तन लागू करना चाहते हैं। नियम सरल है: यदि कमिट पहले ही सर्वर पर भेजा जा चुका है — तो उसे रीबेस न करें।

विरोधों का समाधान

मर्ज विरोध तब होता है जब Git एक फ़ाइल में परिवर्तनों को स्वचालित रूप से मर्ज नहीं कर सकता। Git फ़ाइल में विरोध वाले अनुभागों को विशेष मार्कर से चिह्नित करता है: <<<<<<< (हमारे परिवर्तन), ======= (विभाजक), >>>>>>> (उनके परिवर्तन)। डेवलपर मैन्युअल रूप से फ़ाइल संपादित करता है, वांछित विकल्प चुनता है या दोनों को जोड़ता है, और कमिट के साथ मर्ज पूरा करता है।

रिमोट रिपॉजिटरी के साथ काम करना

रिमोट रिपॉजिटरी (remote) सर्वर पर स्थित Git रिपॉजिटरी की एक प्रतिलिपि है। GitHub, GitLab और Bitbucket रिमोट रिपॉजिटरी होस्ट करने के लिए सबसे लोकप्रिय प्लेटफ़ॉर्म हैं। वे कोड देखने, पहुँच प्रबंधन, कोड समीक्षा और CI/CD सिस्टम के साथ एकीकरण के लिए वेब इंटरफ़ेस प्रदान करते हैं।

Git में, आप एक प्रोजेक्ट के लिए कई रिमोट रिपॉजिटरी कॉन्फ़िगर कर सकते हैं। डिफ़ॉल्ट रूप से, मुख्य रिमोट को origin कहा जाता है। git remote add कमांड एक नया रिमोट जोड़ता है, git fetch बिना मर्ज किए परिवर्तन लाता है, और git pull git fetch + git merge का संक्षिप्त रूप है। Pull Request के माध्यम से कोड के साथ काम करने के लिए, एक डेवलपर रिपॉजिटरी का फ़ोर्क बनाता है, उसे क्लोन करता है, फ़ीचर ब्रांच में काम करता है, और मूल रिपॉजिटरी में मर्ज अनुरोध भेजता है।

# रिमोट रिपॉजिटरी जोड़ना
git remote add origin https://github.com/user/repo.git

# रिमोट रिपॉजिटरी देखना
git remote -v

# सर्वर पर ब्रांच भेजना
git push -u origin feature-auth

# रिमोट ब्रांच से परिवर्तन लाना
git pull origin main

रिमोट रिपॉजिटरी रिलीज़ संस्करणों को चिह्नित करने के लिए टैगिंग का समर्थन करती हैं। टैग हल्के (केवल कमिट की ओर इशारा) या एनोटेटेड (मेटाडेटा: लेखक, तारीख, संदेश) हो सकते हैं। रिलीज़ संस्करणों के लिए एनोटेटेड टैग की सिफारिश की जाती है क्योंकि वे पूर्ण संस्करण जानकारी रखते हैं और लेखकत्व के सत्यापन के लिए GPG कुंजी से हस्ताक्षरित किए जा सकते हैं।

समानांतर कार्य के लिए Git Worktree

Git Worktree आपको उनके बीच स्विच किए बिना विभिन्न निर्देशिकाओं में एक साथ कई ब्रांच के साथ काम करने की अनुमति देता है। git worktree add ../feature-auth feature-auth कमांड एक नई वर्किंग डायरेक्टरी feature-auth बनाता है जहाँ आप मुख्य निर्देशिका में ब्रांच स्विच किए बिना कोड लिख सकते हैं। Worktree रिलीज़ ब्रांच में त्वरित सुधार के लिए उपयोगी है जब मुख्य निर्देशिका दीर्घकालिक डेवलपमेंट में व्यस्त हो।

निर्भरता के लिए Git Submodules

Git Submodules एक Git रिपॉजिटरी को दूसरे के अंदर शामिल करने का एक तंत्र है। Submodule बाहरी रिपॉजिटरी के एक निश्चित कमिट का रेफरेंस संग्रहीत करता है, जो बिल्ड पुनरुत्पादन क्षमता सुनिश्चित करता है। git submodule add https://github.com/example/lib.git कमांड बाहरी लाइब्रेरी को सबमॉड्यूल के रूप में जोड़ता है। सबमॉड्यूल वाले प्रोजेक्ट को क्लोन करते समय, सभी निर्भरताएँ डाउनलोड करने के लिए git submodule update --init --recursive निष्पादित करना आवश्यक है।