गिट पुश अस्वीकृत नॉन-फ़ास्ट-फ़ॉरवर्ड त्रुटि को कैसे ठीक करें

त्रुटिअपडेट अस्वीकार कर दिए गए क्योंकि रिमोट में वह कार्य है जो आपके पास स्थानीय स्तर पर नहीं है (एक नॉन-फ़ास्ट-फ़ॉरवर्ड त्रुटि) का अर्थ है कि किसी ने कमिट को उस दूरस्थ शाखा में धकेल दिया है जो आपके पास नहीं है। Git उनके काम को ओवरराइट करने से रोकने के लिए आपके पुश को ब्लॉक कर देता है। यहां बताया गया है कि इसे सुरक्षित तरीके से कैसे हल किया जाए।

इस त्रुटि का क्या अर्थ है

$ git push origin main
 ! [rejected]        main -> main (non-fast-forward)
error: failed to push some refs to 'origin'
hint: Updates were rejected because the remote contains work that
hint: you do not have locally. This is usually caused by another
hint: repository pushing to the same ref.

आपके अंतिम बार खींचने के बाद किसी ने (या किसी अन्य मशीन से आपने) कमिट को दूरस्थ शाखा में धकेल दिया। आपकी स्थानीय शाखा और रिमोट अलग हो गए हैं। Git आपको आगे बढ़ने नहीं देगा क्योंकि यह उनकी प्रतिबद्धताओं को खारिज कर देगा।

समाधान 1: खींचो, फिर दबाओ (विलय)

# Fetch and merge the remote changes into your local branch
git pull origin main

# This creates a merge commit combining their work and yours.
# Resolve any conflicts if they occur, then:
git push origin main

यह सुरक्षित डिफ़ॉल्ट है. यह मर्ज कमिट के माध्यम से रिमोट कमिट को आपके साथ एकीकृत करता है, फिर आपका पुश सफल होता है।

फिक्स 2: रिबेस के साथ खींचें (क्लीनर इतिहास)

# Replay YOUR commits on top of the remote's - linear history, no merge commit
git pull --rebase origin main

# If conflicts occur during rebase, resolve them, then:
git add 
git rebase --continue

# Then push
git push origin main

रीबेसिंग मर्ज कमिट के बिना एक साफ़, रैखिक इतिहास देता है। कई टीमें इसे पसंद करती हैं. आपके कमिट नवीनतम दूरस्थ कार्य के शीर्ष पर पुनः चलाए जाते हैं।

समाधान 3: पहले प्राप्त करें और समीक्षा करें (सावधानीपूर्वक दृष्टिकोण)

# See what's on the remote before integrating
git fetch origin

# Compare your branch with the remote
git log HEAD..origin/main    # commits on remote you don't have
git log origin/main..HEAD    # your commits not on remote

# Then choose to merge or rebase
git merge origin/main        # or: git rebase origin/main
git push origin main

एक डिफ़ॉल्ट पुल रणनीति सेट करें

# Configure how git pull behaves (avoids the "divergent branches" warning)

# Merge (default) - creates merge commits
git config --global pull.rebase false

# Rebase - linear history
git config --global pull.rebase true

# Fast-forward only - fail if not possible (forces you to decide)
git config --global pull.ff only

जब आप आश्वस्त हों कि आप ओवरराइट करना चाहते हैं (खतरनाक)

# ⚠️ ONLY if you're certain the remote commits should be discarded
# (e.g., your own feature branch nobody else uses)

# --force-with-lease is safer than --force:
# it fails if the remote changed since your last fetch
git push --force-with-lease origin my-feature-branch

# ❌ NEVER force push to shared branches (main, develop)
# It permanently deletes other people's commits
git push --force origin main   # DON'T do this on shared branches

चेतावनी: किसी साझा शाखा में जबरदस्ती धकेलना अन्य लोगों की प्रतिबद्धताओं को नष्ट कर देता है। केवल अपनी स्वयं की फीचर शाखाओं पर बलपूर्वक धक्का दें, जिन पर कोई और काम नहीं करता है, और--force-with-lease.

को प्राथमिकता देते हैं अंतर को समझना

# Before: your local and remote have diverged
#   A---B---C (your local main)
#        #         D---E (remote main - someone else's commits)

# git pull (merge) creates:
#   A---B---C---F (merge commit)
#        \     /
#         D---E

# git pull --rebase creates (cleaner):
#   A---B---D---E---C' (your C replayed on top)

अक्सर पूछे जाने वाले प्रश्न

प्रश्न: क्या मुझे इसे ठीक करने के लिए विलय या पुनः आधार बनाना चाहिए?
उ: मर्ज (गिट पुल) सुरक्षित डिफ़ॉल्ट है और सटीक इतिहास को सुरक्षित रखता है। रीबेस (गिट पुल –रीबेस) स्वच्छ रैखिक इतिहास देता है। साझा शाखाओं के लिए, या तो काम करता है; पीआर से पहले आपकी अपनी फीचर शाखाओं के लिए, रीबेस इतिहास को साफ-सुथरा रखता है। अपनी टीम की परंपरा का पालन करें.

प्रश्न: मैं केवल बलपूर्वक धक्का क्यों नहीं दे सकता?
उ: किसी साझा शाखा पर बलपूर्वक दबाव डालने से दूसरों द्वारा किए गए कमिट स्थायी रूप से हटा दिए जाते हैं – आप उनका काम खो देंगे। केवल अपनी स्वयं की फीचर शाखाओं पर बलपूर्वक पुश (–फोर्स-विद-लीज के साथ) करें जिसका उपयोग कोई और नहीं करता है। कभी भी जबरदस्ती पुश मेन या डेवलप न करें।

प्रश्न: –force-with-lease क्या करता है जो –force नहीं करता है?
A: --force-with-lease जाँचता है कि आपके अंतिम फ़ेच के बाद से रिमोट नहीं बदला है – यदि इस बीच किसी ने धक्का दिया, तो यह ओवरराइट करने के बजाय विफल हो जाता है। यह एक सुरक्षा जाल है जो उन कमिटों को गलती से नष्ट होने से रोकता है जिन्हें आपने नहीं देखा है। हमेशा सादे-बल की अपेक्षा इसे प्राथमिकता दें।

प्रश्न: खींचने के बाद मुझे मर्ज विरोध का सामना करना पड़ा। अब क्या?
उ: विवादित फ़ाइलें खोलें, विवादों का समाधान करें (चुनें कि कौन सा परिवर्तन रखना है), फिरgit add हल की गई फ़ाइलें। मर्ज के लिए,git commit. रिबेस के लिए,git rebase --continue. फिर धक्का.

प्रश्न: मैं भविष्य में इस त्रुटि से कैसे बचूँ?
उत्तर: काम शुरू करने से पहले और धक्का देने से पहले खींच लें। अपनी टीम से इस बारे में संवाद करें कि कौन किस पर काम कर रहा है। सक्रिय साझा शाखाओं पर, चालू रहने और विचलन को कम करने के लिए बार-बार खींचें।

निष्कर्ष

नॉन-फ़ास्ट-फ़ॉरवर्ड पुश रिजेक्शन का मतलब है कि रिमोट में ऐसे कमिट हैं जो आपके पास स्थानीय रूप से नहीं हैं – Git आपके पुश को ब्लॉक करके उन कमिट्स की सुरक्षा करता है। समाधान सरल है:पहले दूरस्थ परिवर्तन खींचें (git pullमर्ज करने के लिए, याgit pull --rebaseसाफ़ इतिहास के लिए), किसी भी टकराव को हल करें, फिर पुश करें. साझा शाखाओं पर कभी भी जबरदस्ती दबाव न डालें – यह दूसरों के काम को नष्ट कर देता है। यदि आपको अपनी स्वयं की फीचर शाखा को अधिलेखित करना है, तो--force-with-leaseका उपयोग करें (से अधिक सुरक्षित--force). इस त्रुटि से बचने के लिए, बार-बार खींचें और अपनी टीम से संवाद करें। यह समझना कि Git उन कमिटों की सुरक्षा कर रहा है जिन्हें आपने नहीं देखा है, समाधान को सहज बनाता है: दूरस्थ कार्य को एकीकृत करें, फिर पुश करें।