फीचर शाखाओं से मास्टर में विलय से पहले कोड की समीक्षा के लिए रणनीति

Question

मैं और मेरी टीम फीचर शाखाओं (गिट के साथ) का उपयोग करते हैं। मुझे आश्चर्य है कि मास्टर में विलय से पहले कोड समीक्षा के लिए सबसे अच्छी रणनीति कौन सी है।

1. मैं मास्टर से एक नई शाखा की जाँच करता हूँ, इसे fb_ # 1 कहता है
2. मैं कुछ समय के लिए प्रतिबद्ध हूं और इसे वापस मास्टर में विलय करना चाहता हूं
3. इससे पहले कि मैं विलय करूं, कोई कोड समीक्षा करने वाला है

अब 2 संभावनाएं हैं:

1

1. मैं विलय मास्टर # 1 fb_ को ( नहीं अप-टू-डेट संभव के रूप में इसे बनाने के लिए मास्टर करने के लिए # 1 fb_)
2. एक टीममेट मास्टर हेड और fb_ # 1 हेड के बीच बदलाव की समीक्षा करता है
3. अगर fb_ # 1 ठीक है, तो हम fb_ # 1 को मास्टर में मर्ज करते हैं
4. पेशेवरों: समीक्षा में कोई अप्रचलित कोड नहीं
5. विपक्ष: अगर कोई और "1." के बीच कुछ मिलाता है और "2." समीक्षा में उनके परिवर्तन दिखाई देते हैं, हालांकि वे दूसरी समीक्षा से संबंधित हैं।

2

1. चेकआउट के बिंदु (गिट मर्ज-बेस मास्टर fb_ # 1) और fb_ # 1 हेड के बीच एक टीममेट बदलाव की समीक्षा करता है
2. पेशेवरों: हम देखते हैं कि फीचर शाखा में काम करने के दौरान क्या बदला गया था
3. विपक्ष: कुछ अप्रचलित कोड समीक्षा में दिखाई दे सकते हैं।

आपको कौन सा तरीका बेहतर लगता है और क्यों ? शायद एक और अधिक उपयुक्त दृष्टिकोण है?

Answer 1

आपके पहले विकल्प की एक विविधता है:

1. मास्टर को fb_ # 1 (fb_ # 1 मास्टर नहीं) को संभव के रूप में अप-टू-डेट बनाने के लिए मर्ज करें
2. एक टीममेट आपके द्वारा विलय किए गए बिंदु पर मास्टर और fb_ # 1 हेड के बीच परिवर्तनों की समीक्षा करता है
3. अगर fb_ # 1 ठीक है, तो हम fb_ # 1 को मास्टर में मर्ज करते हैं
4. त्वरित जाँच करें कि मर्ज ठीक है

जैसे।

... ma -- ... -- mm -- ... -- mf  <- master
      \            \         /
       f1 ... fn -- fm -----      <-- fb_#1

कहा पे:

• ma , गुरु का पूर्वज है और fb_ # 1।
• fn आपकी शाखा पर अंतिम परिवर्तन है
• मिमी वह प्रतिबद्ध है जो उस समय मास्टर / HEAD था जब आप अपनी शाखा में विलय हुए थे ( fm देते हुए )।

तो, आप अपनी प्रारंभिक समीक्षा में मिमी और एफएम की तुलना करते हैं, और फिर कदम 1-3 के दौरान मास्टर पर कुछ भी महत्वपूर्ण परिवर्तन सुनिश्चित करने के लिए वापस एमएफ विलय के बाद जल्दी से जांच नहीं करते हैं। ऐसा लगता है कि शुरुआती समीक्षा के लिए सभी पेशेवरों और विपक्षों में से कोई भी नहीं है।

यह मानता है कि मास्टर को धकेल दिए गए परिवर्तनों की सामान्य आवृत्ति की तुलना में समीक्षा जल्दी होती है, इसलिए fm -> mf अक्सर एक तेज़-फ़ॉरवर्ड होगा।

यदि ऐसा नहीं है, तो किसी भी कारण से, विपक्ष प्रारंभिक समीक्षा से मर्ज-मर्ज की समीक्षा के लिए आगे बढ़ जाएगा, और यह सीधे मास्टर पर विलय करने और वहां एक ही समीक्षा करने के लिए सरल हो सकता है।

Comments

मुझे "आपके द्वारा मर्ज किया गया बिंदु" कैसे मिलेगा? क्या "गिट मर्ज-बेस मास्टर हेड" ठीक होगा, या यह प्रारंभिक शाखा बिंदु दिखाएगा?

— आंद्रेज गिस

जब तक आप मर्ज के बाद जानबूझकर मास्टर को अपडेट नहीं करते हैं, यह सिर्फ मास्टर होगा।

— बेकार

हां, लेकिन अगर कोई और इसे अपडेट करता है तो उस बिंदु को कैसे प्राप्त करें?

— आंद्रेज जिस

जब आप fb शाखा पर हों, का उपयोग करें git show HEAD। चूंकि यह मर्ज कमिटमेंट एफएम होगा, यह माता-पिता दोनों को सूचीबद्ध करेगा । तो, आपके पास मिमी का हैश है । वैकल्पिक रूप से, आप मूल रूप से या किसी अन्य गिट ब्राउज़र में मूल रूप से देख सकते हैंgitk

— बेकार

Answer 2

3

• आप rebase दोनों मेकअप यह अप करने की तारीख करने के लिए मास्टर पर शाखा और परिवर्तन को अलग रखने।

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

• आप पुन: व्यवस्थित करने के लिए इंटरएक्टिव रिबेस ( git rebase -iऔर git commit --amend) का उपयोग करते हैं , परिवर्तनों को संपादित करते हैं और साफ करते हैं ताकि प्रत्येक तार्किक रूप से बंद हो जाए।

  यह फिर से नया इतिहास बनाता है, इस बार अतिरिक्त लाभ के साथ कि आप समीक्षा के दौरान सबसे अधिक समझ बनाने के लिए परिवर्तनों का पुनर्गठन कर सकते हैं।

• पेशेवरों:

  • समीक्षा में कोई अप्रचलित कोड नहीं
  • हम देखते हैं कि फीचर शाखा में काम करने के दौरान क्या बदला गया था
• विपक्ष:
  • थोड़ा और काम
  • आपको इस बात का ध्यान रखना होगा कि जो कुछ भी पहले से विलय हो गया है या जो आपने साझा किया है उसे वापस न करें और प्राप्तकर्ता को इसके फिर से आने की उम्मीद न हो।

आमतौर पर अतिरिक्त काम का मतलब है कि आप पहले अपने आप को पूरी तरह से कोड की समीक्षा करते हैं और यह कई समस्याओं को भी पकड़ लेगा।

यही लिनक्स और Git करते हैं। और उन परियोजनाओं में कई बार समीक्षा के लिए 20 से 25 पैच की श्रृंखला को देखना असामान्य नहीं है और इसे फिर से लिखा गया है।

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

Comments

+1 भी ओपी ने अगले चरणों के बारे में नहीं पूछा, लेकिन मास्टर में अपनी सुविधा प्राप्त करने के लिए आप एक ऐसा उपयोग कर सकते हैं merge --no-ffजो स्पष्ट रूप से बाकी कमिट्स में गायब होने वाली सुविधा के बजाय मास्टर पर उस शाखा को दिखाएगा

— stijn

@stijn: --no-ffयह ऊपर और नीचे है। मैं व्यक्तिगत रूप से इसे किसी भी चीज़ से अधिक शोर लगता है। YMMV।

— Jan Hudec

हाँ, यह वरीयता की बात है .. यदि मास्टर सामान्य रूप से साफ और सीधा है तो मुझे अलग 'बबल' वाली बड़ी विशेषताओं से ऐतराज नहीं है। तो मास्टर एक मेस पहले से ही है, कोई-एफएफ केवल यह बदतर बना देता है

— टिजिन

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

— आंद्रेज गिस

दूसरा Con - मुझे नहीं लगता कि आप ऐसा कर सकते हैं यदि आपने पहले ही अपनी शाखा किसी के साथ साझा की है। जब आप इतिहास को फिर से लिखेंगे तो विसंगतियां होंगी।

— साठफुटेरसुडे

Answer 3

जीआईटी एक SCM कार्यप्रणाली के कार्यान्वयन की तुलना में SCM फ्रेमवर्क के कार्यान्वयन से अधिक है, क्योंकि वास्तव में एक तीसरी कब्ज़ है- और सबसे अधिक दूसरों के लिए बहुत संभव है। यह तीसरी संभावना पर आधारित है rebase।

rebaseGIT subcommand (अपने विषय शाखा की नोक के लिए अपने शाखाओं बिंदु से आम तौर पर प्रतिबद्ध की एक श्रृंखला लेता है topic) और उन्हें कहीं और पुन: चलाने के (आमतौर पर अपने एकीकरण शाखा की नोक, जैसे पर master)। rebaseSubcommand नई करता है, जो एक प्रपत्र समीक्षा करना आसान है कि में प्रतिबद्ध उलटफेर का अवसर देता है पैदा करता है। यह एक नई श्रृंखला की उपज देता है, जो topicकि एकीकरण शाखा के शीर्ष पर निहित होने के समान है । इस नई शाखा को अभी भी topicजीआईटी द्वारा बुलाया जाता है, ताकि पुराने संदर्भ को छोड़ दिया जाए। मैं अनौपचारिक topic-0रूप से आपकी शाखा की मूल स्थिति को लेबल करता हूं topic-1और इसी तरह इसके विभिन्न रीफैक्टरिंग पर।

यहाँ आपकी topicशाखा के लिए मेरा सुझाव है :

1. (वैकल्पिक कदम) आप सहभागी अपने विषय शाखा rebase topicअपनी शाखाओं मुद्दे पर (देखें --fixupके लिए विकल्प commitऔर -iऔर --autosquashपर विकल्प rebase) है, जो आप एक तरह से समीक्षा करने के लिए आसान है कि में अपने प्रतिबद्ध पुनर्लेखन के लिए अवसर देता है। इससे एक शाखा निकलती है topic-1।

2. आप अपनी विषय शाखा को अपनी एकीकरण शाखा में सबसे ऊपर रखते हैं, एक मर्ज करने के समान है, लेकिन एक मर्ज के साथ इतिहास को प्रदूषित नहीं करता है, जो केवल एक सॉफ्टवेयर इंजीनियरिंग विरूपण साक्ष्य है। इससे एक शाखा निकलती है topic-2।

3. topic-2एक टीम के साथी को भेजें जो इसे टिप के खिलाफ समीक्षा करता है master।

4. यदि topic-2ठीक है तो इसे मास्टर में विलय करें।

नोट शाखाएँ - जहाँ शाखा प्रतिबद्ध वृक्ष को संदर्भित करती है - सभी को GIT द्वारा समान कहा जाएगा, इस प्रकार, प्रक्रिया के अंत में, केवल शाखा topic-2का GIT में एक नाम होता है।

पेशेवरों:

• समीक्षा में कोई अप्रचलित कोड नहीं।
• कोई सहज "विदेशी मर्ज" समीक्षा (आप 1 में वर्णित घटना)।
• स्वच्छ तरीके से फिर से लिखने का अवसर।

विपक्ष:

• एक शाखा के बजाय topic-0, तीन शाखाएँ कलाकृतियाँ हैं topic-0, topic-1और topic-2जो प्रतिबद्ध वृक्ष में बनाई गई हैं। (हालांकि किसी भी समय, उनमें से केवल एक का नाम जीआईटी में है।)

आपके 1 परिदृश्य में «अगर किसी ने" 1. "के बीच कुछ मिला दिया है और "2." »शाखा बिंदु के निर्माण और उस समय के बीच फैले समय को संदर्भित करता है जब आप विलय करने का निर्णय लेते हैं। इस परिदृश्य में «अगर किसी ने" 1. "के बीच कुछ विलय कर दिया है और "2." »रिबास और मर्ज के बीच फैले समय को संदर्भित करता है, जो आमतौर पर बहुत कम है। इस प्रकार, मेरे द्वारा प्रदान किए गए परिदृश्य में, आप «लॉक» masterमर्ज के समय के लिए शाखा को अपने वर्कफ़्लो के बिना सांकेतिक रूप से परेशान कर सकते हैं, जबकि यह 1 परिदृश्य में अव्यावहारिक है।

यदि आप व्यवस्थित कोड समीक्षा कर रहे हैं, तो संभवतः पर्याप्त तरीके (वैकल्पिक चरण) में कमिट को पुनर्व्यवस्थित करना एक अच्छा विचार है।

मध्यवर्ती शाखा कलाकृतियों का प्रबंधन केवल एक कठिनाई प्रस्तुत करता है यदि आप उन्हें रिपॉजिटरी के बीच साझा करते हैं।

Comments

नहीं topic-0, topic-1और topic-2शाखाएं होनी चाहिए । दूसरा रिबास पूरा हो गया है, पिछला संस्करण अप्रासंगिक है। तो सब वहाँ होगा topic@{1}, topic@{2}, topic@{yesterday}, topic@{3.days.ago}आदि अपने बट मामले में आप पाते हैं आप रिबेस में संघर्ष समाधान खराब कर दिया है को बचाने के लिए।

— Jan Hudec

तीन शाखाएं मौजूद हैं, लेकिन उनका कोई नाम (कोई रेफरी) नहीं है। शायद मुझे इस पर जोर देना चाहिए।

— माइकल ले बारबियर ग्रुएनवाल्ड

संशोधन मौजूद हैं और रिफ्लग प्रविष्टियों द्वारा इंगित किए गए हैं। लेकिन शाखाओं के रूप में सिर्फ एक, है topic। क्योंकि गिट में शाखा सिर्फ नाम है।

— Jan Hudec

यह मुझे "विदेशी मर्ज" से कैसे बचाता है? क्या होगा यदि कोई व्यक्ति टीम -२ में विषय भेजने के बाद किसी मास्टर में विलीन हो जाता है और यह कि टीम का साथी इसे मास्टर की टिप के खिलाफ बताता है?

— आंद्रेज गिस

@JanHudec किसी भी समय, वहाँ केवल एक ही शाखा कहा जाता है topicGIT में यह हमेशा शाखाओं में से एक (एक शाखा के रूप में GIT संदर्भ में के रूप में नहीं, पेड़ प्रतिबद्ध) मैं लेबल है, topic-0, topic-1, topic-2।

— माइकल ले बारबियर ग्रुएनवाल्ड