Git fork को upstream से sync करें: 3 सुरक्षित तरीक़े

TL;DR: git fetch upstream && git merge upstream/main && git push origin main चलाइए और आपका फ़ोर्क बराबर हो गया। “git sync fork with upstream” का पूरा वर्कफ़्लो बस इतनी सी लाइन है — जिस प्रोजेक्ट का फ़ोर्क बनाया था उसके बदलाव खींचिए, फिर अपनी कॉपी पर पुश कीजिए। लीनियर हिस्ट्री पसंद है तो merge की जगह git rebase upstream/main लीजिए और force-push कीजिए। और अगर आपने upstream रिमोट कभी जोड़ा ही नहीं, तो नीचे स्टेप 1 से शुरू कीजिए — क्योंकि यही ग़ायब रिमोट नंबर-एक वजह है कि फ़ोर्क “sync नहीं होता”। बाक़ी सब — rebase, GitHub का sync बटन, जिन ब्रांचों को पुश नहीं हो पाता — इन्हीं तीन कमांड्स की फ़र्मैइश है।

फ़ोर्क का upstream से sync होना किसे कहते हैं?

फ़ोर्क GitHub पर किसी और की रिपॉज़िटरी की आपकी कॉपी है। मूल रिपो upstream है; आपकी कॉपी origin। GitHub के फ़ोर्क ख़ुद-ब-ख़ुद अपडेट नहीं होते — जब मेंटेनर कोई पुल रिक़्वेस्ट मर्ज करते हैं, आपकी कॉपी कल का कोड ही रखती है। फ़ोर्क का sync मतलब है upstream के नए कमिट्स अपने फ़ोर्क में खींचना, ताकि आपकी ब्रांच प्रोजेक्ट की मौजूदा हालत से मेल खाए — या कम से कम उसमें शामिल हो।

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

कमांड लाइन से फ़ोर्क को upstream से कैसे sync करें?

तीन स्टेप: एक बार upstream घोषित कीजिए, उससे fetch कीजिए, फिर merge करके push कीजिए। वायरिंग स्थायी है — अगली बार सिर्फ़ स्टेप 2 और 3 टाइप करने होते हैं।

स्टेप 1 — upstream रिमोट जोड़ें (हर क्लोन में एक बार)।

# फ़ोर्क के अपने लोकल क्लोन के अंदर
git remote add upstream https://github.com/ORIGINAL_OWNER/REPO.git
git remote -v   # तस्दीक़: origin -> आपका फ़ोर्क, upstream -> मूल रिपो

सही URL मूल रिपो के पेज पर मिलेगा: हरा Code बटन। एक आम ग़लती दोनों रिमोट्स को अपने ही फ़ोर्क पर इशारा करना है — फिर “sync” चुपचाप कुछ नहीं करता, क्योंकि आपने उसी जितनी पुरानी एक और कॉपी से fetch किया।

स्टेप 2 — upstream ब्रांच fetch और merge करें।

git checkout main
git fetch upstream
git merge upstream/main
git push origin main

“git sync fork with upstream command line” का स्टैंडर्ड जवाब यही है। आम नतीजा fast-forward होता है — आपके फ़ोर्क की main पर कुछ नया नहीं था, तो वह बस upstream/main तक खिसक जाती है और कोई merge कमिट नहीं बनता।

स्टेप 3 — ज़रूरत पर दोहराएँ। git fetch upstream && git merge upstream/main && git push origin main के आगे याद रखने को कुछ नहीं। merge से पहले देखना हो कि कितना पीछे हैं, तो fetch के बाद git rev-list --count main..upstream/main चलाइए।

फ़ोर्क sync करते वक़्त rebase करें या merge?

दोनों आपके फ़ोर्क में एक ही कोड पहुँचाते हैं; फ़र्क़ पीछे छूटी हिस्ट्री का है। हर रिपो के लिए एक पॉलिसी चुनिए और उसी पर टिकिए:

तरीक़ा	कमांड	हिस्ट्री का नतीजा	किसके लिए बेस्ट
Merge	git merge upstream/main	बँटी हुई ब्रांचों पर एक अतिरिक्त merge कमिट	खुले PR वाली फ़ीचर ब्रांचें — कुछ भी दोबारा नहीं लिखता
Rebase	git rebase upstream/main	आपके कमिट्स ऊपर फिर से चलते हैं, लीनियर हिस्ट्री	फ़ोर्क की main साफ़ रखना; जिन बँटे फ़ोर्क को रीसेट करना है
GitHub UI	Sync branch बटन / PR merge	merge जैसा ही	बिना क्लोन खोले फ़ुर्सत से बराबर करना

Sync का rebase रूप:

git fetch upstream
git rebase upstream/main
git push --force-with-lease origin main

Force push ज़रूरी है क्योंकि rebase कमिट IDs दोबारा लिखता है — आपके फ़ोर्क की रिमोट ब्रांच अब आपकी लोकल ब्रांच से उतरी हुई नहीं रहती। हमेशा --force की जगह --force-with-lease चुनिए: बीच में किसी ने (या आपकी किसी दूसरी मशीन ने) पुश किया हो तो यह रिमोट पर लिखने से इनकार कर देता है — ख़तरनाक कमांड इससे डिफ़ॉल्ट रूप से सुरक्षित हो जाता है।

एक नियम कलाई पर गुदवा लीजिए: खुला पुल रिक़्वेस्ट वाली ब्रांच को कभी rebase न कीजिए, जब तक आप जानते हों कि क्या कर रहे हैं — rebase कमिट IDs बदल देता है, जिससे खुला PR उसके कमिट्स से उठा सकता है। main को merge से sync कीजिए (या नया काम शुरू करने से पहले rebase कीजिए), और PR ब्रांचों को इस खेल से बाहर रखिए।

मेरा फ़ोर्क upstream से sync क्यों नहीं हो रहा?

चार आम मुलज़िम, असली टर्मिनलों में जिस क्रम में दिखते हैं:

1. upstream रिमोट ही नहीं — git remote -v सिर्फ़ origin दिखाता है। लक्षण: git fetch upstream 'upstream' does not appear to be a git repository कहकर फेल होता है। इलाज: ऊपर स्टेप 1।
2. fetch किया पर merge कभी नहीं किया — fetch आपकी लोकल रिपो में upstream/main अपडेट करता है पर किसी काम की ब्रांच को नहीं छूता। लक्षण: सफल fetch के बाद भी git log पुराना लगता है। इलाज: git merge upstream/main।
3. बँटी हुई हिस्ट्री — आपने अपने फ़ोर्क की main पर कमिट किए, और upstream भी आगे बढ़ गया। अब git pull अनजानी हिस्ट्री की फ़रियाद करता है या merge थोपता है। इलाज, अगर upstream को जीतना है: git reset --hard upstream/main (आपके सिर्फ़-लोकल कमिट्स फेंक देता है — पहले git stash list देख लीजिए या एक ब्रांच बनाकर बचा लीजिए; अगर बुरा वाला reset पहले ही हो चुका है, तो वापसी का रास्ता वही है जो git undo last commit में बताया गया: git reflog पुराना टिप अब भी जानता है)।
4. rebase के बाद push non-fast-forward कहकर ठुकराया — rebase किया पर push सामान्य तरीक़े से किया। इलाज: git push --force-with-lease origin main।

पाँचवाँ, दुर्लभ मामला: upstream रिपो rename या delete हो गई, तो स्टेप 1 का URL भी 404 देता है। GitHub renamed रिपोज़ को redirect करता है, इसलिए सख़्त नाकामी अक्सर delete या प्राइवेट होने का इशारा है — sync करने को कुछ बचा ही नहीं।

क्या GitHub वेबसाइट से फ़ोर्क sync कर सकते हैं?

हाँ। अपने फ़ोर्क के पेज पर ब्रांच ड्रॉपडाउन में Sync fork बटन तब दिखता है जब आपकी ब्रांच पीछे हो; एक क्लिक में upstream अंदर आ जाता है। नीचे की ओर वही काम पुल रिक़्वेस्ट की तरह भी होता है: upstream/main से अपने फ़ोर्क की main में PR खोलिए और मर्ज कर दीजिए।

बटन की हदें बताती हैं CLI कब लेनी है: वह सिर्फ़ fast-forward या merge करता है — rebase नहीं करता, और ब्रांचें बँट चुकी हों तो साफ़ इनकार कर देता है कि कमिट्स छोड़ दीजिए या कमांड लाइन लीजिए। वह सिर्फ़ डिफ़ॉल्ट ब्रांच भी sync करता है। सीधी बराबरी से आगे हर काम के लिए ऊपर वाली तीन कमांड्स ही औज़ार हैं।

अपने फ़ोर्क को कितनी बार sync करना चाहिए?

ईमानदार जवाब: हर नए काम से पहले — ताज़ी main से ब्रांच निकालिए, और आपका कोई PR “यह तीन हफ़्ते पुराने वर्ज़न पर बना है” से शुरू नहीं होगा। जिन फ़ोर्क में सक्रिय योगदान देते हैं, उनकी main का रोज़ाना या हर सेशन का sync सेकंडों का ख़र्च है। जिस फ़ोर्क को सिर्फ़ पढ़ते या डिप्लॉय करते हैं, वह upstream के चाहे हुए चीज़ शिप होने पर sync कीजिए — मूल रिपो की releases फ़ीड सब्सक्राइब कीजिए और रिलीज़ पर sync कीजिए। sync सस्ता ठीक इसीलिए है कि वह रोज़मर्रा है; छह महीने पीछे फ़ोर्क को अक्सर merge नहीं, ऑपरेशन चाहिए — और यहीं “मेरा फ़ोर्क sync करो” एक दोपहर में बदल जाता है।

चीट शीट

# एक बार का सेटअप
git remote add upstream https://github.com/ORIGINAL_OWNER/REPO.git

# रोज़मर्रा का sync (merge पॉलिसी)
git fetch upstream && git merge upstream/main && git push origin main

# रोज़मर्रा का sync (rebase पॉलिसी, लीनियर हिस्ट्री)
git fetch upstream && git rebase upstream/main && git push --force-with-lease origin main

# मैं कितना पीछे हूँ?
git fetch upstream && git rev-list --count main..upstream/main

# बँटा फ़ोर्क, अब ठीक नहीं होता — main को upstream जैसा कर दो (destructive)
git fetch upstream && git reset --hard upstream/main && git push --force-with-lease origin main

रोज़ की इस दो-लाइन वाली कमांड को मांसपेशियों में उतार लीजिए, और बँटा हुआ फ़ोर्क किताबी क़िस्सा बना रहेगा, ठीक करने की मुसीबत नहीं। अगर आपकी git सफ़ाई सर्वरों तक फैली है, तो journalctl cheat sheet मशीन की हिस्ट्री पढ़ने लायक रखने का दूसरा हिस्सा सँभालती है।