2012-02-02 18 views
18

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

मान लें कि मेरी फीचर शाखा को "new_feature" कहा जाता है। "विकसित" शाखा के साथ यह मर्ज करने के लिए मेरे प्रक्रिया इस प्रकार है:

git checkout develop 

git pull (this is set up on our rig to always pull rebase) 

git checkout new_feature 

git rebase develop 

(lots of merge conflicts ensue) 

git checkout develop 

git merge -no-ff new_feature 

(same set of merge conflicts again) 

यह समय मेरे रिबेस से परिवर्तित करता है दर्पण की तरह करने के लिए अपने नए फीचर शाखा सभी तरह वापस विकसित कारण के रूप में है, और फिर संघर्ष का विकास खुद की एक psudo-copy के साथ।

+3

क्यों 'git merge -no-ff'? यदि आपने अभी विकास पर new_feature को रीबेस किया है, तो यह _should_ एक तेज़-आगे हो। – Useless

+0

मैं ईमानदारी से यकीन नहीं कर रहा हूँ। थोड़ी देर के लिए, हमारे यहां एक लड़का था जो वास्तव में गिट को जानता था, और उसने मुझे बताया कि मुझे ऐसा कुछ कारणों से करना चाहिए जो समय रेखा को साफ करने के साथ करना है। मुझे वास्तव में पता नहीं था कि कारण क्या था। –

+1

मैं देख सकता हूं कि यह समयरेखा भ्रमित कर सकता है ... हम्म। रिबेज सभी कामों को 'new_feature' पर बदलकर मूल शाखा बिंदु के बजाय' विकास 'पर लागू समकक्ष परिवर्तनों के साथ बदल रहा है, जिसका अर्थ है कि आपको पुराने कामों की प्रतियां मिलेंगी, जिनके माता-पिता (मूल शाखा बिंदु और' विकास के बीच/HEAD') उनके से बड़े हैं। – Useless

उत्तर

29

ठीक है, यह अब एक टिप्पणी के लिए बहुत लंबा है।

पहले rebase चलाने के बाद मैनुअल (git help rebase)

Assume the following history exists and the current branch is "new_feature": 

       A---B---C new_feature 
       /
      D---E---F---G develop 


    From this point, the result of either of the following commands: 

     git rebase develop 
     git rebase develop new_feature 

    would be: 

         A'--B'--C' <new_feature 
         /
      D---E---F---G <develop 

व्याख्या करने के लिए अब, अगर आप संघर्ष किया था, वास्तविक राज्य

   A'--B'--C'--[local state] 
      / ^
D---E---F---G   new_feature 
      ^develop 

हो जाएगा जहां [local state] विरोध हुआ मर्ज आप अभी तक है ठीक करने के लिए। वापस अब अपने राज्य हो जाएगा

   A'--B'--C'--H <new_feature 
      /
D---E---F---G <develop 
इस बिंदु विलय new_feature पर

जाहिर है पर विकसित इतना की तरह तेजी से अग्रेषित किया जा सकता है: एक बार जब आप मर्ज संघर्ष का समाधान और सूचकांक का संकल्प लिया फ़ाइलें जोड़ लेते हैं तो चलाने git rebase --continue :

   A'--B'--C'--H <new_feature <develop 
      /
D---E---F---G 

लेकिन यदि ऐसा नहीं है तो आप इसके बजाए

   A'--B'--C'--H <new_feature 
      /   \ 
D---E---F---G---------------I <develop 

अब इनमें से जो भी आप एक से पसंद करते हैं मिल जाएगा समयरेखा परिप्रेक्ष्य, यह स्पष्ट नहीं है कि या तो समस्या क्यों होगी ... जब तक कि आपने कभी भी रीबेज पूरा नहीं किया और H के साथ संघर्षों का समाधान नहीं किया, लेकिन मुझे लगता है कि गिट इसके बारे में शिकायत करेगा।

+0

पढ़ने की अनुशंसा करता हूं "लेकिन यदि ऐसा नहीं है तो आप इसे इसके बजाय प्राप्त करेंगे"? "नहीं है" क्या? मुझे समझ में नहीं आता कि इन परिदृश्यों में से किसी एक का कारण कैसे बनना है। क्या अंतर था? – Umagon

+1

"_... तेजी से अग्रेषित किया जा सकता है ... लेकिन अगर यह नहीं है ..._"। यदि आप '--no-ff' के साथ विलय को तेज़ी से आगे नहीं बढ़ाना चुनते हैं, तो आपको चित्र सूचक के रूप में केवल शाखा सूचक को स्थानांतरित करने के बजाय विलय प्रतिबद्धता मिलती है। यदि आप पहले स्थान पर परिदृश्य को नहीं समझते हैं, तो आपको शायद अपने खुद के प्रश्न पूछने की ज़रूरत है या अन्यथा गिट के बारे में और जानना चाहिए, क्योंकि मैं वास्तव में अनुमान नहीं लगा सकता कि यह जवाब आपको कहां खो गया है। – Useless

4

मुझे लगता है जैसे आप पीछे की ओर रीबेस का उपयोग कर रहे हैं लेकिन यह सिर्फ एक भ्रमित वाक्यांश हो सकता है।

मैं फीचर शाखा को पर विकसित कर दूंगा और फिर (विकास पर) git merge --ff-only feature कर दूंगा।

+0

मैं प्रक्रिया को दिखाने के लिए अपनी पोस्ट को संपादित करने पर काम कर रहा हूं, यह देखने के लिए कि क्या मुझे यह गलत लगता है या नहीं। –

+1

@Useless टिप्पणी के रूप में, विलय एक तेजी से आगे होना चाहिए (मैं केवल - केवल -फ का उपयोग करके इसे मजबूर करना पसंद करता हूं)। बाकी सब ठीक लगता है हालांकि शब्दों में इसे डालने का आपका तरीका मानक नहीं है। मैं http://progit.org/book/ – madth3

-1

चूंकि आप एक ही प्रश्न में "बड़े पैमाने पर" और "रिबेस" निर्दिष्ट कर रहे हैं, इसलिए मैं आपको ऐसा करने की सलाह दूंगा। इसके बजाए विलय का प्रयोग करें।

मूल शाखा बिंदु को संरक्षित करने के उद्देश्य से विलय में नोनो-एफएफ का उपयोग करना बहुत अच्छा है। मैं इसका उपयोग करने का समर्थन करता हूं।

संबंधित मुद्दे