git pullशायद कमिट बना रहा है। यदि आप एक स्थानीय कमिट करते हैं और फिर git pullरिपॉजिटरी में किसी अन्य व्यक्ति को कमिट करने के बाद चलाते हैं , तो Git दूसरे डेवलपर की कमिट को डाउनलोड करता है और फिर उसे आपकी स्थानीय शाखा में विलय कर देता है।
भविष्य में इन मर्जों से कैसे बचा जाए
आप git pull --rebaseइसे भविष्य में होने से रोकने के लिए उपयोग कर सकते हैं, लेकिन रिबासिंग के अपने खतरे हैं, और मैं pullपूरी तरह से बचने की सलाह देता हूं ।
इसके बजाय, मैं आपको इस उपयोग पैटर्न का अनुसरण करने के लिए प्रोत्साहित करता हूं:
# download the latest commits
git remote update -p
# update the local branch
git merge --ff-only @{u}
# if the above fails with a complaint that the local branch has
# diverged:
git rebase -p @{u}
व्याख्या
git remote update -pसभी दूरस्थ रिपॉजिटरी में कमिट्स को डाउनलोड करता है और रिमोट ट्रैकिंग ब्रांच (जैसे, origin/master) को अपडेट करता है । यह आपके कार्यशील निर्देशिका, सूचकांक या स्थानीय शाखाओं को नहीं छूता है।
-pतर्क आलूबुखारा नदी के ऊपर शाखाओं को नष्ट कर दिया। इस प्रकार, यदि fooशाखा originरिपॉजिटरी में हटा दी जाती है, git remote update -pतो स्वचालित रूप से आपके origin/fooरेफ को हटा देगा ।
git merge --ff-only @{u}गिट को अपस्ट्रीम शाखा ( @{u}तर्क) को अपनी स्थानीय शाखा में विलय करने के लिए कहता है, लेकिन केवल तभी जब आपकी स्थानीय शाखा अपस्ट्रीम शाखा को "फास्ट फॉरवर्ड" (दूसरे शब्दों में, अगर यह अलग नहीं हुई है) हो सकती है।
git rebase -p @{u}प्रभावी रूप से आपके द्वारा किए गए कमिट को स्थानांतरित करता है, लेकिन अभी तक अपस्ट्रीम शाखा के शीर्ष पर धकेल नहीं दिया गया है, जो आपके द्वारा बचने की कोशिश कर रहे मूर्खतापूर्ण मर्ज को बनाने की आवश्यकता को समाप्त करता है। यह विकास के इतिहास की रैखिकता में सुधार करता है, जिससे समीक्षा करना आसान हो जाता है।
यह -pविकल्प Git को मर्जों को संरक्षित करने के लिए कहता है। यह Git को कमिट किए जा रहे कमिट्स को रैखिक बनाने से रोकता है। यह महत्वपूर्ण है अगर, उदाहरण के लिए, आपने एक सुविधा शाखा को मर्ज कर दिया है master। इसके बिना -p, सुविधा शाखा की प्रत्येक प्रतिबद्ध masterद्वारा किए गए रैखिककरण के हिस्से के रूप में दोहराया जाएगा git rebase। यह विकास के इतिहास को समीक्षा के लिए कठिन बना देगा, आसान नहीं।
खबरदार : git rebaseआप जो करने की उम्मीद करते हैं वह नहीं कर सकते, इसलिए धक्का देने से पहले परिणामों की समीक्षा करें। उदाहरण के लिए:
git log --graph --oneline --decorate --date-order --color --boundary @{u}..
मैं git pull --rebaseनिम्नलिखित कारणों से इस दृष्टिकोण को पसंद करता हूं :
- यह आपको अपने इतिहास को संशोधित करने से पहले आने वाले अपस्ट्रीम को देखने के लिए अनुमति देता है ताकि आप उन्हें शामिल कर सकें।
- यह आपको एक जानबूझकर मर्ज (जैसे, पहले से धकेल दी गई सुविधा शाखा में मर्ज ) करने की आवश्यकता होने पर आपको
-p( --preserve-merges) विकल्प पास करने की अनुमति देता है ।git rebasemaster
आशुलिपि: के git upबजायgit pull
उपरोक्त कार्य करना आसान बनाने के लिए, मैं एक उपनाम बनाने की सलाह देता हूं up:
git config --global alias.up '!git remote update -p; git merge --ff-only @{u}'
अब आपको अपनी शाखा को चालू करने के लिए बस इतना करना है:
git up
के बजाय git pull। यदि आपको कोई त्रुटि मिलती है क्योंकि आपकी स्थानीय शाखा ने अपस्ट्रीम शाखा से विचलन किया है, तो यह आपकी प्रतिक्रिया का कारण बनता है।
क्यों नहीं git pull --rebase?
दौड़ना उसके बाद git pull --rebaseदौड़ने के बराबर git fetchहै git rebase। यह नए अपस्ट्रीम को फास्ट-फॉरवर्ड करने का प्रयास करता है, लेकिन यदि यह संभव नहीं है, तो यह आपके स्थानीय कमिट्स को नए अपस्ट्रीम के कमिट्स पर रीबेस कर देगा। यह आमतौर पर ठीक है, लेकिन सावधान रहें:
- रिबेस एक उन्नत विषय है, और आपको पुनरावृत्ति करने से पहले निहितार्थ को समझना चाहिए।
git pull --rebaseउन्हें शामिल करने से पहले आपको कमिट्स की जांच करने का अवसर नहीं देता है। क्या नदी के ऊपर बदल के आधार पर, इसलिए संभव है कि रिबेस गलत आपरेशन-एक है rebase --onto, merge, reset, या push -fएक सादे की तुलना में अधिक उपयुक्त हो सकता है rebase।- यह (वर्तमान में)
--preserve-mergesरिबास संचालन के लिए पारित करना संभव नहीं है , इसलिए किसी सुविधा शाखा का कोई जानबूझकर मर्ज रैखिक हो जाएगा, फिर से खेलना (और इस प्रकार दोहराव) सुविधा शाखा के सभी काम करता है।
"फिक्सिंग" द्वारा बनाई गई मौजूदा मर्ज कमेटी git pull
यदि आपने अभी तक किसी मर्ज कमेटी को धक्का नहीं दिया है git pull, तो आप मर्ज कमिट को रीबेस कर सकते हैं। यह मानते हुए कि आपने कोई जानबूझकर मर्ज नहीं किया है (उदाहरण के लिए, अपनी वर्तमान शाखा में पहले से धकेल दी गई सुविधा शाखा को मर्ज करना), निम्नलिखित को यह करना चाहिए:
git rebase @{u}
उपरोक्त आदेश Git को सभी गैर-मर्ज किए गए कमिटों में से चुनने के लिए कहता है HEAD(वर्तमान प्रतिबद्ध), से आने वाले सभी कमानों को घटाता है @{u}(जो "अपस्ट्रीम शाखा" के लिए शॉर्टहैंड है, अर्थात, origin/masterयदि HEADहै master), रिप्ले (चेरी-पिक) ) उन्हें अपस्ट्रीम शाखा के शीर्ष पर, और फिर वर्तमान शाखा संदर्भ को स्थानांतरित करने के परिणाम को इंगित करने के लिए फिर से शुरू करें। यह सबसे हाल ही में अपस्ट्रीम कमिट पर गैर-मर्ज कमिट को प्रभावी ढंग से आगे बढ़ाता है, जो द्वारा बनाए गए मर्ज को समाप्त करता है git pull।
यदि आपके पास एक जानबूझकर मर्ज कमिटमेंट है, तो आप चलाना नहीं चाहते git rebase @{u}क्योंकि यह दूसरी शाखा से सब कुछ फिर से करेगा। इस मामले से निपटना काफी अधिक जटिल है, यही कारण है कि इसका उपयोग करना git upऔर git pullपूरी तरह से बचना अच्छा है । आपको संभवतः resetद्वारा बनाए गए मर्ज को पूर्ववत करने के लिए उपयोग करना होगा pullऔर फिर करना होगा git rebase -p @{u}। मेरे लिए मज़बूती से काम नहीं -pकरने का तर्क git rebase, इसलिए आप resetजानबूझकर मर्ज को पूर्ववत करने के लिए उपयोग करने के लिए समाप्त हो सकते हैं , अपनी स्थानीय शाखा को अपडेट कर सकते हैं @{u}, और फिर जानबूझकर मर्ज को फिर से कर सकते हैं (जो कि बहुत सारे बालों के मर्ज होने पर दर्द होता है) संघर्ष)।