git - मास्टर में गिट शाखा को मर्ज करने के लिए सर्वश्रेष्ठ(और सबसे सुरक्षित) तरीका




git-merge (4)

न तो एक रिबेस और न ही विलय किसी के परिवर्तन को ओवरराइट करना चाहिए (जब तक आप किसी संघर्ष को हल करते समय ऐसा करने का विकल्प नहीं चुनते)।

विकास करते समय सामान्य दृष्टिकोण है

git checkout master
git pull
git checkout test
git log master.. # if you're curious
git merge origin/test # to update your local test from the fetch in the pull earlier

जब आप मास्टर में वापस विलय करने के लिए तैयार होते हैं,

git checkout master
git log ..test # if you're curious
git merge test
git push

यदि आप मर्ज पर कुछ तोड़ने के बारे में चिंतित हैं, तो git merge --abort आपके लिए है।

पुश का उपयोग करना और फिर विलय के साधन के रूप में खींचना मूर्खतापूर्ण है। मुझे यह भी यकीन नहीं है कि आप मूलभूत परीक्षण क्यों कर रहे हैं।

master से एक नई शाखा बनाई गई है, हम इसे test कहते हैं।

ऐसे कई डेवलपर हैं जो या तो master या अन्य शाखाएं बनाने के लिए प्रतिबद्ध होते हैं और बाद में master में विलय करते हैं।

आइए मान लें कि test पर काम कई दिनों लग रहा है और आप लगातार master अंदर काम करने के साथ test जारी रखना चाहते हैं।

मैं test से git pull origin master करूँगा।

प्रश्न 1: क्या यह सही दृष्टिकोण है? अन्य डेवलपर आसानी से उसी फाइल पर काम कर सकते थे क्योंकि मैंने बीटीडब्ल्यू काम किया है।

test पर मेरा काम किया जाता है और मैं इसे वापस master विलय करने के लिए तैयार हूं। यहां दो तरीके हैं जिनके बारे में मैं सोच सकता हूं:

ए:

git checkout test
git pull origin master
git push origin test
git checkout master
git pull origin test 

बी:

git checkout test
git pull origin master
git checkout master
git merge test

मैं --rebase का उपयोग नहीं कर रहा --rebase क्योंकि मेरी समझ से, --rebase को master से बदलाव मिलेगा और इसके ऊपर मेरा ढेर --rebase होगा, इसलिए यह अन्य लोगों के बदलावों को ओवरराइट कर सकता है।

प्रश्न 2: इन दो तरीकों में से कौन सा सही है? वहां क्या अंतर है?

इन सभी में लक्ष्य मेरी test शाखा को master में होने वाली चीजों के साथ अद्यतन रखना है और बाद में मैं उन्हें master में वापस मर्ज कर सकता हूं ताकि समय रेखा को यथासंभव रैखिक बनाए रखा जा सके।


मैं यह कैसे करूंगा

git checkout master
git pull origin master
git merge test
git push origin master

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

गिट हमेशा तुम्हारा सम्मान करने की कोशिश करता है और दूसरों को बदलता है, और ऐसा होगा --rebase । मुझे नहीं लगता कि मैं इसे उचित रूप से समझा सकता हूं, इसलिए गिट बुक - रीबिसिंग या गिट-रेडी पर एक नज़र डालें : थोड़ा विवरण के लिए रीबेजिंग में परिचय । यह एक बहुत अच्छी सुविधा है


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

git pull -r upstream master

यह मास्टर को परिवर्तनों को खींच देगा क्योंकि आपने test शाखा को फोर्क किया है और उन्हें लागू किया है, और फिर मास्टर की वर्तमान स्थिति "शीर्ष पर" परीक्षण करने के लिए किए गए परिवर्तनों को लागू करें। यहां पर संघर्ष हो सकते हैं, अगर अन्य लोगों ने उसी फाइल में बदलाव किए हैं जिन्हें आपने परीक्षण में संपादित किया है। यदि वहां हैं, तो आपको उन्हें मैन्युअल रूप से ठीक करना होगा, और प्रतिबद्ध होना होगा। एक बार ऐसा करने के बाद, आप मास्टर शाखा में स्विच करने और बिना किसी समस्या के test में विलय करने के लिए अच्छा होगा।


किंगक्रंच के जवाब के अलावा, मैं उपयोग करने का सुझाव देता हूं

git checkout master
git pull origin master
git merge --squash test
git commit
git push origin master

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

संपादित करें: आपको रुचि हो सकती है

तो mybranch पर, मैं एक फीचर शाखा mybranch लिए निम्नलिखित कर रहा हूँ:

मूल से नवीनतम प्राप्त करें

$ git checkout master
$ git pull origin master

मर्ज बेस हैश ढूंढें:

$ git merge-base mybranch master
c193ea5e11f5699ae1f58b5b7029d1097395196f

$ git checkout mybranch
$ git rebase -i c193ea5e11f5699ae1f58b5b7029d1097395196f

अब सुनिश्चित करें कि केवल पहला pick , बाकी है:

pick 00f1e76 Add first draft of the Pflichtenheft
s d1c84b6 Update to two class problem
s 7486cd8 Explain steps better

इसके बाद एक बहुत अच्छा प्रतिबद्ध संदेश चुनें और गिटहब को दबाएं। तब पुल अनुरोध करें।

पुल अनुरोध के विलय के बाद, आप इसे स्थानीय रूप से हटा सकते हैं:

$ git branch -d mybranch

और गिटहब पर

$ git push origin :mybranch




git-merge