दूसरी नई समीक्षा होने पर गेरिट में समीक्षा समस्याओं में संशोधन कैसे करें

Question

अभी भी सीखने की कोशिश कर रहा है कि गेरिट और इसकी प्रक्रिया का उपयोग कैसे करें। कदम मैंने किया था जहां

1. पुश पहले change1 सिर पर समीक्षा के लिए Gerrit रहे हैं: refs/के लिए/एक ही शाखा पर कुछ और पर
2. कार्य को विकसित करने और change2 धक्का सिर पर समीक्षा के लिए Gerrit करने के लिए: के लिए refs// विकसित

दोनों प्रतिबद्ध

Gerrit है बदलें आईडी लाइनों तो अब मैं change1 के लिए मुद्दे के समाधान करना चाहते हैं तो मैं

था

git checkout -b change1 <change 1's commit id> 

मेरी परिवर्तन किए और प्रतिबद्ध

git add . 
git commit 

(प्रतिबद्ध संदेश को बदलें-आईडी जोड़कर) अब जब मैं

git push origin HEAD:refs/for/develop 

मैं

! [remote rejected] HEAD -> refs/for/develop (squash commits first) 
error: failed to push some refs to 'ssh://adrian@192.168.7.100:29418/CommunicationsLibrary' 

मिल कैसे करते हैं मैं स्टैक्ड समीक्षाओं में मुद्दों को ठीक करता हूं और इसे फिर से एक और समीक्षा के बिना gerrit पर पोस्ट करता हूं?

Answer 1

जब आपके पास गेरिट में निर्भर समीक्षा है (यानी, समीक्षा में एक बदलाव जो पहले के परिवर्तन पर निर्भर है जो समीक्षा में एक साथ है), और आपको पहले के बदलाव में संशोधन करने की आवश्यकता है, तो आपको प्रभावी ढंग से दोनों को पुनः सबमिट करना होगा परिवर्तन (के बाद से दूसरा परिवर्तन एक अलग "जनक" पर निर्भर हो जाता प्रतिबद्ध)

तो स्थिति आप मुख्य विकास शाखा के बंद एक भी शाखा में दो करता है, इस तरह है:

o master 
\ 
o Commit A (in review, requires change) 
o Commit B (in review, no changes required) 

मैं इस स्थिति में आम तौर पर क्या करता हूं वह कमेट ए के तीसरे प्रतिबद्धता में किए गए परिवर्तनों को करना है।

o master 
\ 
o Commit A (in review, requires change) 
o Commit B (in review, no changes required) 
o Commit C (modifications to Commit A) 

अब मैं git rebase -i master करते हैं और सी कमिट के बाद आने के एक कमिट लेकिन इससे पहले कि बी कमिट करने के लिए पुन: व्यवस्थित, और उसके बाद में उससे छुटकारा पाने के ए ग्राफ प्रतिबद्ध अब इस तरह दिखता है प्रतिबद्ध:

हमारे प्रतिबद्ध ग्राफ अब इस तरह दिखता है

o master 
\ 
o Commit A' (Commit A, incorporating the changes from Commit C) 
o Commit B' (the same changes made in Commit B, but applied to Commit A' instead of A) 

अंत में, git review (या जो भी आदेश आप Gerrit में परिवर्तन सबमिट कर का उपयोग करें) फिर से प्रस्तुत करने के लिए दोनों Gerrit के लिए प्रतिबद्ध।

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

Answer 2

मुझे लगता है कि आपकी समस्या इस तथ्य से संबंधित है कि पहले प्रतिबद्धता में संशोधन अब निर्भरता के रूप में दूसरी प्रतिबद्धता है। यही वह है जो मैं व्यक्तिगत रूप से करता हूं लेकिन एक बेहतर तरीका हो सकता है। मैं इसे देखता हूं क्योंकि आप अपनी पसंद के तरीके को पुनर्जीवित करना चाहते हैं और आप पिछले 3 से निपट रहे हैं। तो 'गिट रिबेस -आई हेड ~ 3' चलाएं। यह आपको आदेश को स्विच करने या उन्हें एक दूसरे के साथ जोड़ने के माध्यम से अंतिम 3 प्रतिबद्धताओं को पुन: पेश करने की अनुमति देता है।आपको अवगत होना चाहिए कि यह सबसे पुराने क्रम में काम करता है। यहाँ एक उदाहरण है:

जानकारी के लिए प्रतिबद्ध:

Git लॉग इस प्रकार है ......

संदेश: foo2

जानकारी के लिए प्रतिबद्ध: ......

संदेश: bar1

प्रतिबद्ध जानकारी: ......

संदेश: foo1

उपरोक्त आदेश चलाने के बाद एक संपादक निम्नलिखित के साथ पॉप अप चाहिए:

पिकअप foo1।

बार 1 चुनें।

foo2 चुनें।

(यह माना जाता है कि आपका दूसरा फू परिवर्तन किसी भी फाइल को नहीं बदला है जो बार 1 बदल गया है क्योंकि यह काम नहीं कर सकता है और यदि आपने ऐसा किया है तो आपको प्रतिबद्धता में संशोधन करना चाहिए था।) फिर सूची को बदलें:

foo2

पिकअप bar1

कि आप foo1 और foo2 कुचल में एक प्रतिबद्ध और bar1 प्रतिबद्ध निम्नलिखित हो जाएगा होगा के बाद लेने foo1

Fixup। फिर मैं 'गिट रीसेट - सॉफ्ट हेड ~ 1' को नवीनतम प्रतिबद्धता को रीसेट कर दूंगा, उसके बाद 'गिट प्रतिबद्ध - कमांड' होगा जो आपको पहली समीक्षा के लिए प्रतिबद्ध संदेश बदलने की अनुमति देता है और परिवर्तन-आईडी को शामिल करना सुनिश्चित करता है । फिर अपने धक्का की कोशिश करो। इसके बाद आपके पास एक नया पैच सेट होना चाहिए, और दूसरी फाइलों को दूसरी बार संशोधित किया जाएगा और अभी भी आपकी कार्यशील निर्देशिका में।

Answer 3

कॉल

commit --ammend 

अपने 2 बदलाव के लिए

बजाय

Answer 4

मैं इन प्रयासों के साथ की कोशिश की

1. Git rebase मैं मास्टर
   यह
2. तो पिछले काम नहीं किया था मैंने क्या किया, मैंने फ़ाइलों का बैकअप लिया। पूरी परियोजना हटा दी गई। फिर इसे फिर से क्लोन किया। बैकअप से आवश्यक फ़ोल्डर में फ़ाइलों को पेस्ट करें और फिर दोबारा अनुशंसित करें और फिर धक्का दें। इसने काम कर दिया ।

Answer 5

सिर्फ प्रतिबद्ध Git --amend तो Git समीक्षा