gerrit

2012-05-01 7 views
11

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

मैंने कुछ मुद्दों में भाग लिया है जो मुझे लगता है कि मैं गिटिट के साथ संयोजन में गिट का सही उपयोग नहीं कर रहा हूं।

प्रत्येक प्रतिबद्धता के लिए पिछले कुछ प्रतिबद्धताओं पर निर्भर नहीं होने के लिए मेरे गिट/गेरिट वर्कफ़्लो में अलग-अलग क्या होना चाहिए? मैं भी बदलाव के लिए एक नई शाखा बनाने की कोशिश की है:

> git pull origin master 
> git checkout -b new_branch 
> #make a change 
> git add -A 
> git commit #with gerrit's commit hook in .git/hooks 
> git push origin <sha1>:refs/for/master 

यह काम करता है, लेकिन अभी भी Gerrit पहले से प्रतिबद्ध आइटम पर निर्भरता की रिपोर्ट।

+0

मुझे यह भी सुनिश्चित नहीं है कि आप क्या पूछ रहे हैं। "निर्भरता" से आपका क्या मतलब है? – ebneter

+0

गेरिट दिखाता है कि कौन से मुद्दे निर्भर हैं/निर्भरता पर निर्भर हैं। उदाहरण के लिए, मैं gerrit को समस्या # 1 में चेक करता हूं, और उसके बाद एक पूरी तरह अलग # 2 में चेक करता हूं जो एक ही फ़ाइल को स्पर्श नहीं करता है। गेरिट रिपोर्ट करता है कि # 2 # 1 पर निर्भर है। यह गलत लगता है। – Shellum

+0

एक गिट रिबेस-ई का उपयोग करके और निर्भरताओं को हटाने से आप निर्भरताओं से छुटकारा पाने का भी एक तरीका हो सकते हैं। – cafebabe1991

उत्तर

13

यह Gerrit निर्भरता से है - एक प्रतिबद्धता जो किसी अन्य प्रतिबद्धता के शीर्ष पर है। यदि दोनों समीक्षा में हैं, तो नया व्यक्ति पुराने पर निर्भर करता है।

यदि आप नहीं चाहते हैं कि वे एक-दूसरे पर निर्भर रहें, तो एक दूसरे के शीर्ष पर काम न करें। एक प्रतिबद्ध बनाएं, फिर अपनी अगली प्रतिबद्धता

(git checkout origin/master -b NEW_BRANCH_NAME) के लिए मास्टर पर आधारित एक नई शाखा बनाएं।

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

+0

मैंने प्रत्येक कोड परिवर्तन के लिए शाखाकरण का उल्लेख देखा है ... लेकिन जैसा कि मेरे संपादित प्रश्न में है, यह अभी भी एक ही परिणाम उत्पन्न करता प्रतीत होता है। कोई और विचार? – Shellum

+7

वह आदेश जो आप शाखा बनाने के लिए उपयोग कर रहे हैं (गिट चेकआउट -बी new_branch) मौजूदा प्रतिबद्धता के शीर्ष पर नई शाखा बनाता है। आप मौजूदा प्रतिबद्धता के रूप में सर्वर को क्या देखते हैं, इसे वापस रीसेट करना चाहते हैं - इसलिए चेकआउट कमांड में निर्दिष्ट करें।गिट चेकआउट * मूल/मास्टर * -b new_branch। – Brad

+1

@Brad आपकी टिप्पणी समझ में आता है। मैं बस यह इंगित करना चाहता था कि गिट-चेकआउट के लिए दस्तावेज़ में अंतिम पैरामीटर के रूप में शुरुआती बिंदु है: गिट चेकआउट [-q] [-f] [-m] [[-b | -B | --orphan] ] [] तो अपने उदाहरण होगा: Git चेकआउट बी new_branch _origin/master_ – Plazgoth

0

मुझे प्रत्येक git push के बाद git reset --hard HEAD~1 करके इसे प्राप्त करने के लिए सिखाया गया है।

+3

क्या आप इस बारे में टिप्पणी करना चाहते हैं कि आपको गलत क्यों लगता है, शायद गलत जानकारी कायम रखने से बचें और मुझे बेहतर सूचित करें? – Mitch

+3

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

+1

कोई समस्या नहीं है। धक्का दिया गया सभी काम सर्वर पर और स्थानीय रूप से संग्रहीत किया जाता है। आप एक पर काम करते हैं, इसे दबाते हैं, फिर आप दूसरे पर काम करते हैं। जब आप एक पर प्रतिक्रिया प्राप्त करते हैं और इसे फिर से संशोधित करना चाहते हैं, तो आप इसे इस पर काम करने के लिए देखें। उस पर शाखा का नाम रखना एक सुविधा है, और कुछ भी नहीं। – clacke

0

git reset --hard HEAD~1 को एक प्रकार के रूप में मैं इस के बजाय का उपयोग करें:

git reset --hard origin/master 

, मान लिया जाये कि मैं एक त्वरित बदलाव के लिए master में काम कर रहा हूँ।

अन्यथा, किसी विषय शाखा में काम करना बहुत पसंद है।

कई Git लिपियों विषय शाखाओं प्रबंधन में मदद करने के लिए कर रहे हैं:

मुझे यकीन है कि वहाँ दूसरों रहे हैं रहा हूँ।

+0

मुझे लगता है कि "गिट रीसेट - हार्ड उत्पत्ति/मास्टर" बेहतर है ... क्योंकि उपरोक्त आदेश ने त्रुटि दी और अंतरिक्ष देने के बाद काम किया - और कठिन –

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