डिफ़ॉल्ट रूप से रिबेट के बजाय गिट पुल एक मर्ज क्यों करता है?


71

निम्नलिखित स्थिति पर विचार करें:

  • आपके पास गिट रिपॉजिटरी का क्लोन है
  • आपके कुछ स्थानीय कमिट हैं (कमिट जो अभी तक कहीं धकेल नहीं दिए गए हैं)
  • रिमोट रिपॉजिटरी में नए कमिट्स हैं जिन्हें आपने अभी तक नहीं समेटा है

तो कुछ इस तरह:

अनमनापन करता है

यदि आप git pullडिफ़ॉल्ट सेटिंग्स के साथ निष्पादित करते हैं, तो आपको कुछ इस तरह मिलेगा:

मर्ज करना

ऐसा इसलिए है क्योंकि git ने एक मर्ज किया है।

हालांकि एक विकल्प है। आप इसके बजाय एक रिबास करने के लिए बता सकते हैं:

git pull --rebase

और आपको यह मिलेगा:

रिबेस

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

किसी भी तरह से मैं यह सुझाव नहीं दे रहा हूं कि यह किसी तरह एक बुरा या गलत डिफ़ॉल्ट है, हालांकि। मुझे सिर्फ उन कारणों के बारे में सोचने में परेशानी हो रही है जो डिफ़ॉल्ट के लिए मर्ज को पसंद किया जा सकता है। क्या हमारे पास कोई अंतर्दृष्टि है कि इसे क्यों चुना गया? क्या ऐसे फायदे हैं जो इसे डिफ़ॉल्ट के रूप में अधिक उपयुक्त बनाते हैं?

इस प्रश्न के लिए प्राथमिक प्रेरणा यह है कि मेरी कंपनी कुछ आधारभूत मानकों को स्थापित करने की कोशिश कर रही है (उम्मीद है कि अधिक दिशा-निर्देश जैसे) कि हम अपने रिपॉजिटरी को कैसे व्यवस्थित करते हैं और प्रबंधित करते हैं ताकि डेवलपर्स के लिए रिपॉजिटरी को आसान बनाने के लिए वे पहले से काम नहीं कर सकें। मुझे ऐसा मामला बनाने में दिलचस्पी है कि हमें इस प्रकार की स्थिति में आमतौर पर रिबास करना चाहिए (और शायद डेवलपर्स की सिफारिश करने के लिए डिफ़ॉल्ट रूप से रिबास करने के लिए अपने वैश्विक कॉन्फ़िगरेशन सेट करें), लेकिन अगर मैं इसके विरोध में था, तो मैं निश्चित रूप से पूछ रहा हूं कि रिबास क्यों नहीं है ' यदि यह बहुत अच्छा है तो डिफ़ॉल्ट रूप से टी। इसलिए मैं सोच रहा हूं कि क्या कुछ है जो मुझे याद आ रहा है।

यह सुझाव दिया गया है कि यह प्रश्न डुप्लिकेट है कि क्यों कई वेबसाइट "गिट मर्ज" पर "गिट रीबेस" पसंद करती हैं? ; हालाँकि, यह सवाल कुछ हद तक इस एक के विपरीत है। यह मर्ज के ऊपर रीबेस की खूबियों पर चर्चा करता है, जबकि यह सवाल रिबेज पर मर्ज के लाभों के बारे में पूछता है। वहाँ के उत्तर इस बात को दर्शाते हैं, मर्ज के साथ समस्याओं और छूट के लाभों पर ध्यान केंद्रित करना।



दूसरी समस्या यह है कि यदि आप गलती से मास्टर करने के लिए प्रतिबद्ध हैं, तो एक पुल करें जो विलय हो गया है, दो मास्टर सिंक से बाहर हो सकते हैं भले ही मर्ज सामान्य दिख रहा हो। यही कारण है कि मेरे पुल उर्फ ​​में शामिल हैं - ओफ़-ओनली।
Ixrec

अगर सॉकरेट्री कभी अपना ग्राफ दृश्य बदलता है तो यह विद्रोह / विलय को अलग तरह से प्रदर्शित करता है, तो क्या आप विलय पर स्विच करेंगे?
इवान

1
@ ईवन सोर्सट्री को इसका ग्राफ दृश्य नहीं बदलना चाहिए। यह सही ढंग से ग्राफ का प्रतिनिधित्व करता है।
jpmc26

4
मतदाता मतदाताओं के लिए, कृपया ध्यान दें कि मेरे द्वारा स्वीकार किए गए उत्तर में सामग्री निश्चित रूप से उस प्रश्न में मौजूद नहीं है जिसका आप दावा कर रहे हैं कि यह एक डुप्लिकेट है।
jpmc26

जवाबों:


56

यह जानना कठिन है कि विलय उस व्यक्ति की सुनवाई के बिना डिफ़ॉल्ट क्यों है, जिसने यह निर्णय लिया।

यहाँ एक सिद्धांत है ...

Git यह नहीं मान सकता है कि यह हर खींच --rebase के लिए ठीक है। सुनें कि कैसा लगता है। "हर पुल को रीबेस करें।" यदि आप पुल अनुरोधों या समान का उपयोग करते हैं तो केवल गलत लगता है। क्या आप एक पुल अनुरोध पर छूट देंगे?

एक टीम में जो केंद्रीकृत स्रोत नियंत्रण के लिए सिर्फ गिट का उपयोग नहीं कर रहा है ...

  • आप ऊपर से और नीचे से ऊपर की ओर खींच सकते हैं। कुछ लोग डाउनस्ट्रीम से, योगदानकर्ताओं आदि से बहुत अधिक खींचतान करते हैं।

  • आप अन्य डेवलपर्स के साथ घनिष्ठ सहयोग में काम कर सकते हैं, उनसे या साझा विषय शाखा से खींच सकते हैं और अभी भी कभी-कभी अपस्ट्रीम से अपडेट किया जा सकता है। यदि आप हमेशा रिबास करते हैं तो आप साझा इतिहास को बदलते हैं, न कि मजेदार संघर्ष चक्रों का उल्लेख करने के लिए।

Git को एक बड़ी उच्च वितरित टीम के लिए डिज़ाइन किया गया था, जहां हर कोई एक ही केंद्रीय रेपो को नहीं खींचता और धकेलता है। तो डिफ़ॉल्ट समझ में आता है।

  • जिन डेवलपर्स को पता नहीं है कि कब रिबेट करना ठीक है, डिफ़ॉल्ट रूप से विलय हो जाएगा।
  • डेवलपर्स जब चाहें तब रिबास कर सकते हैं।
  • कमिटर्स जो बहुत सारी खींचतान करते हैं और उनमें बहुत अधिक खींच-तान होती है, जो उन्हें सबसे ज्यादा सूट करता है।

इरादे के सबूत के लिए, यहां पर लिनस टॉर्वाल्ड्स के एक प्रसिद्ध ईमेल का लिंक दिया गया है, जब उन्हें इस बात पर ध्यान नहीं देना चाहिए था कि वे रिबास न करें। Dri-devel git पुल ईमेल

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

बहुत सारे लोग अब Git का उपयोग केंद्रीकृत तरीके से करते हैं, जहां एक छोटी सी टीम में हर कोई केवल एक अपस्ट्रीम सेंट्रल रेपो से खींचता है और उसी रिमोट को पुश करता है। यह परिदृश्य कुछ ऐसी स्थितियों से बचता है जहां एक रिबास अच्छा नहीं है, लेकिन आमतौर पर उन्हें खत्म नहीं करता है।

सुझाव: डिफ़ॉल्ट को बदलने की नीति न बनाएं। जब भी आप Git को डेवलपर्स के एक बड़े समूह के साथ जोड़ते हैं, तो कुछ डेवलपर्स Git को गहराई से (खुद शामिल) समझ नहीं पाएंगे। वे Google, SO पर जाएंगे, कुकबुक सलाह प्राप्त करेंगे और फिर आश्चर्य करेंगे कि कुछ चीजें काम क्यों नहीं करती हैं, उदाहरण git checkout --ours <path>के लिए फ़ाइल का गलत संस्करण क्यों मिलता है? अपने स्वाद के अनुकूल आप हमेशा अपने स्थानीय वातावरण को संशोधित कर सकते हैं, उपनाम आदि बना सकते हैं।


5
+1 डिफ़ॉल्ट को न बदलने के लिए - अपने स्वयं के गिट वर्कफ़्लो को रोल करने के बजाय यह संभवत: एक को पकड़ने के लिए बेहतर है जो मौजूद है (उदाहरण के लिए एटटलियन atlassian.com/git/tutorials/comparing-workflows/… ) द्वारा लिखित कोई भी
रोब चर्च

1
जवाब के लिए धन्यवाद। बहाव से नीचे खींचने की जानकारी मुझे याद आ रही थी। इसके अलावा, दिलचस्प रूप से पर्याप्त है, आपके द्वारा दिया गया लिंक ठीक वही है जो मैं हासिल करना चाहता हूं: "लोग (और शायद) को अपने निजी पेड़ों (अपने काम) को फिर से भरना चाहिए ।"
jpmc26

2
@jpmc महान। वास्तव में। निजी पेड़ों को रीबास करने से साझा इतिहास से बहुत ध्यान भंग हो सकता है। मैं करता हूं। यह स्पष्टता है कि ऐसा कब नहीं करना चाहिए।
4

"डेवलपर्स में से कुछ समझ में नहीं आएगा कि सभी गहराई से"। रीबेस गैट का सुपर फैंसी ("गहरा", आदि) फ़ीचर नहीं है। क्या आप वास्तव में इस बात पर विचार करते हैं कि समझना मुश्किल है? मुझे लगता है कि देव को अक्षम कहने के लिए यह एक ट्रिगर होना चाहिए।
विक्टर यारमा

15

यदि आप रिबेट के लिए git मैनपेज पढ़ते हैं , तो यह कहता है :

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

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

जब आप कहते हैं 'कीपिंग ... हिस्ट्री क्लीन', तो आप गलत हैं। यह अच्छा लग सकता है, लेकिन एक उपकरण के लिए जिसे संशोधन के इतिहास को रखने के लिए डिज़ाइन किया गया है, यह हर प्रतिबद्ध रखने के लिए बहुत साफ है ताकि आप देख सकें कि क्या हुआ। इतिहास को बाद में चमकाना, पेटिना को चमकाने जैसा है, एक चमकदार रिप्रो की तरह एक समृद्ध एंटीक दिखने के लिए :-)


3
@ इवान IMHO "काम नहीं करता है, लेकिन सुंदर लग रहा है" कुछ ऐसा है जो पूरी तरह से फैशन उद्योग के लिए आरक्षित होना चाहिए न कि आईटी के लिए। IMHO गिट को इसे हटा देना चाहिए क्योंकि यह स्पष्ट रूप से बहुत से लोगों को यह सोचने के लिए प्रोत्साहित करता है कि शैली पदार्थ से अधिक महत्वपूर्ण है।
gbjbaanb

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

3
कोड पहले और सबसे पहले मशीन द्वारा निष्पादित किया जाता है (संभवतः संकलित होने के बाद)। आपके ऊपर दर्शन को लागू करने से, हम यह निष्कर्ष निकालेंगे कि कोड की पठनीयता कोई मायने नहीं रखती क्योंकि पठनीयता की कोई भी मात्रा कोड को समझने की कठिनाई को हल नहीं करेगी। मैंने कभी यह सुझाव नहीं दिया कि किसी भी चीज को तोड़ दिया जाए। मैं केवल यह कह रहा हूं कि एक जटिल ग्राफ जो बहुत सारे क्रॉसिंग पथों में परिवर्तित हो जाता है, उनका पालन करना मुश्किल है, इसलिए यह आपके इतिहास को काफी साफ रखने में थोड़ा निवेश करने लायक है। यह भी ध्यान दें कि एक रेखीय इतिहास दोष और द्विभाजित जैसे जिट टूल का लाभ उठाने के लिए अधिक अनुकूल है।
jpmc26

6
डॉक्स यह नहीं कहते हैं कि "पुनरावृत्ति न करें।" यह कहता है, "उन परिवर्तनों कोकरें जो अन्य लोगों के ऊपर हैं ।" उन दोनों के बीच अंतर की दुनिया है। लिनुस खुद को इतिहास के आयोजन के लिए कुछ रिबासिंग की सलाह देते हैं , जैसा कि स्वीकृत उत्तर में लिंक में देखा जा सकता है। और किसी भी उपकरण को कैसे पता चलेगा कि कौन-सा अपराध अप्रासंगिक है (विशेषकर यदि उपकरण को गैर-रेखीय इतिहास का विश्लेषण करने में कठिनाई होती है?), और आपको कैसे पता चलेगा कि आप किसके साथ अंतर करना चाहते हैं (विशेषकर इतिहास के माध्यम से खुदाई किए बिना!)। आप एक विशेष स्थिति के बारे में सावधानी बरतने के लिए एक हठधर्मी चरम पर ले जा रहे हैं।
jpmc26

4
आप निश्चित रूप से नहीं चाहते हैं कि "संशोधन का इतिहास रखें" यदि इसमें वह भी शामिल हो जो किसी डेवलपर ने कभी किया हो। उस तर्क के बाद हमें हर बार कोड के मूल संस्करण को रिकॉर्ड करना चाहिए जो बैकस्पेस कुंजी हिट हो गया है। हर एक कम से कम और पूर्ण परिवर्तन होना चाहिए जो अभी भी पूरी परियोजना को स्थिर स्थिति में रखता है। यदि बाद में आपकी मूल प्रतिबद्धता छोटी हो जाती है, तो यह बेहतर है कि किसी अन्य को बनाने की तुलना में कमिट को रिबेट / एडिट / संशोधन करें। हालाँकि, यह भी देखें- mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html
मिको रेंटालीनन

12

आप सही हैं, यह मानते हुए कि आपके पास केवल एक स्थानीय / परिवर्तित भंडार है। हालांकि, उदाहरण के लिए, एक दूसरा स्थानीय पीसी होने पर विचार करें।

एक बार जब आपकी स्थानीय / संशोधित प्रति को कहीं और धकेल दिया जाता है, तो उन प्रतियों को पुन: प्रकाशित कर दिया जाएगा। बेशक, आप जोर लगाने पर मजबूर कर सकते हैं, लेकिन यह जल्दी जटिल हो जाता है। यदि इनमें से एक या एक से अधिक पूरी तरह से नया प्रतिबद्ध है तो क्या होगा?

जैसा कि आप देख सकते हैं, यह बहुत स्थितिजन्य है, लेकिन आधार रणनीति मुझे (गैर-विशेष / सहयोग के मामलों में) बहुत अधिक व्यावहारिक लगती है।


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


1
"विद्रोह के बाद यह बहुत संभावना है कि पुराने कमिट नए बदलावों का पालन कर सकते हैं" - जो विलय के साथ भी होता है, हालांकि, यही कारण है कि आपको (हो सकता है) सुंदर ग्राफ की आवश्यकता होती है। जिस समय एक कमिट किया गया था, वह मर्ज से बहुत पहले हो सकता है जो इसे इस शाखा में लाया था।
स्टीव जेसोप

6

बड़ा कारण शायद यह है कि डिफ़ॉल्ट व्यवहार को पब्लिक रिपॉज में "बस काम" करना चाहिए। अन्य लोगों का इतिहास जो पहले से ही विलय हो चुका है, उसे पुनर्जीवित करने से उन्हें परेशानी होने वाली है। मुझे पता है कि आप अपने निजी रेपो के बारे में बात कर रहे हैं, लेकिन आम तौर पर बोलने वाले को यह नहीं पता है या परवाह नहीं है कि निजी या सार्वजनिक क्या है, इसलिए चुना गया डिफ़ॉल्ट दोनों के लिए डिफ़ॉल्ट होने वाला है।

मैं git pull --rebaseअपने निजी रेपो में काफी उपयोग करता हूं, लेकिन यहां तक ​​कि इसका एक संभावित नुकसान भी है, जो यह है कि मेरे HEADअब तक का इतिहास पेड़ को प्रतिबिंबित नहीं करता है क्योंकि मैंने वास्तव में इस पर काम किया था।

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

मुझे वास्तव में इससे कोई आपत्ति नहीं है, लेकिन यह कुछ लोगों को परेशान करता है: वे पसंद करेंगे कि गिट में उनका इतिहास उस कोड को दर्शाता है जो उन्होंने वास्तव में काम किया था (या शायद जब तक वे इसे धक्का देते हैं, कुछ उपयोग के बाद सच्चाई का एक सरल संस्करण। "तय" के)।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.