65

नीचे दिए गए परिदृश्य के साथ git कैसे मदद करता है:

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

बैकएंड परिवर्तन शाखा से परिवर्तन शाखा को हटाने के लिए परिवर्तनों में खींचने का सबसे अच्छा तरीका क्या है, जबकि यह अभी भी समीक्षा की जा रही है?

git branching

— sul4bh
स्रोत

14

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

— हेर डर्ब

17

@ हेरडेब ओह स्वीट समर चाइल्ड ...

— गार्डेन

4

आप इसे अपने अब तक के समीक्षा किए गए बैकएंड कोड के खिलाफ क्यों नहीं लिख सकते हैं?

— user253751

क्या आपकी टीम के पास इस स्थिति को संभालने के लिए किसी प्रकार की सहमति-युक्त तकनीक है? यदि नहीं, तो शायद आपको कुछ इस तरह से सहमत होना चाहिए, क्योंकि यह काफी सामान्य स्थिति है।

— राडू मुरझिया

वहां कोई नहीं है। यही कारण है कि मैंने यह सवाल पूछा। मुझे बहुत अच्छे सुझाव मिले। मैं सुझावों की कोशिश करूंगा और देखूंगा कि वे मेरे लिए कैसे काम करते हैं।

— sul4bh

42

मुझे भी कभी-कभी यह समस्या होती है। गिट बहुत लचीला है। एक तरीका यह है कि आप इसे कर सकते हैं।

आपकी पहली शाखा featureAसमीक्षा के लिए तैयार है।

आपकी दूसरी शाखा featureBविकास में है और featureAशाखा में कोड पर निर्भर करती है ।

featureAशाखा को शाखा में मिलाएं featureB।

यदि आप featureAशाखा में परिवर्तन करते हैं तो आपको परिवर्तनों को सम्मिलित करने के featureAलिए featureBशाखा को फिर से शाखा में मिलाना चाहिए ।

आपको featureAपहले मुख्य ट्रंक में विलय करना भी सुनिश्चित करना चाहिए , अन्यथा जब आप featureBमुख्य ट्रंक में विलय करते हैं तो आप अनजाने में भी विलय कर देंगे featureA। एक बार featureAमुख्य ट्रंक में विलय होने के बाद आप featureAशाखा से छुटकारा पा सकते हैं क्योंकि featureBकेवल मुख्य ट्रंक पर निर्भर करता है।

मैं इसे पसंद करता हूं जब मेरी सुविधा शाखाएं एक दूसरे पर निर्भर नहीं होती हैं लेकिन कभी-कभी वे करते हैं और आपको इसके साथ रोल करना पड़ता है।

— मैट
स्रोत

यह समझ में आता है। क्या यह आवश्यकता होने featureAपर विलय को पूर्ववत करने की अनुमति देता featureBहै?

— sul4bh

8

कोई पूर्ववत ऑपरेशन नहीं है, लेकिन @ 9000 उल्लेख के रूप में, आप एक नई शाखा बना सकते हैं और चेरी उस कमिट को चुन सकते हैं, featureAजिसमें से आप फिर से शुरू करना चाहते हैं । Git शाखाओं को डिस्पोजेबल के रूप में सोचना अच्छा है। वे सस्ते और आसान हैं, आप हमेशा एक नई शाखा बना सकते हैं। आप अपनी शाखा से एक परीक्षण शाखा भी बना सकते हैं featureBयदि आप किसी ऐसी चीज के साथ खेलना चाहते हैं जिसके बारे में आप निश्चित नहीं हैं, और फिर इसे स्क्रैप करें यदि यह काम नहीं करता है, या इसे अपनी featureBशाखा में वापस मर्ज करें यदि ऐसा हुआ।

— मैट

9

विलय से एक ऐसी गड़बड़ी पैदा होगी जो रोल-बैक में मुश्किल (असंभव नहीं) होगी। मैं चेरी-पिक या रिबास (यानी: फीचरबी के बेस पर फीचर ए में चेरी-पिक सब कुछ) को रिगर्स करूंगा। 9000 का जवाब देखें।

— पियरे.सोउलासस

1

यह एक जटिल इतिहास बनाता है जो आने वाले कई वर्षों के लिए एक समस्या होगी जब भी कोई यह समझना चाहता है कि फीचर और फीचरबी के लिए क्या कोड बदला गया था

— इयान

2

यदि featureA अद्यतन किया जाता है, featureB रिबेस किया जाना चाहिए नहीं विलय कर दिया

— लिंडन व्हाइट

39

मर्ज करना छोड़ें, मर्ज करना छोड़ें

इस दृष्टिकोण के लिए, आप है नहीं अपने मर्ज करना चाहते हैं feature_aमें feature_bबार-बार।

रिबासिंग का उल्लेख अन्य उत्तरों में किया गया है, लेकिन केवल चीजों को रिबास करने के लिए master। आप अपने मामले में क्या करना चाहते हैं:

अपने feature_bसे शुरू feature_a, यानी:
```
git checkout feature_a
git checkout -b feature_b
```
जब भी feature_aपरिवर्तन करते हुए इसे इंतज़ार कर रहा है में विलय करने के लिए master, आप rebase feature_b इस पर:
```
... commit something onto feature_a ...
git checkout feature_b
git rebase feature_a
```
अंत में, जैसे ही feature_aमें विलय कर दिया गया है master, आप बस नई प्राप्त करते हैं masterऔर feature_aउस पर अंतिम बार रीबेस करते हैं:
```
git checkout master
git pull origin master
git checkout feature_b
git rebase --onto master feature_a feature_b
```
यह अंतिम छूट सभी कमिट्स को ग्रिप करेगा feature_aजो कमिट से झूल रहे हैं (जो अब अप्रासंगिक है क्योंकि इसे masterसही में विलय कर दिया गया है ) master। आपका feature_bअब एक सरल, मानक शाखा है जो सही से जा रही है master।

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

— AnoE
स्रोत

2

feature_aकई बार रिबासिंग के साथ , आप बाद में समस्याओं में भाग सकते हैं, जब feature_aइस बीच खुद को रिबेट किया गया हो। दौड़ने के परिणामस्वरूप git checkout feature_b; git rebase feature_aआपको संघर्ष हो सकता है या कुछ मज़ेदार कमिट्स आ सकते हैं जिनमें नए बदलावों का सम्मान करना चाहिए feature_a। यह आमतौर पर --interactiveअन्य शाखा के पुराने संस्करण से लिए गए उपयोग और लंघन द्वारा हल करने योग्य है (मुझे हाल ही में यह कई बार करना पड़ा)।

— मातरिनस

@maaartinus, हेड-अप के लिए धन्यवाद, मैं खुद इस तरह के मुद्दों में नहीं गया हूं। जैसा कि rebaseएक साधारण से कई अधिक व्यक्तिगत कदम हैं merge, निश्चित रूप से संघर्ष पैदा करने के लिए यह एक उच्चतर संभावना है; दूसरी ओर mergeइस मामले में बस शब्दार्थ करना काफी गलत होगा।

— AnoE

मुझे लगता है, mergeसमान या बदतर समस्याएं होंगी (एक अवांछित बदलाव में एक संघर्ष उतना बुरा नहीं है)। मैं एक शाखा को कई असंबंधित परिवर्तनों से पहले वांछित परिवर्तनों के अनुक्रम के रूप में देखता हूं (तार्किक रूप से एक अलग शाखा से संबंधित)। जब एक ही शाखा के साथ बार-बार रिबासिंग होती है, तो मैं हमेशा असंबंधित परिवर्तनों को हटा देता हूं क्योंकि मुझे पता है कि वे वैसे भी (संभवतः एक अद्यतन आकार में) आएंगे और यह ठीक काम करता है।

— मआर्टिनस

1

@maaartinus, मैंने इसके बारे में एक छोटा सा परिशिष्ट जोड़ा है (लगातार परिवर्तन करने के लिए जिन्हें केवल आधार शाखा में दोनों शाखाओं में जाने की आवश्यकता है, दो अलग-अलग कमिटों में नहीं)।

— AnoE

अच्छी तकनीक है। यह है कि मैं हमेशा यह कैसे करता हूं। git rebase --onto

— एफटीडब्ल्यू

29

आपके पास पहले से ही एक शाखा है जिस पर आपकी हर सुविधा शाखा निर्भर करती है, और जो बदलती रहती है। इसे कहते हैं master।

एक सुविधा शाखा के साथ सिंक में रहने का विशिष्ट तरीका इसके शीर्ष परmaster रहना है। जब परिवर्तन होता है, तो आप सामान्य रूप से अपनी शाखा की कार्यशील निर्देशिका में होते हैं।mastergit fetch origin master:master && git rebase master

आप एक ही सुविधा शाखा के साथ एक ही काम कर सकते हैं: इसे लाते रहें और इसके शीर्ष पर रिबासिंग करें।

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

— 9000
स्रोत

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

— सिनास्टेटिक

@Sinaesthetic: आप इस पाठ्यक्रम के आधार के कर सकते हैं feature-bपर feature-a, और के रूप में समय के बाद एक रिबेस समय feature-aबदल रहा है। यह एक बड़े बदलाव को देखने योग्य बनाने के लिए एक विशिष्ट तरीका है: इसे part-A(आधारित बंद master), part-B(आधारित बंद part-A), और यदि आवश्यक हो तो विभाजित करें । फिर प्रत्येक भाग के लिए एक पुल अनुरोध करें, और समीक्षकों के पास छोटे, तार्किक रूप से समूहीकृत टुकड़ों को देखने में आसान समय है।

— 9000

क्या यह मायने रखेगा अगर मैं PR के संदर्भ में मास्टर के साथ पार्ट-ए बनाम पार्ट-बी के साथ पार्ट-बी को रिबेट करता हूं? मैं सिर्फ यह सुनिश्चित करना चाहता हूं कि मेरे बदलाव पार्ट-बी में बदलाव के रूप में भाग-एक बदलाव नहीं दिखा रहे हैं। इसके अलावा, यदि मैं बनाम रिबेस को मर्ज करता हूं, तो यह भाग-बी पीआर को कैसे प्रभावित करेगा? हर बार मुझे लगता है कि मैं प्रभावों को समझते हैं, मैं कुछ अलग परिणाम प्राप्त lol

— Sinaesthetic

5

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

एक सुविधा शाखा जो लंबे समय तक जीवित रहती है, उसे मास्टर से परिवर्तन में विलय करने की आवश्यकता होती है (यह सुनिश्चित करने के लिए कि आप "समीक्षा, क्यूए, मर्ज-" के भाग के बजाय सुविधा शाखा पर देव कार्य के भाग के रूप में किसी भी मर्ज या शब्दार्थ संघर्ष को समेट लें) मास्टर करने के लिए "प्रक्रिया)। तो आप ऐसा करते हैं कि आपकी फ्रंट एंड ब्रांच पर, और जब बैकएंड कार्य को मास्टर करने के लिए स्वीकार कर लिया गया है, तो आपको अपने रिव्यू / स्वीकृति के तहत बैकएंड में किए गए किसी भी छोटे बदलाव को स्वचालित रूप से उसी मार्ग से करना होगा जो आप कर रहे हैं! मास्टर पर कोई अन्य कोड परिवर्तन प्राप्त करें।

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

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

— बेन
स्रोत

2

मुझे यहां समस्या नहीं दिख रही है।

आपके पास अपनी masterशाखा के साथ हर बार यह पहले से ही है , जो सुविधाओं के विकसित होने और फिर विलय होने पर बदलता रहता है।

इसलिए, अपने ठोस उदाहरण में, आप सबसे पहले feature_xxx_backendशाखा बनाते हैं और बैकएंड परिवर्तन विकसित करते हैं। जब यह किया जाता है, तो शाखा की समीक्षा की जाती है और masterसमीक्षा पूरी होने के बाद इसे विलय कर दिया जाएगा ।

तो, बस, एक और शाखा शुरू feature_yyy_frontend। आप शायद सीधे से शाखा करना चाहेंगे feature_xxx_backend, ताकि आपके पास अपने ब्रांक्स में पहले से ही वे बदलाव हों। फिर बस शाखा के सामने दृश्य सुविधा विकसित करें master।

जब feature_xxx_backendशाखा बदलती है, उदाहरण के लिए क्योंकि समीक्षा के दौरान आने वाली चीजें होती हैं, जिन्हें स्वीकार करने की आवश्यकता होती है, बस इन परिवर्तनों को करें और उन्हें feature_yyy_frontendशाखा में विलय कर दें । फिर आगे की शाखा पर जारी रखें।

बैकएंड ब्रांच की समीक्षा पूरी होने के बाद, यह विलय हो जाता है master। इस बिंदु पर, यह करने के लिए बुद्धिमान होगा rebasefeature_yyy_frontend पर शाखा master, ताकि समीक्षक केवल समीक्षा करने की आवश्यकता नया परिवर्तन है कि इस शाखा में योगदान देता है master, और करने की जरूरत नहीं बैकएंड के लिए किए गए परिवर्तनों (जो पहले से ही अनुमोदित किया गया है फिर से समीक्षा )।

यह तब भी किया जा सकता है जब आपके पास दो, तीन या अधिक आश्रित शाखाएँ हों। यदि आपके पास दो फ़ीचर शाखाएँ हैं, जिन पर आप निर्भर हैं, सरल एक व्युत्पन्न शाखा बनाते हैं, जिसमें दोनों फ़ीचर मर्ज हो गए हैं। वहाँ से ब्रांच, तीसरी फ़ीचर को विकसित करें, दोनों फ़ीचर ब्रांचों को मर्ज करने का तरीका जब उनमें से प्रत्येक बदल जाए। जब दोनों विशेषताएं हो जाती हैं और या तो व्युत्पन्न शाखा में विलीन हो जाती हैं, तो उस पर रिबास, या यदि वे मास्टर में विलय हो जाते हैं, तो मास्टर के लिए रिबेस करें।

रिबासिंग (जैसा कि ऊपर सुझाव दिया गया है) वास्तव में शक्तिशाली है और परिवर्तनों की एक साफ लॉग रखने में मदद करता है, जिससे समीक्षा बहुत आसान हो जाती है।

— Polygnome
स्रोत

2

जैसा कि पॉलिग्नोम ने उल्लेख किया है, आप वास्तव में मास्टर्स के बजाय अपनी बैकेंड शाखा के साथ अपनी फ्रंटेंड शाखा को मर्ज कर सकते हैं। यहां तक कि वर्तमान शाखा सेटअप के साथ भी, आप बस कर सकते हैं:

git checkout frontend
git merge backend

या केवल

git merge backend frontend

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

तकनीकी तौर पर आप भी सब कुछ रिबास के साथ कर सकते हैं, लेकिन यह आपके फ्रेंड ब्रांच के प्रतिबद्ध इतिहास को गड़बड़ कर देगा। जहां से मैं आ रहा हूं, यह बुरा अभ्यास माना जाता है। YMMV

— जोरिस मे
स्रोत

"अजीब कोई भी उल्लेख किया है कि कि आप वास्तव में स्वामी के बजाय अपने बैकएंड शाखा के साथ अपने दृश्यपटल शाखा विलय कर सकते हैं:" यह है पहले ही उल्लेख किया गया है, अपने खुद के जवाब में जैसे।

— बहुपत्नी

@ पॉलीगोमेन फ्रंटेंड को बैकएंड से सीधे ब्रंच नहीं करना पड़ता है। वे दोनों मास्टर के रूप में अच्छी तरह से शाखित हो सकते हैं, लेकिन आप अभी भी उन्हें मर्ज कर सकते हैं। तो आपके जवाब में यह उल्लेख नहीं है कि वास्तव में।

— जोरिस मेय्स

वास्तव में, मेरा जवाब यह नहीं बताता है कि आप सीधे बैकएंड से शाखा करते हैं, यह सिर्फ साईज़ है कि शायद जाने का मार्ग है (क्योंकि आप उन परिवर्तनों को सीमांत शाखा में वैसे भी विलय कर देते हैं)।

— पॉलीगोमैन

@Polygnome तो मैं अपने जवाब गलत समझा। विशेष रूप से आपके लिए अपडेट किया गया :-)

— जोरिस मेय्स

मुझे नहीं पता कि किसने इसे अस्वीकार किया है, लेकिन कृपया मुझे बताएं कि मैं कहां गलत हूं, इसलिए मैं भी कुछ सीख सकता हूं।

— जोरिस मेय्स

1

यहां अधिकांश उत्तर सही ढंग से दूसरी शाखा से पहली में परिवर्तन को मर्ज करने की प्रक्रिया का वर्णन करते हैं, लेकिन वे यह पता नहीं लगाते हैं कि संघर्ष की मात्रा को कैसे कम करना है जिसे आपको हल करने की आवश्यकता हो सकती है।

जब भी आपके पास बड़े बदलावों के दो सेट होते हैं जिन्हें आप व्यक्तिगत रूप से (जैसे featureAऔर featureB) समीक्षा करना चाहते हैं , तो एक पीआर बनाएं जो विलय होने का नहीं है, लेकिन पीओसी के प्रारंभिक फीडबैक को इकट्ठा करने के लिए है featureA।

लोग इसकी शीघ्र समीक्षा कर सकेंगे (यह सिर्फ एक PoC है), और इसका उद्देश्य सामान्य डिज़ाइन या दृष्टिकोण को मान्य करना है।

फिर, आप फीचर A पर काम कर सकते हैं, इसके लिए एक पुल अनुरोध बना सकते हैं और शाखा और फीचर B पर काम कर सकते हैं।

बड़ा अंतर यह है कि अब आप featureAमौलिक रूप से नहीं बदलने की उम्मीद कर सकते हैं : डिजाइन और दृष्टिकोण पहले से ही मान्य थे। कोड की समीक्षा और आवश्यक परिवर्तन "woops के बजाय सूक्ष्म और स्थानीय हो सकते हैं, आपको एक अलग दृष्टिकोण की आवश्यकता है"। यह काम है कि आप बाद में मर्ज करने के लिए क्या करने की जरूरत की राशि को कम कर देंगे featureBपर featureAकी कोड, विधि की परवाह किए बिना अपने द्वारा चुने गए।

— अल्फा
स्रोत

जिस शाखा की समीक्षा की जा रही है, उस शाखा पर निर्भरता के साथ कार्य करना

मर्ज करना छोड़ें, मर्ज करना छोड़ें