क्या गिट विलय करते समय विशिष्ट प्रतिबद्धताओं को बाहर करना संभव है?

Question

मान लीजिए कि मैं एक रिलीज शाखा से मास्टर शाखा में विलय करना चाहता हूं और कुछ रिलीज शाखा में कुछ काम करता है जिसे मैं मास्टर शाखा में शामिल नहीं करना चाहता हूं। क्या विलय करने का कोई तरीका है ताकि उनमें से एक या अधिक विलय नहीं किया जा सके?

मेरे रणनीति अब तक ऐसा करने के लिए है (मास्टर में) के बाद:

git merge --no-commit release-branch 
# Resolve conflicts and apply reverse patch of the commits that I don't want included 
git commit # Edit commit message so that it lists the commits that have been reverse-patched 

वहाँ यह करने के लिए एक बेहतर तरीका है?

Answer 1

एक नई शाखा बनाएं, शाखा को अंतःक्रियात्मक रूप से दोबारा दबाएं और उन चीजों को छोड़ दें जिन्हें आप नहीं चाहते हैं, और फिर इसे मर्ज करें।

आप बिना किसी शाखा के बीच में शाखाओं के बीच में बदलाव नहीं कर सकते हैं, लेकिन सही बात तब होगी जब यह बाद में विलय में समान परिवर्तन देखेगी (उदाहरण के लिए चेरी-पिकिंग और क्या नहीं)।

Answer 2

कारण यह सीधे नहीं किया जा सकता है कि प्रत्येक प्रतिबद्धता में माता-पिता के काम शामिल होते हैं (आमतौर पर केवल एक लेकिन विलय के लिए कई)। इस तरह यदि आपके पास एक प्रतिबद्धता है (इसके SHA1 योग से) पूरा इतिहास भी तय किया जाता है क्योंकि माता-पिता में उनके माता-पिता के लिंक भी शामिल होते हैं। तो इतिहास में पैच छोड़ने का एकमात्र तरीका एक नया लिखना है। एक नई बनाई गई शाखा पर गिट रिबेस- मैं शायद इसे प्राप्त करने का सबसे आसान तरीका है।

Answer 3

मुझे एक समाधान मिला है जो मेरे लिए काम करता है in the Pro Git book।

मान लें कि आप फ़ाइल config.php को बाहर करना चाहते हैं।

शाखा एक पर: config.php merge=ours:

1. एक ही निर्देशिका में .gitattributes नाम की एक फ़ाइल, इस लाइन के साथ बनाएँ। यह गिट बताता है कि फ़ाइल विलय करते समय किस रणनीति का उपयोग करना है। इस मामले में यह हमेशा आपका संस्करण रखता है, यानी। जिस शाखा में आप विलय कर रहे हैं उस संस्करण का संस्करण।

2. .gitattributes फ़ाइल जोड़ें और प्रतिबद्ध

शाखा बी पर: दोहराने कदम 1-2

अब विलय की कोशिश करो। आपकी फाइल छूटे रहना चाहिए।

Answer 4

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

git checkout partlyMergedFrom 
git whatchanged 
--> find the commit hash up to where you want to merge 
git checkout partlyMergedInto 
git merge e40a0e384f58409fe3c864c655a8d252b6422bfc 
git whatchanged 
--> check that you really got all the changes you want to have 

Answer 5

यह भी .git/जानकारी संशोधित करने के लिए संभव है/फ़ाइल विशेषताओं और इसे रखने के अंदर .git फ़ोल्डर को जोड़ने के बजाय .git फ़ोल्डर के अंदर उन्हें अंततः स्रोत नियंत्रण में जोड़ने की आवश्यकता होगी।

Answer 6

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

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

यदि फ़ाइल जानकारी वाली फ़ाइल में केवल में संस्करण जानकारी है, तो आप fcurella के उत्तर के साथ जा सकते हैं। लेकिन अगर यह वास्तव में विलय योग्य जानकारी (pom.xml, gradle.properties, MANIFEST.MF, ...) भी हो सकता है, तो आपको कुछ अतिरिक्त कार्रवाई करनी होगी।

निम्न उदाहरण

 C---D*---E---F* support 
    /
A---B---G---H*---I master 

जहां के साथ सितारों केवल संस्करण परिवर्तन है कि मर्ज के दौरान अनदेखा किया जाना चाहिए की वजह से परिवर्तन शामिल करता है का उपयोग करने देता है।

बिना संस्करण बनाता है की वजह से मर्ज-संघर्ष मास्टर में समर्थन मर्ज करने के लिए, आप निम्न में से किसी कर सकते हैं:

एकाधिक मर्ज करता

git checkout master 
git merge C 
git merge D -s ours 
git merge E 
git merge F -s ours 

-s ours तर्क के साथ हम कार्यक्षेत्र को बदलने के बिना केवल मर्ज रिकॉर्ड करने के लिए गिट को बता रहे हैं। यह तुलनीय to the --record-only option of svn है।

ऊपर निम्नलिखित लेआउट

 -------------C---D*---E---F* support 
    /   \ \ \ \ 
A---B---G---H*---I---J---K----L---M master 

एक मर्ज का उपयोग कर के लिए प्रतिबद्ध में परिणाम होगा चेरी लेने

git checkout master 
git merge support -s ours --no-commit 
git cherry-pick C E --no-commit 
git commit -m 'merged support into master' 

पहले हम, किसी मर्ज लेकिन केवल रिकॉर्ड है कि हम विलय कर रहे हैं शुरू कर रहे हैं को बदले बिना कार्यक्षेत्र और विलय प्रतिबद्ध किए बिना। फिर हम बिना किसी प्रतिबद्धता के फिर से विलय करने के लिए काम करते हैं। अंत में हम विलय कर रहे हैं।

ऊपर निम्नलिखित लेआउट

 C---D*---E---F* support 
    /   \ 
A---B---G---H*---I---J master 

एक भी चेरी पिकिंग को स्वचालित कर सकता का परिणाम देगा।

git checkout master 
git merge support -s ours --no-commit 
for id in `git log support --reverse --not HEAD --format="%H [%an] %s" | 
    grep -v "bump version" | 
    sed "s/\(\w*\)\s.*/\1/g"` 
do 
    git cherry-pick --no-commit $id 
done 
git commit -m 'merged support into master' 

Answer 7

मुख्य सवाल यह है: आप कैसे करता आप छोड़ना चाहते का प्रतिनिधित्व करना चाहते हैं?

1. sneakily उन्हें (नहीं मेरी पसंदीदा) छिपाने
2. स्पष्ट रूप से उन्हें
3. छोड़ स्पष्ट रूप से उन्हें पूर्ववत

दुर्भाग्य से कोई। इतिहास ग्राफ में व्यक्त करना असंभव है 2।

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

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

कुछ अन्य उत्तरों इस छिपाने का सुझाव देते हैं। मैं स्पष्ट तरीके से अनुशंसा करता हूं: प्लस रिवर्ट मर्ज करें।