git checkout documentation का कहना है:Git चेकआउट: "उनकी" और की विस्तृत अर्थ "हमारा"
--ours --theirs जब सूचकांक से पथ बाहर की जाँच, चरण # की जाँच 2 (हमारे) या # 3 (उनके) अनमोल पथों के लिए।
मर्ज, रिबेस और चेरी-पिक के दौरान "चरण # 2" और "चरण # 3" का क्या अर्थ है? क्या यह सुनिश्चित करने के लिए कि यह सही संस्करण पुनर्प्राप्त करेगा, कमांड चलाने से पहले "चरणों" से पूछताछ करने का कोई तरीका है?
ये प्रलेखित हैं (हालांकि नहीं सब स्पष्ट रूप से, मुझे लगता है कि) the gitrevisions documentation में:
एक बृहदान्त्र, वैकल्पिक रूप से एक मंच संख्या (3 0) और उसके बाद एक कॉलन, एक पथ के द्वारा पीछा किया, नाम दिए गए पथ पर इंडेक्स में एक ब्लॉब ऑब्जेक्ट। एक लापता चरण संख्या (और इसके बाद का कोलोन) चरण 0 प्रविष्टि का नाम देता है। एक विलय के दौरान, चरण 1 आम पूर्वज है, चरण 2 लक्ष्य शाखा का संस्करण (आमतौर पर वर्तमान शाखा) है, और चरण 3 शाखा से संस्करण है जिसे विलय किया जा रहा है।
इनके लिए, आपको git rebase और git cherry-pick कार्य के बारे में ज्ञान जोड़ने की आवश्यकता है।
सामान्य चेरी पिकिंग अच्छी तरह परिभाषित है: "हमारा" HEAD संस्करण है, यानी, जिस शाखा में आप थे (और अभी भी हैं), जबकि "उनका" वह कार्य है जिसे आप सक्रिय रूप से उठा रहे हैं। जब आप एक ही प्रतिबद्धता को चुनते हैं, तो यह सब स्पष्ट है: चरण # 1 आम पूर्वज है, चरण # 2 आपकी वर्तमान शाखा की नोक से संस्करण है, और चरण # 3 वह संस्करण है जिसे आप चेरी-पिकिंग कर रहे हैं।
यदि आप काम करने की श्रृंखला चुनते हैं, तो यह अभी भी सच है, यह केवल सही है। कहें कि उदाहरण के लिए, आप चेरी-तीन चीजें चुन रहे हैं। गिट बस तीनों एक-एक समय में करता है। पहले चेरी-पिक के दौरान, चरण # 2 आपकी शाखा की नोक है, और चरण # 3 चेरी-चुने जाने वाले पहले प्रतिबद्धता का संस्करण है। एक बार जब चेरी-पिक खत्म हो जाता है, तो गिट एक नई प्रतिबद्धता बनाता है, जो आपकी शाखा की नोक को आगे बढ़ाता है। फिर, दूसरे चेरी-पिक के दौरान, चरण # 2 आपकी शाखा की नोक है, जो आपके पहले चेरी-पिक किए गए प्रतिबद्ध हैं, और चरण # 3 दूसरी प्रतिबद्धता का संस्करण है। यह अंतिम प्रतिबद्धता के लिए फिर से दोहराता है। प्रत्येक बार, चरण # 3 "उनका" संस्करण है।
रीबेस, हालांकि, थोड़ा मुश्किल है। आंतरिक रूप से, यह आपको एक नई, अज्ञात शाखा (एक "अलग सिर") पर ले कर शुरू होता है। फिर यह आपकी मूल शाखा से प्रत्येक प्रतिबद्धता लेने के लिए git cherry-pick चलाता है। इसका मतलब है कि "हमारा" अलग सिर संस्करण है, जबकि "उनका" आपकी मूल शाखा का संस्करण है। चेरी-पिक की तरह, यह हर प्रतिबद्धता के लिए इसे क्रमशः दोहराया जाता है (शाब्दिक रूप से एक इंटरैक्टिव रीबेस के मामले में, जहां आप pick लाइनों को संपादित करते हैं)। एक बार रिबेस समाप्त होने के बाद, गिट बस शाखा लेबल को चारों ओर घुमाता है, ताकि आपके द्वारा बनाई गई नई अनाम शाखा आपका कोड हो।
संक्षेप में, आप रिबेस को "हमारी/उनकी सेटिंग्स को उलटाने" के रूप में सोच सकते हैं-लेकिन यह एक असाधारण है। यह कहना अधिक सटीक हो सकता है कि चरण 2 आपका नया, मिश्रित कोड है, और चरण 3 आपका पुराना कोड है।
Git documentation for merge (और साथ ही कुछ अन्य स्थानों) बताते हैं कि तीन संस्करणों, या चरणों अप करने के लिए एक सूचकांक फ़ाइल रिकॉर्ड:
परस्पर विरोधी रास्तों के लिए, तीन संस्करणों के लिए ऊपर इंडेक्स फ़ाइल रिकॉर्ड: चरण 1 सामान्य पूर्वजों से संस्करण, हेड से चरण 2, और MERGE_HEAD से चरण 3 स्टोर करता है (आप git ls-files -u के चरणों के निरीक्षण कर सकते हैं)। काम करने वाली पेड़ फ़ाइलों में "विलय" कार्यक्रम का परिणाम होता है; यानी परिचित संघर्ष मार्करों के साथ 3-तरफा विलय परिणाम < < < === >>>।
Common Ancestor -> C1 --- C2 <- MERGE_HEAD (Stage 3) (Stage 1) \ --- C3 --- C4 <- HEAD (Stage 2)मतलब यह है कि शाखा जिसका
HEADहैC4शाखाC2में समाप्त होने पर वापस विलय कर दिया जा रहा है:
यहाँ दिखा क्या तीन चरणों एक ठेठ Git मर्ज में हैं एक चित्र है।
प्रलेखन राज्यों के रूप में, आप वास्तव में टाइप करके चरणों देख सकते हैं:
git ls-files -u