क्या "गिट पुल" स्वतः स्लैश और पॉप लंबित परिवर्तन कर सकता है?

Question

मुझे पता है कि इसे कैसे हल किया जाए:

user@host$ git pull
Updating 9386059..6e3ffde
error: Your local changes to the following files would be overwritten by merge:
    foo.bar
Please, commit your changes or stash them before you can merge.
Aborting

लेकिन git pullक्या मेरे लिए ऐसा करने stashऔर popनृत्य करने का कोई तरीका नहीं है?

यदि इस कमांड का कोई दूसरा नाम है, तो यह ठीक है।

के लिए एक शेल उपनाम बनाना एक git stash; git pull; git stash popसमाधान है, लेकिन मैं एक बेहतर समाधान खोजता हूं।

Comments

क्या एक के बारे में Git उर्फ?

— Яइस

git stash; git pull; git stash popप्रोग्रामेटिक रूप से चलाना खतरनाक है, क्योंकि अगर स्टैश करने के लिए कुछ भी नहीं है, git stashतो नो-ऑप git stash popहोगा , लेकिन आखिरी स्टैश (यदि कोई हो) को पॉप करेगा, जो कि निश्चित रूप से वह नहीं है जो आप चाहते हैं। स्टैक ओवरफ्लो पर यूजर के पास इस बारे में एक बेहतरीन पोस्ट है, लेकिन मैं इसे नहीं पा सकता ...

— jub0bs

@ जुब्स इस एक? stackoverflow.com/a/20412685/6309 या यह एक? stackoverflow.com/a/20480591/6309

— VonC

@guettli मैं आपके प्रश्न का अर्थ यह नहीं लगा रहा था कि यह एक डुप्लिकेट है, मैं सिर्फ जुब्ब्स की टिप्पणी का जवाब दे रहा था।

— वॉनसी

एक और कदम के रूप में, ऑपरेशन को केवल तभी सफल होना चाहिए जब खींच के बाद साफ सफाई से लगाया जा सकता है। यदि संघर्ष होते हैं, तो पूरे ऑपरेशन परमाणु रूप से विफल हो जाते हैं ताकि पेड़ को बदल न जाए। यह वही है जो मैं करना चाहता हूं: या तो मेरे स्थानीय लोगों के साथ मर्ज किए गए परिवर्तनों को नीचे खींचें, या फिर एक त्रुटि के साथ विफल हो जाएं और मुझे मैन्युअल रूप से यह तय करने दें कि आगे क्या करना है। क्या इस तरह का 'लेन-देन' संभव है?

— एड एविस

Answer 1

गिट 2.6+ के लिए (28 सितंबर 2015 को जारी)

केवल git config सेटिंग जो ब्याज की होगी:

rebase.autoStash

(Git 2.27, Q2 2020 के साथ, अब आपके पास भी है merge.autostash, नीचे देखें)

जब सही पर सेट किया जाता है, तो ऑपरेशन शुरू होने से पहले स्वचालित रूप से एक अस्थायी स्लैश बनाएं, और ऑपरेशन समाप्त होने के बाद इसे लागू करें।
इसका मतलब है कि आप एक गंदे वर्कट्री पर रिबास चला सकते हैं।

हालांकि, देखभाल के साथ उपयोग करें: एक सफल रिबास के बाद अंतिम स्लैश आवेदन गैर-तुच्छ संघर्ष हो सकता है। झूठे की अवहेलना।

इसके साथ गठबंधन करें:

pull.rebase

जब सही होता है, तो भ्रूण शाखा के शीर्ष पर रिबास शाखाएं होती हैं, बजाय डिफ़ॉल्ट शाखा से डिफ़ॉल्ट शाखा को विलय करने के जब "गिट पुल" चलाया जाता है।

git config pull.rebase true
git config rebase.autoStash true

git pullएक गंदे पेड़ में भी काम करने के लिए यह पर्याप्त होगा ।
उस मामले में किसी अन्य व्यक्ति की जरूरत नहीं है।

---

केविन Daudt ( ) द्वारा प्रतिबद्ध 53c76dc (04 जुलाई 2015) देखें । ^{( जूनियो सी हमानो द्वारा विलय - - in प्रतिबद्ध e69b408 , 17 अगस्त 2015)}Ikke
gitster

pull: rebase.autostashसक्षम होने पर गंदे पेड़ की अनुमति दें

रिबेस ने एक गंदे काम के पेड़ का सामना करने पर परिवर्तन को रोकना सीखा, लेकिन git pull --rebaseऐसा नहीं किया।

केवल तभी सत्यापित करें कि कार्यशील पेड़ rebase.autostashसक्षम नहीं होने पर गंदा है।

---

नोट: यदि आप ऑटोस्टैश के बिना खींचना चाहते हैं (भले ही rebase.autoStash trueसेट हो), आपके पास git 2.9 (जून 2016) से है:

 pull --rebase --no-autostash

देखें प्रतिबद्ध 450dd1d , 1,662,297 प्रतिबद्ध , 44a59ff प्रतिबद्ध , 5c82bcd प्रतिबद्ध , 6ddc97c प्रतिबद्ध , eff960b प्रतिबद्ध , प्रतिबद्ध efa195d (02 अप्रैल 2016), और f66398e प्रतिबद्ध , c48d73b प्रतिबद्ध (21 मार्च 2016) द्वारा मेहुल जैन ( mehul2029) ।
^{(द्वारा विलय Junio सी Hamano - gitster- में 7c137bb प्रतिबद्ध , 13 अप्रैल 2016)}

विशेष रूप से प्रतिबद्ध f66398e में शामिल हैं:

pull --rebase: --[no-]autostashझंडा जोड़ें

यदि rebase.autoStashकॉन्फ़िगरेशन चर सेट किया गया है, git pull --rebaseतो कमांड लाइन से इसे " " के लिए ओवरराइड करने का कोई तरीका नहीं है ।

" git pull --rebase" --[no-]autostashकमांड लाइन के झंडे को सिखाएं, जो rebase.autoStashसेट होने पर वर्तमान मूल्य को ओवरराइड करता है । जैसा कि " git rebase" --[no-]autostashविकल्प को समझता है , यह " git rebase" जब " git pull --rebase" कहा जाता है तो विकल्प को अंतर्निहित करने के लिए पारित करने की बात है।

---

चेतावनी: Git 2.14 (Q3 2017) से पहले, " git pull --rebase --autostash" जब स्थानीय इतिहास तेजी से ऊपर की ओर तेजी से आगे नहीं बढ़ा तो ऑटो-स्टैश नहीं हुआ।

देखें f15e7cf प्रतिबद्ध (01 जून 2017) द्वारा टायलर Brazier ( tylerbrazier) ।
^{(द्वारा विलय Junio सी Hamano - gitster- में प्रतिबद्ध 35898ea , 05 जून 2017)}

pull: --rebase --autostashगंदे रेपो में ff काम करता है

जब git pull --rebase --autostashएक गंदे भंडार में तेजी से अग्रगामी परिणाम हुआ, तो कुछ भी नहीं किया जा रहा था और पुल विफल हो गया।
यह एक शॉर्टकट के कारण था जब हम तेजी से फ़ॉरवर्ड कर सकते हैं, लेकिन रिडसेट को चलाने से बचने के लिए, लेकिन ऑटोस्टैश को उस कोडपाथ पर ध्यान नहीं दिया जाता है।

---

अद्यतन: Mariusz Pawelski टिप्पणियों में एक दिलचस्प सवाल पूछता है :

इसलिए हर कोई इस बारे में लिख रहा है autostashकि आप कब रिबेस (या pull --rebase) करते हैं।

लेकिन जब आप मर्ज के साथ सामान्य खींचतान करते हैं तो कोई भी ऑटोस्टैशिंग के बारे में नहीं ले रहा है ।
तो उसके लिए कोई स्वचालित स्विच नहीं है? या मुझे कुछ याद आ रहा है? मैं करना पसंद करता हूं, git pull --rebaseलेकिन ओपी ने " मानक " गिट पुल के बारे में पूछा

उत्तर:

मूल धागा इस autostash सुविधा पर चर्चा, इसके लिए मूल रूप से दोनों लागू किया गया था git pull(मर्ज) और git pull --rebase।

लेकिन ... जूनियो सी हामानो (गिट अनुचर) ने कहा कि:

अगर pull-mergeकुछ ऐसा था जो "झुंझलाहट" को प्रेरित करेगा, जो इस विषय को ट्रिगर करता है, तो परिभाषा के अनुसार, स्थानीय परिवर्तन मर्ज के साथ ओवरलैप हो जाता है, और यह आंतरिक "स्टैश पॉप" मर्ज को छूने वाले रास्तों को छू लेगा और इसका परिणाम "ड्राप्ड" होने की संभावना नहीं है। "लेकिन आगे के संघर्षों को हल करने के लिए छोड़ दें।

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

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

तो, एक क्लासिक पुल-मर्ज के बारे में, यह बेहतर है:

उपयोगकर्ता को WIP की प्रकृति के बारे में सोचने के लिए प्रोत्साहित करें कि वह " git pull" चलने से पहले काम के पेड़ में है ।
क्या यह एक बहुत ही जटिल जानवर है जो दूसरों के साथ क्या कर रहा है, या क्या यह एक तुच्छ परिवर्तन है जिसे वह दूर फेंक सकता है और उसे वापस ला सकता है?

यदि पूर्व में, वह " checkout -b" करने से बहुत बेहतर होगा, तब तक काम करते रहें, जब तक कि स्थानीय परिवर्तन मूल आकार में आने से पहले कुछ हद तक बेहतर आकार और "प्रतिबद्ध" न हो जाए।

यदि बाद वाला, वह करना बेहतर है:

• " git pull",
• इसे खोजने के बाद संघर्ष, भागो
  • git stash,
  • git merge FETCH_HEAD तथा
  • git stash pop

---

कहा जा रहा है कि, Git 2.27 (Q2 2020) के साथ, " git pull" जब कोई pull.rebaseकॉन्फ़िगरेशन मौजूद नहीं है, और न तो चेतावनी देना सीखा है और न --[no-]rebaseही --ff-onlyदिया गया है (जिसके परिणामस्वरूप मर्ज होगा)।

एलेक्स हेनरी ( ) द्वारा प्रतिबद्ध d18c950 (10 मार्च 2020) देखें । ^{( जूनियो सी हमानो द्वारा विलय - - में}alexhenrie
^{gitster जूनियो हमानो ५६ डी ६ एफ , २) मार्च २०२०)}

pull: यदि उपयोगकर्ता यह नहीं कहता कि रिबास या मर्ज करना है तो चेतावनी दें

^{साइन-ऑफ-बाय: एलेक्स हेनरी}

अक्सर नौसिखिए Git उपयोगकर्ता " pull --rebase" कहना भूल जाते हैं और ऊपर से एक अनावश्यक मर्ज के साथ समाप्त होते हैं।

वे आमतौर पर जो चाहते हैं वह pull --rebaseसरल मामलों में या तो " " है, या " pull --ff-only" मुख्य एकीकरण शाखाओं की प्रतिलिपि को अद्यतन करने के लिए, और उनके काम को अलग से रिबेट करते हैं।
pull.rebaseविन्यास चर उन्हें सरल मामलों में मदद करने के लिए मौजूद है, लेकिन वहाँ इन उपयोगकर्ताओं को इसके बारे में पता करने के लिए कोई तंत्र है।

--[no-]rebaseकमांड लाइन से कोई विकल्प और कोई pull.rebaseकॉन्फ़िगरेशन चर नहीं दिए जाने पर एक चेतावनी संदेश जारी करें ।
इससे उन लोगों को असुविधा होगी जो कभी " pull --rebase" नहीं चाहते हैं , जिन्हें कुछ विशेष नहीं करना है, लेकिन असुविधा की लागत प्रति उपयोगकर्ता केवल एक बार भुगतान की जाती है, जो कि कई नए उपयोगकर्ताओं की मदद करने के लिए उचित लागत होनी चाहिए।

---

Git 2.27 (Q2 2020) के साथ, " git merge" " --autostash" विकल्प सीखता है , और नई merge.autostashसेटिंग।

देखें d9f15d3 प्रतिबद्ध , f8a1785 प्रतिबद्ध , a03b555 प्रतिबद्ध , 804fe31 प्रतिबद्ध , 12b6e13 प्रतिबद्ध , प्रतिबद्ध 0dd562e , प्रतिबद्ध 0816f1d , प्रतिबद्ध 9bb3dea , 4d4bc15 प्रतिबद्ध , प्रतिबद्ध b309a97 , f213f06 प्रतिबद्ध , 86ed00a प्रतिबद्ध , facca7f प्रतिबद्ध , be1bb60 प्रतिबद्ध , efcf6cf प्रतिबद्ध , c20de8b प्रतिबद्ध , प्रतिबद्ध bfa50c2 , 3442c3d , 5b2f6d9 (07 अप्रैल 2020), 6542525a प्रतिबद्ध(04 अप्रैल 2020), और डेंटन लियू ( ) द्वारा fd6852c , 805d9ea (21 मार्च 2020) के लिए प्रतिबद्ध । ^{(द्वारा विलय Junio सी Hamano - - में प्रतिबद्ध bf10200 , 29 अप्रैल 2020)}Denton-L
gitster

pull: पास करना

^{साइन-ऑफ-बाय: डेंटन लियू}

इससे पहले, --autostashकेवल साथ काम किया था git pull --rebase।

हालांकि, पिछले पैच में, मर्ज सीखा और --autostashसाथ ही ऐसा कोई कारण नहीं है कि हमें यह प्रतिबंध क्यों न हो। मर्ज करने के
लिए पास --autostashकरना सिखाएं , ठीक उसी तरह जैसे उसने रिबेस के लिए किया था।

तथा:

rebase: apply_autostash()sequencer.c से उपयोग करें

^{साइन-ऑफ-बाय: डेंटन लियू}

apply_autostash()में समारोह builtin/rebase.cके लिए इसी तरह के लिए पर्याप्त है apply_autostash()में समारोह sequencer.cवे लगभग विनिमेय, की आर्ग वे स्वीकार करते हैं प्रकार के अलावा हैं। करsequencer.cसंस्करण को बाहरी और इसे रिबास में उपयोग करें।

रिबास संस्करण 6defce2b02 (" बिल्टइन रिबेस: सपोर्ट --autostashऑप्शन", 2018-09-04, Git v2.20.0-rc0 - बैच # 8 में सूचीबद्ध मर्ज ) से सी रूपांतरण के रूप में पेश किया गया था। इसने फंक्शन को डुप्लिकेट करने का विकल्प चुना, क्योंकि उस समय, शेल से सी के साथ-साथ इंटरएक्टिव रीबेस को परिवर्तित करने वाली एक और इन-प्रोग्रेस परियोजना थी और वे संस्करण को रीक्रिएट करके उनके साथ टकराव नहीं करना चाहते थे । चूंकि दोनों प्रयास लंबे समय से किए जा रहे हैं, इसलिए हम उन्हें स्वतंत्र रूप से एक साथ जोड़ सकते हैं।
sequencer.capply_autostash()

Comments

2.4.2 के अनुसार, इसे अभी तक लागू नहीं किया गया है। शायद किसी दिन। rebase.autoStashकेवल रिबास का उपयोग करते समय लागू होता है। pull.rebaseकेवल पुल का उपयोग करते समय लागू होता है।

— रान्डल श्वार्ट्ज

"गंदे पेड़ में भी काम करने के लिए एक साधारण गिट पुल के लिए पर्याप्त होगा।" जैसा कि रैंडल ने कहा, यह अभी तक सही नहीं है। वर्तमान मास्टर की पुल ..c अभी भी चुनता है die_on_unclean_work_tree।

— प्रधान

@ प्रधान मैं सहमत हूँ। कार्यान्वयन आज सुबह ही हो गया और 2.6 के लिए होना चाहिए। मैंने यह स्पष्ट करने के लिए उत्तर को संपादित किया है।

— VonC

मैंने पुष्टि की है कि ऑटोस्टैश गिट के साथ काम कर रहा है 2.5.5।

— जोशुआ हॉब्लेट

इसलिए हर कोई ऑटोस्टैश के बारे में लिख रहा है जब आप करते हैं rebase(या pull --rebase)। लेकिन जब आप pullमर्ज के साथ सामान्य करते हैं, तो कोई भी ऑटोस्टैशिंग नहीं करता है । तो उसके लिए कोई स्वचालित स्विच नहीं है? या मुझे कुछ याद आ रहा है? मैं करना पसंद करता हूं, git pull --rebaseलेकिन ओपी ने "मानक" के बारे में पूछाgit pull

— मारियस पावेल्स्की

Answer 2

आने वाले खोजकर्ताओं के लिए कुछ सेकंड बचाने के लिए, यहां एक सारांश है (@VonC के लिए धन्यवाद):

git pull --rebase --autostash

Comments

बिंदु है: के बाद एक git config pull.rebase trueऔर git config rebase.autoStash true, सभी तुम कभी हूँ की जरूरत है git pull। बस git pull। कोई अन्य विकल्प की आवश्यकता नहीं है।

— VonC

--autostashविकल्प के लिए आपको कम से कम Git 2.9 की आवश्यकता है। -c rebase.autoStash=trueGit 2.6 आगे में काम करता है।

— ntc2

Answer 3

जैसा कि ऊपर कहा गया है, दो कॉन्फिग वैल्यू सेट करने से वर्तमान में काम नहीं होता है git pull, क्योंकि ऑटोस्टैश कॉन्फिग केवल वास्तविक रिबैप्स पर लागू होता है। ये git कमांड्स वही करती हैं जो आप चाहते हैं:

git fetch
git rebase --autostash FETCH_HEAD

या इसे एक उपनाम के रूप में सेट करें:

git config alias.pullr '!git fetch; git rebase --autostash FETCH_HEAD'

फिर करो:

git pullr

बेशक, इस उपनाम को वांछित के रूप में बदला जा सकता है।

Answer 4

Git 2.6+ के साथ आप निम्नलिखित का उपयोग कर सकते हैं:

alias gup='git -c rebase.autoStash=true pull --rebase'

यह इसके बजाय --rebasegit-pull उपयोग rebaseकरता है merge, इसलिए सेटिंग्स / विकल्प--ff-only लागू नहीं होंगे।

मैं --ff-onlyडिफ़ॉल्ट रूप से ( git pull --ff-only) के साथ खींचने के लिए एक उपनाम का उपयोग कर रहा हूं , और उसके बाद gup(ऊपर से) का उपयोग कर सकता है यदि कोई तेजी से आगे मर्ज संभव नहीं है या स्टैक्ड परिवर्तन हैं।

Comments

के बीच मुख्य अंतर क्या है git pull --ff-onlyऔरgit pull pull --rebase --autostash

— alper

Answer 5

जैसा कि आप पहले ही उल्लेख कर चुके हैं कि यह करने का तरीका है। आप टाइपिंग को बचाने के लिए और शॉर्टकट का उपयोग करने के लिए इसे अन्य नाम से उपयोग कर सकते हैं या आप इसे एक ही पंक्ति में उपयोग कर सकते हैं (साथ ही यह एक अलार्म भी हो सकता है)

git stash && git pull --rebase && git stash pop

यह वही काम करेगा जो आपने किया था लेकिन एक लाइन (&&) में है और क्या आप उर्फ ​​के रूप में सेट हैं तो यह और भी छोटा होगा।

निम्न पंक्तियाँ आपके द्वारा खींच / धक्का देने से पहले आने वाले / बाहर जाने वाले परिवर्तनों को प्रदर्शित करेंगी

git log ^master origin/master
git log master ^origin/master

Comments

यह दृष्टिकोण असुरक्षित है: यदि कोई बात नहीं है, तो पहले आदेश कुछ नहीं करेगा, और फिर stash popपहले से कुछ यादृच्छिक सामान को हटा देगा।

— जॉन Zwinck

बस अतिरिक्त स्पष्ट होना: भले ही git stashगुप्त कोष में कुछ भी यह अभी भी "रिटर्न" कोई ERRORCODE नहीं है तो && अभी भी साथ जारी रहेगा git pullऔर git stash popऔर पिछले गुप्त कोष में पॉप। जब तक आप बहुत निश्चित नहीं हैं, तो बेहतर है कि इसका उपयोग न करें।

— मूनलाइट