पुश करना — यह क्या है, git push कैसे काम करता है और कब ज़रूरी है

Git में पुश क्या है

Git push एक कमांड है जो लोकल रिपॉजिटरी से रिमोट रिपॉजिटरी में कमिट्स ट्रांसफर करता है। commit के विपरीत, जो चेंजेज़ को केवल डेवलपर की लोकल मशीन पर सेव करता है, पुश उन चेंजेज़ को पूरी टीम के लिए प्रकाशित करता है। Push Pull Request बनाने और डिप्लॉयमेंट से पहले एक अनिवार्य कदम है।

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

# origin remote, main ब्रांच में पुश करें
git push origin main

# वर्तमान ब्रांच को upstream के साथ remote में पुश करें
git push -u origin feature/new-dashboard

# मिलान वाले नामों वाली सभी ब्रांच पुश करें
git push --all origin

# लीज़ के साथ फ़ोर्स पुश (सुरक्षित फ़ोर्स पुश)
git push --force-with-lease

पुश करने के बाद, रिमोट रिपॉजिटरी रेफ्स (ब्रांच रेफरेंस) को अपडेट करती है ताकि वे नए कमिट्स की ओर इशारा करें। अन्य डेवलपर git pull या git fetch के माध्यम से इन चेंजेज़ को प्राप्त कर सकते हैं। कमिट्स का यह आदान-प्रदान सहयोगी डेवलपमेंट का आधार बनता है।

git push कैसे काम करता है

git push कमांड लोकल और रिमोट ब्रांच की तुलना करता है और केवल गुम कमिट्स को ट्रांसफर करता है। Git सभी फ़ाइलों को फिर से नहीं भेजता — वह केवल डेल्टा ट्रांसफर करता है, जो बड़ी रिपॉजिटरी के लिए भी पुश को तेज़ बनाता है। Git प्रोटोकॉल स्मार्ट ट्रांसफर का उपयोग करता है, जो ट्रांसमिटेड डेटा की मात्रा को कम करता है।

यदि रिमोट ब्रांच में ऐसे कमिट्स हैं जो लोकल रूप से मौजूद नहीं हैं, तो पुश अस्वीकार कर दिया जाएगा। यह एक सुरक्षात्मक तंत्र है जो चेंजेज़ के नुकसान को रोकता है। ऐसी स्थिति में, डेवलपर को पहले git pull चलाना चाहिए, चेंजेज़ को मर्ज करना चाहिए और उसके बाद ही फिर से पुश करना चाहिए। एक विकल्प फ़ोर्स पुश है, जो रिमोट ब्रांच को ओवरराइट करता है, लेकिन इसका उपयोग सावधानी से किया जाना चाहिए।

रिमोट रिपॉजिटरी को समझना सही पुश की कुंजी है। आमतौर पर, origin डिफ़ॉल्ट रिमोट रिपॉजिटरी का नाम है। git remote -v कमांड रिमोट रिपॉजिटरी और उनके URL की सूची दिखाता है। आप कई रिमोट जोड़ सकते हैं (उदाहरण के लिए, मुख्य रिपॉजिटरी के लिए origin और फ़ोर्क के लिए upstream)।

कब चेंजेज़ पुश करने चाहिए

मुख्य नियम: काम के प्रत्येक तार्किक रूप से पूर्ण चरण के बाद पुश करें। यदि डेवलपर ने कोई कार्य या उसका हिस्सा पूरा कर लिया है — तो पुश करने का समय आ गया है। हालांकि, अधूरे काम को पुश करना जो बिल्ड को तोड़ता है, अनुशंसित नहीं है। बिल्ड न टूटा हो किसी भी ब्रांच में पुश करने के लिए न्यूनतम आवश्यकता है।

टीम डेवलपमेंट में निम्नलिखित लय अपनाई जाती है: सुबह — सहकर्मियों के चेंजेज़ प्राप्त करने के लिए git pull, दिन में — कई कमिट्स और एक या दो पुश, शाम — सभी पूर्ण कार्यों का अंतिम पुश। डेवलपर जितनी बार पुश करता है, मर्ज टकराव का जोखिम उतना ही कम होता है और काम की प्रगति उतनी ही पारदर्शी होती है।

• कार्य पूरा करने के बाद — कमिट करें और फ़ीचर ब्रांच में अंतिम समाधान पुश करें
• जाने से पहले — अधूरे काम को फ़ीचर ब्रांच में पुश करें (main में नहीं!)
• PR बनाने से पहले — सुनिश्चित करें कि सभी कमिट्स पुश हो गए हैं और समीक्षा के लिए उपलब्ध हैं
• रीबेस करने के बाद --force-with-lease के साथ अपनी फ़ीचर ब्रांच में पुश करें

सुरक्षित पुश के नियम

सुरक्षित पुश नियमों का एक सेट है जो डेटा हानि और टीम में टकराव को रोकता है। पहला और सबसे महत्वपूर्ण नियम: कभी भी सीधे main या master ब्रांच में पुश न करें यदि प्रोजेक्ट में सीधा डिप्लॉयमेंट कॉन्फ़िगर नहीं किया गया है। आधुनिक टीमों में, main ब्रांच की सुरक्षा GitHub ब्रांच प्रोटेक्शन स्तर पर कॉन्फ़िगर की जाती है।

दूसरा नियम: पुश करने से पहले रिमोट ब्रांच के साथ सिंक्रोनाइज़ करें। मर्ज करते समय मर्ज कमिट से बचने के लिए git pull --rebase चलाएँ। यह हिस्ट्री को सरल और रैखिक बनाता है। यदि पुश अस्वीकार हो जाता है — तो सीधे फ़ोर्स पुश का उपयोग न करें, बल्कि पहले पता करें कि रिमोट ब्रांच पर कौन से कमिट्स आए हैं।

तीसरा नियम: प्री-पुश हुक सेट अप करें जो भेजने से पहले स्वचालित रूप से टेस्ट और लिंटर चलाएँ। यदि टेस्ट विफल होते हैं — तो पुश ब्लॉक हो जाता है। ऐसे हुक Husky या Git हुक (pre-push फ़ाइल .git/hooks में) के माध्यम से कॉन्फ़िगर किए जाते हैं।

चौथा नियम: बड़ी बाइनरी फ़ाइलों को पुश न करें। Git बाइनरी आर्टिफैक्ट्स को स्टोर करने के लिए डिज़ाइन नहीं किया गया है — वे रिपॉजिटरी को बढ़ाते हैं और संचालन को धीमा करते हैं। बड़ी फ़ाइलों के लिए, Git LFS (Large File Storage) का उपयोग करें। यदि कोई बाइनरी पहले ही पुश हो चुकी है और हिस्ट्री में है, तो उसे git filter-branch के माध्यम से हटाया जाना चाहिए।

अगर पुश विफल हो जाए तो क्या करें

पुश विफल होने का सबसे आम कारण यह है कि रिमोट ब्रांच में ऐसे कमिट्स हैं जो लोकल रूप से मौजूद नहीं हैं। ऐसा तब होता है जब किसी अन्य डेवलपर ने अपने चेंजेज़ उसी ब्रांच में पुश किए हों। समाधान: git pull चलाएँ, किसी भी टकराव को हल करें और फिर से पुश करें।

# पुश अस्वीकार — पहले fetch और rebase करें
git fetch origin
git rebase origin/main
# टकराव हल करें, फिर:
git push --force-with-lease

# या बस रिमोट चेंजेज़ मर्ज करें
git pull origin main
git push

दूसरा कारण — ब्रांच पर लिखने की अनुमति का अभाव। यदि main ब्रांच ब्रांच प्रोटेक्शन नियमों द्वारा संरक्षित है, तो सीधे पुश निषिद्ध हैं। समाधान: फ़ीचर ब्रांच में पुश करें और Pull Request बनाएँ। सुरक्षा सेटिंग्स आमतौर पर GitHub सेटिंग्स या GitLab संरक्षित ब्रांच के माध्यम से प्रशासित की जाती हैं।

तीसरा कारण — प्रमाणीकरण समस्याएँ। पुरानी क्रेडेंशियल्स, SSH पर स्विच करना या पर्सनल एक्सेस टोकन बदलना। समाधान: रिमोट URL (git remote -v) जाँचें और क्रेडेंशियल्स अपडेट करें। 2021 से, GitHub ने HTTPS के लिए पासवर्ड प्रमाणीकरण बंद कर दिया है — पर्सनल टोकन या SSH कुंजी का उपयोग करें।