2012-04-14 10 views
29

मैं सहयोगी रूप से किसी परियोजना के साथ किसी के साथ काम कर रहा हूं, इसलिए हमने गिट का उपयोग करने का फैसला किया। दुर्भाग्य से, हम अक्सर कोई इंटरनेट के साथ स्थानों में कोड है, तो हम कुछ इस तरह के साथ अंत:गिट ने कोई फ़ाइल परिवर्तन के साथ विलय प्रतिबद्ध क्यों बनाया?

origin/master: A---B---C 
         \ 
mylocalmaster:   D---E---F 
         \ 
hismaster:    G---H---I 

अब, का कहना है कि वह अपने प्रतिबद्ध धक्का और हो जाता है इस:

origin/master: A---B---C---G---H---I 
         \ 
master (local):   D---E---F 

सभी मैं करना चाहता हूँ मेरी करता धक्का दोनों अपने स्थानीय रेपो और ऑनलाइन एक में इस प्राप्त करने के लिए है:

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

यह काम करने के लिए जब मैं git push कर रहा है, लेकिन मुसीबत पैदा होती है जब मैंकरना 0 और फिर git merge। मैं बस इतना करना चाहता हूं कि प्राप्त करें मेरे स्थानीय रेपो में आता है, लेकिन मैं अपने संदेश के रूप में Merge remote-tracking branch 'origin/master' जैसे कुछ विलय प्रतिबद्धता के साथ समाप्त होता हूं।

मैं इस व्यर्थ प्रतिबद्धता को नहीं रखना चाहता, क्योंकि हमारे काम में कोई विवादित कोड नहीं है। हम पूरी तरह से अलग फाइलों पर काम कर रहे हैं, इसलिए इस प्रतिबद्धता का कोई कारण नहीं है। मैं इस विलय प्रतिबद्धता को बनाने से गिट को कैसे रोक सकता हूं?

+1

जब आप उस स्थिति में गिट पुश करते हैं तो आपको एक त्रुटि मिलनी चाहिए। यह ठीक काम नहीं लग रहा है। – bames53

+0

चूंकि मैं इस पृष्ठ पर पहुंचने की कोशिश कर रहा हूं कि किसी भी फ़ाइल परिवर्तन के बिना मर्ज गेट बनाने के लिए * गिट को कैसे बल देना है, मैं यहां उल्लेख करूंगा कि इसका उत्तर 'गिट प्रतिबद्ध-पेड़' कमांड है। 'मैन गिट-प्रतिबद्ध-पेड़' देखें। – Wildcard

+0

@ वाइल्डकार्ड जिज्ञासा से बाहर, आप किस स्थिति में एक विलय प्रतिबद्ध बनाना चाहते हैं कि 'गिट मर्ज - नो-एफएफ' हल नहीं होगा? –

उत्तर

29

आप बनाने मर्ज करता, का उपयोग करके छोड़ सकते हैं rebase बजाय विलय करें।

रूप @Dougal कहा, यदि आप git fetch करते हैं, आप git rebase बाद में निष्पादित कर सकते हैं प्राप्त किए गए HEAD में अपने परिवर्तन के आधार बदलने के लिए।

आमतौर पर आप उन अवांछित मर्ज रिमोट रिपोजिटरी से खींचकर मर्ज करते हैं। उस मामले में आप --rebase विकल्प जोड़ सकते हैं:

git pull --rebase 

या उचित विकल्प जोड़ने कॉन्फ़िग फ़ाइल Git करने के लिए (स्थानीय):

git config branch.<branch-name-here>.rebase true 

या सभी नए खजाने और शाखाओं के लिए:

git config branch.autosetuprebase always --global 

हालांकि, पुनर्जन्म क्लीनर, अधिक रैखिक इतिहास बनाता है मर्ज कमेट बनाना अच्छा है, जहां बड़े बदलाव हैं दोनों शाखाओं में (ऐसा करने के लिए git merge का उपयोग करें)।

+0

और आपके पहले प्रश्न का उत्तर - क्यों? गिट नवागंतुकों के लिए भ्रम से बचने के लिए विलय को डिफ़ॉल्ट रूप से बनाया जाता है, क्योंकि यह अवधारणात्मक रूप से सरल स्थिति है और लोग विलय करते समय विलय करने की अपेक्षा करते हैं। –

+2

मैं इन कामों को बनाना नहीं चाहता क्योंकि मैं कुछ भी विलय नहीं कर रहा हूं। अगर मैं इन कामों में से एक लाख बनाता हूं जो कुछ भी नहीं करता है, तो यह किसी भी कारण से मेरे प्रतिबद्ध इतिहास को बंद कर देगा। –

+5

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

9

git rebase (git fetch के बाद) अपने काम को पिछले मास्टर के बजाए उसके खिलाफ लागू करने के लिए उपयोग करें। यही है, अपने उदाहरण में ABCGHIDEF पर जाना है। (आप एक push -f करने के लिए बिना ABCDEFGHI नहीं कर सकते, क्योंकि ABCGHIorigin/master में पहले से ही है और आप उस ओवरराइड करने के लिए होगा।)

+0

धन्यवाद। मुझे पता था कि यह कुछ मूर्खतापूर्ण था, लेकिन मुझे नहीं पता था कि क्या। –