अंतर होने के बावजूद Git मर्ज की रिपोर्ट "पहले से ही अद्यतित" है

Question

मेरे पास 2 शाखाओं के साथ गिट रिपॉजिटरी है: मास्टर और टेस्ट।

मास्टर और परीक्षण शाखाओं के बीच अंतर हैं।

दोनों शाखाओं में सभी परिवर्तन किए गए हैं।

यदि मैं करता हूँ:

गिट चेकआउट मास्टर

git भिन्न परीक्षण

परिवर्तनों से भरी एक स्क्रीन अंतर दिखाती है। मैं परीक्षण शाखा में परिवर्तनों को मर्ज करना चाहता हूं और इस प्रकार करता हूं:

git मर्ज टेस्ट

लेकिन संदेश "पहले से ही अद्यतित" प्राप्त करें

हालांकि, प्रत्येक अलग शाखा के तहत फाइलों की जांच करने से स्पष्ट रूप से अंतर दिखाई देता है।

यहाँ क्या समस्या है और मैं इसे कैसे हल करूं?

Comments

क्या आपके पास अन-कमिटेड संशोधित कोड है?

— ओजमा

क्या इससे आपके सवाल का जवाब मिलता है? Git का कहना है कि मेरी मास्टर शाखा "पहले से ही अद्यतित" है, हालांकि यह नहीं है?

— माइकल फ्रीजिम

Answer 1

संदेश "पहले से ही अद्यतित" का अर्थ है कि जिस शाखा में आप विलय करने का प्रयास कर रहे हैं, उससे सभी परिवर्तन पहले से ही उस शाखा में विलय हो चुके हैं जो आप वर्तमान में हैं। अधिक विशेष रूप से इसका मतलब है कि जिस शाखा को आप विलय करने की कोशिश कर रहे हैं वह आपकी वर्तमान शाखा का एक माता-पिता है । बधाई हो, यह सबसे आसान मर्ज है जो आप कभी भी करेंगे। :)

gitkअपने भंडार पर एक नज़र डालने के लिए उपयोग करें । "परीक्षण" शाखा के लिए लेबल आपके "मास्टर" शाखा लेबल के नीचे कहीं होना चाहिए।

आपकी शाखा अपने माता-पिता के संबंध में अद्यतित है। मर्ज के अनुसार अंतिम विलय के बाद से माता-पिता में कोई नए बदलाव नहीं हुए हैं। इसका मतलब यह नहीं है कि शाखाएँ समान हैं, क्योंकि आपके पास अपनी कार्यशील शाखा में बहुत सारे बदलाव हो सकते हैं और ऐसा लगता है जैसे आप करते हैं।

संपादित करें 10/12/2019:

इस जवाब के लिए टिप्पणी में चार्ल्स चार्ल्स ड्रेक, समस्या का निवारण करने के लिए एक समाधान है:

git checkout master
git reset --hard test

यह इसे 'परीक्षण' स्तर पर वापस लाता है।

फिर करो:

git push --force origin master

केंद्रीय रेपो में परिवर्तन के लिए बाध्य करने के लिए।

Comments

पवित्र cr * p! आप सही हे! मुझे लगता है कि क्या हुआ था कि एक और शाखा (अस्थिर विकास) को गलत तरीके से मास्टर के साथ मिला दिया गया था और परीक्षण शाखा अस्थिर का एक उप-सेट थी। मैं जो मर्ज करने की कोशिश कर रहा था वह मास्टर को 'परीक्षण' स्तर पर वापस लाना था।

— चार्ल्स डार्के

सही। इस ऑपरेशन का कोई मतलब नहीं होगा इसलिए Git कुछ भी करने से मना कर देगा। :)

— बोम्बे

मैंने अब जो किया है वह है: गिट चेकआउट मास्टर; गिट रीसेट - भार परीक्षण; यह इसे 'परीक्षण' स्तर पर वापस लाता है। फिर मैंने केंद्रीय रेपो में परिवर्तन के लिए मजबूर करने के लिए "गिट पुश --फोर्स ओरिजिन मास्टर" किया।

— चार्ल्स डार्के

अच्छा होता अगर गिट में "माता-पिता के साथ विलय करने की कोशिश" कहने की चेतावनी होती।

— चार्ल्स डार्के

एक शाखा को धक्का देना जो पहले से ही दूरस्थ तरफ मौजूद शाखा का वंशज नहीं है, एक बुरी बात मानी जाती है: गिट-पुश और गिट-पुल के लिए मैन पेजों पर चर्चा देखें।

— बॉम्बे

Answer 2

यह अक्सर मेरे साथ होता है जब मुझे पता है कि दूरस्थ मास्टर पर परिवर्तन हैं, इसलिए मैं उनका उपयोग करके विलय करने का प्रयास करता हूं git merge master। हालाँकि, यह दूरस्थ मास्टर के साथ, लेकिन आपके स्थानीय मास्टर के साथ विलय नहीं करता है।

तो मर्ज करने से पहले, चेकआउट मास्टर, और फिर git pullवहाँ। तब आप नए परिवर्तनों को अपनी शाखा में मर्ज कर पाएंगे।

Comments

क्या कोई ऐसा तरीका है जिससे शाखाओं की अदला-बदली से बचा जा सकता है, जैसे कि शाखा में विलय होने के लिए शाखा को खींचने का काम तब करना और फिर विलय करना?

— जफेट ओन्गेरी - इंकलीमेवा

आह, अच्छा है। मैंने सोचा git fetchकि अगर मैं वर्तमान में एक अलग पर हूं, तो भी मैं मास्टर ब्रांच को अपडेट करूंगा। यह नहीं करता है। धन्यवाद! मुझे पूरा यकीन है कि इसके लिए एक विकल्प fetchहै जो आपको निर्दिष्ट करने की अनुमति देता है कि किस शाखा को प्राप्त करना है।

— राक

@ राईक आप कर सकते हैं git fetch --all, लेकिन यह केवल शाखाओं को प्राप्त करता है, यह उन्हें नहीं खींचता है।

— इंगो बुर्क

@ JaphethOngeri-inkalimeva आप बस कर सकते हैं git fetch --all && git merge origin/master। masterदूरस्थ परिवर्तनों को मर्ज करने के लिए अपने स्थानीय को अपडेट करने की आवश्यकता नहीं है ।

— इंगो बुर्क

@ IngoBürk मेरी 2 शाखाएँ थीं, 1 के साथ 1 अद्यतन git merge masterऔर 1 के साथ git merge origin/master। मैं यह भी जाँच की थी masterऔर git pull2 शाखाओं को अद्यतन करने से पहले। भले ही उन्होंने समान सामग्री साझा की, 2 शाखाओं के बीच एक पीआर बनाने से कुछ अलग फाइलें दिखाई गईं। मैंने git pullलक्ष्य शाखा द्वारा फीचर शाखा में तय किया था, जिसमें दिखाया गया था: Already up to date! Merge made by the 'recursive' strategy.इसके परिणामस्वरूप मर्ज में कोई बदलाव नहीं हुआ, लेकिन पीआर से अप्रत्याशित रूप से अलग फाइलें हटा दी गईं । कोई भी विचार क्यों "स्थानीय" और दूरस्थ शाखाओं के विलय के बीच एक अंतर है?

— रैपपरैप्स

Answer 3

कहो कि आपके पास masterनिम्नलिखित प्रतिबद्ध इतिहास वाली एक शाखा है :

A -- B -- C -- D

अब, आप एक शाखा परीक्षण बनाते हैं, उस पर काम करते हैं, और 4 कमिट करते हैं:

                 E -- F -- G -- H
                /
A -- B -- C -- D

masterका सिर D को इंगित करता है, और testH को सिर का अंक।

"पहले से ही अद्यतित" संदेश तब दिखाई देता है जब आप जिस शाखा में विलय कर रहे हैं, उस शाखा के माता-पिता उस शाखा के कमिटमेंट की एक अभिभावक हैं जिसे आप विलय करना चाहते हैं। यह मामला है, यहाँ: Dके एक माता पिता है E।

वहाँ से मर्ज करने के लिए कुछ भी नहीं है testके लिए masterके बाद से कुछ भी नहीं है पर बदल गया है, masterतब से। यहाँ आप जो करना चाहते हैं, उसका शाब्दिक अर्थ है Git masterको H को इंगित करने के लिए, इसलिए गुरु की शाखा में निम्नलिखित गुण हैं:

A -- B -- C -- D -- E -- F -- G -- H

यह गिट कमांड के लिए एक नौकरी है reset। आप इस परिवर्तन को प्रतिबिंबित करने के लिए कार्यशील निर्देशिका भी चाहते हैं, इसलिए आप एक हार्ड रीसेट करेंगे:

git reset --hard H

Comments

मुझे अतीत में बताया गया है कि प्रयोग git reset --hardकरना काफी कठोर काम है, क्या यह कमिट कर सकता है? क्या इन परिवर्तनों को करने का एक सुरक्षित तरीका है, या git reset --hardअतिरंजित होने के खतरे हैं ?

— ग्राहम आर। आर्मस्ट्रांग

यह आज्ञा समझदार है, कोई चिंता नहीं। मैं केवल यही कहूंगा कि --hardविकल्प के साथ ध्यान देने की बात यह है कि यह वास्तव में आपकी कार्यशील निर्देशिका को संशोधित करता है, और इसके परिणामस्वरूप, आप बिना परिवर्तन किए हुए परिवर्तन खो देते हैं। व्यक्तिगत रूप से, मैं git statusयह सुनिश्चित करने के लिए कि मेरा रेपो साफ है या अपेक्षित स्थिति में है, मैन्युअल रूप से चलने वाली प्रत्येक कमांड के पहले और बाद में करता हूं।

— मारेक स्टेनली

यह "आपकी शाखा और 'मूल / मास्टर' ने स्थिति संदेश को अलग कर दिया है, मैं इसे कैसे हल कर सकता हूं?

— Eido95

काश मैं तुम्हें एक से अधिक उत्थान दे पाता। धन्यवाद!

— KMC

क्या --hardविकल्प की कोई आवश्यकता है ? मैं इस स्थिति में एक दो बार रहा हूँ और हमेशा बिना रीसेट करता हूँ --hard। इसने बिना किसी परिवर्तन के बिना किसी जोखिम के ठीक होने का काम किया।

— कासिमिर

Answer 4

मेरे लिए क्या काम करता है, मान लीजिए कि आपके पास शाखा 1 है और आप इसे शाखा 2 में विलय करना चाहते हैं।

आप git कमांड लाइन को शाखा 2 के रूट फोल्डर में खोलें और टाइप करें:

git checkout branch1
git pull branch1
git checkout branch2
git merge branch1
git push

यदि आपके पास कम्फर्ट्स हैं, तो आपको गिट पुश करने की आवश्यकता नहीं है, लेकिन पहले कॉन्फ्लिट्स को हल करें और फिर पुश करें।

Answer 5

एक मर्ज हमेशा वर्तमान HEAD और एक या अधिक कमिट्स (आमतौर पर, ब्रांच हेड या टैग) के बीच होता है,
और इंडेक्स फाइल को HEAD कमिट (यानी अंतिम प्रतिबद्ध की सामग्री) के पेड़ से मेल खाना चाहिए जब यह शुरू होता है।
दूसरे शब्दों में, git diff --cached HEADकोई परिवर्तन नहीं रिपोर्ट करना चाहिए।

मर्ज किए गए कमिट में पहले से ही निहित है HEAD। यह सबसे सरल मामला है, जिसे "पहले से ही अद्यतित" कहा जाता है।

इसका मतलब यह होना चाहिए कि परीक्षण में किए गए कमिट पहले से ही मास्टर में विलय किए जाते हैं, लेकिन चूंकि मास्टर पर अन्य कमिट किए जाते हैं, git diff testफिर भी कुछ अंतर देंगे।

Answer 6

ऐसा इसलिए होता है क्योंकि जिस शाखा में आप विलय करना चाहते हैं, उसकी आपकी स्थानीय प्रति पुराना है। मुझे मेरी शाखा मिल गई है, MyBranchमुझे बुलाया गया है और मैं इसमें विलय करना चाहता हूं ProjectMaster।

_>git status
On branch MyBranch-Issue2
Your branch is up-to-date with 'origin/MyBranch-Issue2'.

nothing to commit, working tree clean

_>git merge ProjectMaster
Already up-to-date.

लेकिन मुझे पता है कि ऐसे बदलाव हैं जिन्हें मर्ज करने की जरूरत है!

यहाँ बात है, जब मैं टाइप करता हूँ git merge ProjectMaster, तो git इस शाखा की मेरी स्थानीय प्रति देखता है , जो शायद चालू न हो । यह देखने के लिए कि क्या यह मामला है, मैं सबसे पहले Git को जाँचने और देखने के लिए कहता हूँ कि क्या मेरी शाखाएँ पुरानी हैं और यदि कोई उपयोग हो रहा है, तो उह fetch। फिर मुझे उम्मीद है कि मैं उस शाखा में विलीन हो जाऊंगा जो वहां हो रहा है ...

_>git fetch origin

_>git checkout ProjectMaster
Switched to branch ProjectMaster
**Your branch is behind 'origin/ProjectMaster' by 85 commits, and can be fast-forwarded.**
  (use "git pull" to update your local branch)

आह-हा! मेरी स्थानीय प्रति 85 बासी है, जो सब कुछ समझाती है! अभी मैंPull उन परिवर्तनों को कम कर रहा हूँ जो मुझे याद आ रहे हैं, फिर MyBranchसे मर्ज करने का प्रयास करें।

_>git pull
Updating 669f825..5b49912
Fast-forward

_>git checkout MyBranch-Issue2
Switched to branch MyBranch-Issue2
Your branch is up-to-date with 'origin/MyBranch-Issue2'.

_>git merge ProjectMaster
Auto-merging Runbooks/File1.ps1
CONFLICT (content): Merge conflict in Runbooks/Runbooks/File1.ps1

Automatic merge failed; fix conflicts and then commit the result.

और अब मुझे ठीक करने के लिए एक और मुद्दा है ...

Answer 7

यह मेरे साथ हुआ क्योंकि अजीब तरह से जीआईटी ने सोचा कि स्थानीय शाखा दूरस्थ शाखा से अलग थी। यह शाखा ग्राफ़ में दिखाई देता था: इसने दो अलग-अलग शाखाएँ प्रदर्शित कीं: रीमोज़ / ओरिजिन / ब्रांच_नाम और ब्रांच_नाम।

समाधान केवल स्थानीय रेपो को हटाने और रिमोट से इसे फिर से क्लोन करने के लिए था। इस तरह से जीआईटी को समझ में आएगा कि रीमोट / ओरिजिन / ब्रांच_नाम> और ब्रांच_नाम वास्तव में एक ही हैं, और मैं इसे जारी कर सकता हूं git merge branch_name।

rm <my_repo>
git clone <my_repo>
cd <my_repo>
git checkout <branch_name>
git pull
git checkout master
git merge <branch_name>

Comments

क्या यह ठीक उसी तरह का उत्तर नहीं है जैसा कि एकेटर्स का है?

— एंड्रयू सी

मुझे लगता है कि एक्सेटर वास्तव में इस बिंदु से चूक गए - रिमोट पर कोई बदलाव नहीं हुए - यह समस्या बिल्कुल नहीं थी। मुझे तेजी से आगे विलय को मजबूर करने के लिए "गिट चेकआउट मास्टर" और फिर "गिट मर्ज <ब्रांच_नाम>" की आवश्यकता थी। दूसरी तरह के आसपास कुछ भी नहीं किया क्योंकि शाखा मास्टर से आगे थी। बॉम्बे का जवाब एक अच्छा स्पष्टीकरण है, लेकिन कभी भी सवाल का "मैं इसे कैसे हल करूं" का जवाब नहीं दिया।

— MrMas

Answer 8

git merge origin/masterइसके बजाय git merge masterमेरे लिए काम किया। इसलिए मास्टर को उस सुविधा शाखा में मर्ज करने के लिए जिसका आप उपयोग कर सकते हैं:

git checkout feature_branch
git merge origin/master

Answer 9

उस शाखा को चेकआउट करना सुनिश्चित करें जिसे आप पहले मर्ज करना चाहते हैं और फिर इसे खींचें (इसलिए आपका स्थानीय संस्करण दूरस्थ संस्करण से मेल खाता है)।

फिर अपनी शाखा में चेकआउट करें, जिस पर आप मर्ज करना चाहते हैं और आपका मर्ज मर्ज काम करना चाहिए।

Comments

यह मेरे लिए था - मैंने मास्टर में रहते हुए एक पुल किया; मुझे पता चला कि मुझे "शाखा" में नए कमिट मिले। "शाखा" को मास्टर में विलय करने की कोशिश की - "पहले से ही अद्यतित"। क्या Git चेकआउट "शाखा" - मिला है, जिसका अर्थ है मैं चलाकर "शाखा" अद्यतन करने के लिए की जरूरत है "आपका शाखा के पीछे है ... और तेजी से अग्रेषित किया जा सकता।" git pullजबकि "शाखा" में

— sdbbs

Answer 10

मुझे खुशी हुई और मुझे इस पृष्ठ पर भेज दिया गया, यह सुनिश्चित नहीं था कि मेरे पास एक ही परिदृश्य था, लेकिन मेरा मुझे "परीक्षण" करने के लिए "फिर से मर्ज" करने की कोशिश कर रहा था।

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

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

यकीन नहीं है कि यह सही तरीका है या दूसरों को इसी मुद्दे पर मदद कर सकता है, लेकिन यह मेरे विशेष मामले का समाधान प्रदान करता है।

Comments

यहाँ भी वही स्थिति। परिदृश्य यह है कि मैं एक "एकीकरण" शाखा को कई "सुविधा" शाखा में वापस विभाजित करना चाहता हूं।

— यदाली

मैनुअल पेस्ट के बजाय, आप फ़ाइलों को सीधे एक शाखा से वर्तमान शाखा में चेकआउट कर सकते हैं git checkout srcBranch -- path/to/file:। फ़ाइल ग्लब्स का भी उपयोग कर सकते हैं।

— टोड

धन्यवाद, मैंने आपका चेकआउट तरीका इस्तेमाल किया, लेकिन मैंने checkout srcBranch -- *अपने डिफरेंसेस को देखा

— portforwardpodcast

Answer 11

यदि शाखा ए को शाखा बी में विलय किया जाता है, तो "पहले से ही अद्यतित" रिपोर्ट करता है, रिवर्स हमेशा सच नहीं होता है। यह केवल तभी सच है जब शाखा B शाखा A के वंशज है, अन्यथा शाखा B में वे परिवर्तन हो सकते हैं जो A में नहीं हैं।

उदाहरण:

1. आप शाखाओं को ए और बी मास्टर बनाते हैं
2. आप मास्टर में कुछ बदलाव करते हैं और इन परिवर्तनों को केवल शाखा B में विलय करते हैं (अपडेट करने के लिए या शाखा A को अपडेट करने के लिए नहीं भूलना)।
3. आप शाखा A में कुछ परिवर्तन करते हैं और A को B में मिलाते हैं।

इस बिंदु पर A से B रिपोर्ट "पहले से ही अद्यतित" है, लेकिन शाखाएँ भिन्न हैं क्योंकि शाखा B में मास्टर से अपडेट है जबकि शाखा में ऐसा नहीं है।

Answer 12

Git Bash का उपयोग करके इस परिदृश्य का सामना किया।

हमारी रिपॉजिटरी की कई शाखाएँ हैं और प्रत्येक शाखा का एक अलग प्रतिबद्ध चक्र है और विलय एक बार में होता है। Old_Branch का उपयोग New_Branch के लिए माता-पिता के रूप में किया गया था

Old_Branch को कुछ बदलावों के साथ अपडेट किया गया था जिसे New_Branch के साथ मर्ज करना आवश्यक था

सभी शाखाओं से सभी स्रोतों को प्राप्त करने के लिए बिना किसी शाखा के नीचे दिए गए कमांड का उपयोग कर रहा था।

git पुल उत्पत्ति

अजीब तरह से यह सभी शाखाओं से सभी आवागमन को नहीं खींचता है। सोचा था कि यह संकेत के रूप में लगभग सभी शाखाओं और टैग से पता चलता है।

तो इसे ठीक करने के लिए Old_Branch ने नवीनतम उपयोग करके जाँच की

git चेकआउट Old_Branch

git पुल ओरिजिन Old_Branch

अब New_Branch की जाँच की

git चेकआउट New_Branch

यह सुनिश्चित करने के लिए खींच लिया

git पुल उत्पत्ति New_Branch

git मर्ज Old_Branch

और वायोला को Old_Branch से New_Branch :) तक तय करने के लिए संघर्ष मिला, जो अपेक्षित था

Answer 13

मेरे साथ भी ऐसा ही हुआ। लेकिन परिदृश्य थोड़ा अलग था, मेरी मास्टर शाखा थी, और मैंने इसके बाहर release_1 (कहना) उकेरा था। रिलीज़ 1 शाखा में कुछ बदलाव किए और इसे मूल में मिला दिया। तब मैंने ssh किया और रिमोट सर्वर पर मैंने फिर से check_1 को कमांड git checkout -b release_1 का उपयोग करके चेकआउट किया - जो वास्तव में एक नई शाखा release_ का निर्माण करता है! मूल से पहले से मौजूद शाखा रिलीज़ 1 की जाँच करने के बजाय मास्टर से। "-B" स्विच को हटाकर समस्या का समाधान किया

Answer 14

मुझे भी यही समस्या थी। मेरे पास रिमोट में परिवर्तन थे और यह अभी भी "पहले से ही अद्यतित" दिखा रहा था। रिपॉजिटरी को रिकॉल करने से मेरे लिए समस्या का समाधान हो गया।

Answer 15

मूर्खतापूर्ण लेकिन ऐसा हो सकता है। मान लें कि आपकी शाखा का नाम किसी मुद्दे के संदर्भ में उपसर्ग है (उदाहरण के लिए #91-fix-html-markup), यदि आप यह मर्ज करते हैं:

$ git merge #91-fix-html-markup

यह इरादा के अनुसार काम नहीं करेगा क्योंकि सब कुछ #अनदेखा करने के बाद , क्योंकि# एक इनलाइन टिप्पणी शुरू होती है।

इस स्थिति में आप शाखा का नाम बदल सकते हैं #या शाखा नाम को घेरने के लिए एकल उद्धरण का उपयोग कर सकते हैं git merge '#91-fix-html-markup':।