जीआईटी में केवल बदलाव का मंचन - क्या यह संभव है?


364

क्या कोई तरीका है जिससे मैं सिर्फ अपने मंचन में बदलाव कर सकता हूं? जिस परिदृश्य में मुझे समस्या हो रही है वह यह है कि जब मैंने एक निश्चित समय में कई बग पर काम किया है, और कई अस्थिर परिवर्तन हुए हैं। मैं इन फ़ाइलों को व्यक्तिगत रूप से चरणबद्ध करने में सक्षम होना चाहता हूं, मेरी .patch फ़ाइलें बनाएं, और कोड स्वीकृत होने तक उन्हें हटा दें। इस तरह, जब मुझे यह मंजूर हो जाता है तो मैं अपना पूरा (वर्तमान) सत्र रोक सकता हूं, उस बग को पॉप कर सकता हूं और कोड को धक्का दे सकता हूं।

क्या मैं इसके बारे में गलत तरीके से जा रहा हूं? क्या मुझे गलतफहमी है कि मेरी प्रक्रिया को सरल बनाने के लिए git अन्य तरीकों से कैसे काम कर सकता है?


हां, आप शायद इस स्थिति में आने के लिए गलत काम कर रहे हैं। फिर भी एक उपयोगी प्रश्न। अगले स्टिक पर शुरू करने से पहले आपको वास्तव में स्टैश या ब्रांच करना चाहिए। , स्पर्शरेखा, उत्तर stackoverflow.com/a/50692885 , git में इसे संभालने का एक बेहतर तरीका है। अगर मैं ऊपर की ओर से आवागमन करता हूं, तो स्टैश के साथ खेलने से मेरे कार्य-क्षेत्र में अक्सर अजीब चीजें होती हैं।
शमूएल Samसलंद

जवाबों:


469

हाँ, यह संभव स्टाइल के साथ है

  1. अपनी सभी फ़ाइलों को स्टेज करें जिन्हें आपको स्टैश करने की आवश्यकता है।
  2. भागो git stash --keep-index। यह कमांड आपके सभी परिवर्तनों ( मंचन और अस्थिर ) के साथ एक टकराव पैदा करेगा, लेकिन आपकी कार्यशील निर्देशिका (अभी भी राज्य में मंचन) में हुए परिवर्तनों को छोड़ देगा।
  3. Daud git stash push -m "good stash"
  4. अब आपके "good stash"पास केवल चरणबद्ध फ़ाइलें हैं

अब अगर आपको स्टाॅस से पहले अनस्टेज्ड फाइल्स की जरूरत है, तो बस पहले स्टैश ( जिसके साथ बनाई गई है--keep-index ) को अप्लाई करें और अब आप उन फाइल्स को हटा सकते हैं जिन्हें आपने अपटेड किया है "good stash"

का आनंद लें


यह सबमॉड्यूल्स में परिवर्तन को रोकता है, भले ही उनका मंचन न किया गया हो। क्या इसके चारों ओर एक रास्ता है?
rluks

1
यह किसी भी तरह सभी नई फ़ाइलों (यहां तक ​​कि मंचन) को छोड़ दिया।
औरिमास

8
@ नई फ़ाइलों को स्टैश करने के लिए, आपको -uस्विच का उपयोग करने की आवश्यकता है ।
गायरोमाइट

2
जब आप पहले स्टैप को फिर से लागू करते हैं और सभी वापस बदल जाते हैं, जबकि आप केवल अपने unstages परिवर्तन उपयोग git stash apply --indexविकल्प में रुचि हो सकती है। यह आपकी संयुक्त (चरणबद्ध) स्थिति को बनाए रखने का प्रयास करेगा। अब काम करने वाले पेड़ से अवांछित बदलावों को दूर करना आसान है।
12

जबकि मुझे यह उत्तर देने के लिए वास्तव में क्या करने की आवश्यकता नहीं थी, - the-index-flag के बारे में जानना बहुत मददगार था।
आरोन क्रूस

128

नवीनतम गिट के साथ आप --patchविकल्प का उपयोग कर सकते हैं

git stash push --patch  

git stash save --patch   # for older git versions

और git आपको अपनी फाइलों में प्रत्येक बदलाव को जोड़ने या स्टैश में न करने के लिए कहेगा।
आप बस जवाब दो yयाn

युपीडी
के लिए उर्फ डबल गुप्त कोष :

git config --global alias.stash-staged '!bash -c "git stash --keep-index; git stash push -m "staged" --keep-index; git stash pop stash@{1}"'

अब आप अपनी फ़ाइलों को चरणबद्ध कर सकते हैं और फिर चला सकते हैं git stash-staged
परिणामस्वरूप आपकी स्टेज की गई फाइलें स्टैश में सेव हो जाएंगी

यदि आप चरणबद्ध फ़ाइलों को नहीं रखना चाहते हैं और उन्हें स्‍टेश में ले जाना चाहते हैं। फिर आप एक और उपनाम जोड़ सकते हैं और चला सकते हैं git move-staged:

git config --global alias.move-staged '!bash -c "git stash-staged;git commit -m "temp"; git stash; git reset --hard HEAD^; git stash pop"'

17
तकनीकी रूप से सवाल का जवाब नहीं है - लेकिन एक बहुत अच्छी तकनीक है जो चयनात्मक चोरी को प्राप्त करती है।
एलेक्सरेडन

6
सहमत हूँ, यह ठीक है, लेकिन यहाँ सवाल के साथ विचार यह है कि मैं पहले से ही बदलावों के मंचन के इस काम को पूरा कर चुका हूँ, जिसके साथ मैं कुछ करना चाहता हूँ (मूल रूप से प्रतिबद्ध करने के लिए, लेकिन अब जल्दबाज़ी करना चाहता हूँ), सिर्फ देखना नहीं इन सबको फिर से करो।
स्टीवन लू

4
नव निर्मित फ़ाइलों के लिए काम नहीं करता है (केवल संशोधित फ़ाइलों पर काम करता है)
डेरेक लिआंग

@ डेरेक लिआंग: नई बनाई गई फ़ाइलों को बिल्कुल ट्रैक नहीं किया जाता है। शायद आपको -u|--include-untrackedgit-stash
यूजेन कोनकोव

2
से डॉक्स : " सेव : यह विकल्प के पक्ष में पदावनत किया गया है Git गुप्त कोष में धक्का । यह गुप्त कोष में पुश 'में है कि यह pathspecs नहीं ले जा सकते हैं, और किसी भी गैर विकल्प तर्क संदेश फार्म से अलग है।"
बोरजोवस्की

53

मैंने एक स्क्रिप्ट बनाई जो केवल वर्तमान में मंचित है और बाकी सब कुछ छोड़ देती है। यह बहुत बढ़िया है जब मैंने बहुत सारे असंबंधित परिवर्तन करना शुरू कर दिया। बस इच्छित प्रतिबद्ध से संबंधित नहीं है और केवल स्टेज चरण।

(शुरुआती बिंदु के लिए बार्टोलोमिएज का धन्यवाद)

#!/bin/bash

#Stash everything temporarily.  Keep staged files, discard everything else after stashing.
git stash --keep-index

#Stash everything that remains (only the staged files should remain)  This is the stash we want to keep, so give it a name.
git stash save "$1"

#Apply the original stash to get us back to where we started.
git stash apply stash@{1}

#Create a temporary patch to reverse the originally staged changes and apply it
git stash show -p | git apply -R

#Delete the temporary stash
git stash drop stash@{1}


3
यह भी खूब रही! यदि मैंने कमांड लाइन पर एक दर्ज नहीं किया है, तो उपयोगकर्ता को एक स्टैश विवरण के लिए संकेत देने के लिए इसे ट्विक किया है
brookinc

1
यह 2.23.0 git के साथ बिल्कुल काम नहीं करता है।
thnee

धन्यवाद, मैंने उत्थान किया और इसे यहां एक उपनाम में बदल दिया: stackoverflow.com/a/60875067/430128
रमन

33

TL; DR बस -- $(git diff --staged --name-only)अपने git <pathspec>पैरामीटर के लिए जोड़ें

यहाँ एक साधारण लाइनर है:

git stash -- $(git diff --staged --name-only)

और बस एक संदेश जोड़ने के लिए:

git stash push -m "My work in progress" -- $(git diff --staged --name-only)

V2.17.1 और v2.21.0.windows.1 पर परीक्षण किया गया

सीमाएं:

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

6
मुझे लगता है कि यह वर्णित स्थिति पर सबसे अच्छा विकल्प है: समझने में आसान और कोई काला जादू शामिल नहीं है!
लुइस

1
यह बहुत साफ है। मैं इसे से एक उपनाम बनाने के लिए समाप्त हो गया!
कल्पेश पंचाल

उन्हें वोट देते रहो कॉमिन 😉
सोमो एस।

@KalpeshPanchal क्या आप अपना उपनाम साझा कर सकते हैं? मुझे यकीन नहीं है कि यह कैसे बच सकता है, इसलिए यह इसे सही ढंग से व्याख्या नहीं कर रहा है।
इगोर नादज

2
@IgorNadj ज़रूर! संदेश यह है: github.com/panchalkalpesh/git-aliases/commit/...
कल्पेश पांचाल

15

एक ही बात को पूरा करने के लिए ...

  1. जिन फाइलों पर आप काम करना चाहते हैं, उन्हें स्टेज करें।
  2. git commit -m 'temp'
  3. git add .
  4. git stash
  5. git reset HEAD~1

बूम। फ़ाइलें जो आप नहीं चाहते हैं, वे अटकी हुई हैं। आप जो फाइलें चाहते हैं, वे सभी आपके लिए तैयार हैं।


3
यह आसानी से सबसे अच्छा जवाब है और याद रखने में सबसे आसान है
केविन

9

इस परिदृश्य में, मैं प्रत्येक समस्या के लिए नई शाखाएँ बनाना पसंद करता हूँ। मैं उपसर्ग अस्थायी का उपयोग करता हूं / इसलिए मुझे पता है कि मैं बाद में इन शाखाओं को हटा सकता हूं।

git checkout -b temp/bug1

बग 1 को ठीक करने वाली फ़ाइलों को स्टेज करें और उन्हें कमिट करें।

git checkout -b temp/bug2

फिर आप आवश्यकता के अनुसार संबंधित शाखाओं से चेरी चुन सकते हैं और एक पुल अनुरोध सबमिट कर सकते हैं।


2
जबकि फैंसी स्टैशिंग ध्वनियों के बारे में जानना अच्छा है, व्यवहार में यह एक दृष्टिकोण की तरह लगता है, मुझे बोर्क की संभावना कम है।
रैंजडिलन

1
"Git चेरी-पिक tmpCommit" का उपयोग अस्थायी कमिट wo को मर्ज-कमिट या "git मर्ज tmpCommit" + "git रीसेट HEAD ^" के लिए बिना कमिटमेंट के प्राप्त करने के लिए करें।
सैमुअल 8:slund

1
जैसा कि यह उत्तर दिखाता है कि कभी-कभी सीधे यह पूछना बेहतर होता है कि आप दिए गए तकनीक से इसे कैसे प्राप्त करना चाहते हैं। अस्थायी शाखाएं और चेरी-पिक जटिल परिस्थितियों में काम करती हैं।
गनी ओजसन

यदि आपने आंशिक रूप से फ़ाइल का मंचन किया है, तो आपको मूल शाखा में वापस जाने और उन्हें फिर से पॉप करने से पहले अपने परिवर्तनों को छिपाने की आवश्यकता होगी
-ग्लैक्स

6

आप एक निश्चित बग के लिए परिवर्तन क्यों नहीं करते हैं और उस प्रतिबद्ध और उसके पूर्ववर्ती से एक पैच बनाते हैं?

# hackhackhack, fix two unrelated bugs
git add -p                   # add hunks of first bug
git commit -m 'fix bug #123' # create commit #1
git add -p                   # add hunks of second bug
git commit -m 'fix bug #321' # create commit #2

फिर, उपयुक्त पैच बनाने के लिए, उपयोग करें git format-patch:

git format-patch HEAD^^

यह दो फाइलें बनाएगा: 0001-fix-bug-123.patchऔर0002-fix-bug-321.patch

या आप प्रत्येक बग के लिए अलग-अलग शाखाएँ बना सकते हैं, इसलिए आप बग फिक्स को व्यक्तिगत रूप से मर्ज या रिबेट कर सकते हैं, या उन्हें हटा भी सकते हैं, अगर वे काम नहीं करते हैं।


2

git stash --keep-index एक अच्छा समाधान है ... सिवाय इसके कि हटाए गए रास्तों पर सही ढंग से काम नहीं किया गया, जो कि Git 2.23 (Q3 2018) में तय किया गया है

थॉमस Gummerer ( ) द्वारा प्रतिबद्ध b932f6a (16 जुलाई 2019) देखें । (द्वारा विलय Junio सी Hamano - - में प्रतिबद्ध f8aee85 , 25 जुला 2019)tgummerer
gitster

stash: हटाए गए फ़ाइलों को संभालने के साथ ठीक करें --keep-index

git stash push --keep-index सभी परिवर्तनों को अनुक्रमणिका और अनुक्रमणिका में जोड़ा गया है।

वर्तमान में यह सही ढंग से व्यवहार नहीं करता है जब कोई फ़ाइल इंडेक्स से निकाल दी जाती है।
इसे डिस्क पर हटाने के बजाय, ** - रखना-सूचकांक वर्तमान में फ़ाइल को पुनर्स्थापित करता है। **

git checkoutनो-ओवरले मोड में ' ' का उपयोग करके उस व्यवहार को ठीक करें, जो सूचकांक और काम करने वाले पेड़ को ईमानदारी से बहाल कर सकता है।
यह भी कोड को सरल करता है।

ध्यान दें कि यह अनट्रैक की गई फ़ाइलों को अधिलेखित कर देगा यदि अनट्रैक की गई फ़ाइल का नाम उसी फ़ाइल के रूप में है जिसे इंडेक्स में हटा दिया गया है।


2

Git में सिर्फ इंडेक्स (चरणबद्ध परिवर्तन) को स्ट्रैस करना उससे कहीं अधिक कठिन है। मैंने @ जो के जवाब को अच्छी तरह से काम करने के लिए पाया है , और इस उपनाम में एक मामूली बदलाव किया है:

stash-index = "!f() { \
  git stash push --quiet --keep-index -m \"temp for stash-index\" && \
  git stash push \"$@\" && \
  git stash pop --quiet stash@{1} && \
  git stash show -p | git apply -R; }; f"

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

बस अस्थिर परिवर्तनों (उपनाम stash-working) को चुराने की विपरीत समस्या के लिए यह उत्तर देखें ।


1

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

मान लें कि मास्टर प्रतिबद्ध बी पर है। अब बग # 1 पर काम करें।

git checkout -b bug1

अब आप शाखा बग 1 पर हैं। कुछ बदलाव करें, प्रतिबद्ध करें, कोड समीक्षा की प्रतीक्षा करें। यह स्थानीय है, इसलिए आप किसी और को प्रभावित नहीं कर रहे हैं, और यह आसान होना चाहिए कि गिट भिन्न से एक पैच बनाने के लिए पर्याप्त हो।

A-B < master
   \
    C < bug1

अब आप बग 2 पर काम कर रहे हैं। के साथ मास्टर करने के लिए वापस जाओ git checkout master। एक नई शाखा बनाओ git checkout -b bug2,। परिवर्तन करें, प्रतिबद्ध करें, कोड समीक्षा की प्रतीक्षा करें।

    D < bug2
   /
A-B < master
   \
    C < bug1

आइए दिखाते हैं कि जब आप समीक्षा का इंतजार कर रहे हों तो कोई और मास्टर पर ई एंड एफ करता है।

    D < bug2
   /
A-B-E-F < master
   \
    C < bug1

जब आपका कोड स्वीकृत हो गया है, तो आप इसे निम्न चरणों के साथ मास्टर करने के लिए रिबेस कर सकते हैं:

git checkout bug1
git rebase master
git checkout master
git merge bug1

यह निम्नलिखित में परिणाम देगा:

    D < bug2
   /
A-B-E-F-C' < master, bug1

फिर आप अपनी स्थानीय बग 1 शाखा को हटा सकते हैं, और आप जा सकते हैं। आपके कार्यक्षेत्र में एक समय पर एक बग, लेकिन स्थानीय शाखाओं के उपयोग से आपकी रिपॉजिटरी कई बगों को संभाल सकती है। और यह एक जटिल चरण / नृत्य से बचता है।

टिप्पणियों में ctote के प्रश्न का उत्तर दें:

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

तो git rebase -i

जब आप एक शाखा को दूसरे पर वापस करते हैं, तो आप इसे अंतःक्रियात्मक रूप से (-i ध्वज) कर सकते हैं। जब आप ऐसा करते हैं, तो आपके पास यह विकल्प होता है कि आप प्रत्येक कमिटमेंट के साथ क्या करना चाहते हैं। Pro Git एक भयानक पुस्तक है जो HTML प्रारूप में ऑनलाइन भी है, और इसमें रिबासिंग और स्क्वैशिंग पर एक अच्छा खंड है:

http://git-scm.com/book/ch6-4.html

मैं सुविधा के लिए उनके उदाहरण शब्दशः चुराता हूँ। आप निम्नलिखित प्रतिबद्ध इतिहास का वर्णन करें, और आप मास्टर पर बग 1 को रिबास और स्क्वैश करना चाहते हैं:

    F < bug2
   /
A-B-G-H < master
   \
    C-D-E < bug1

जब आप टाइप करेंगे तो यहां आपको दिखाई देगा git rebase -i master bug1

pick f7f3f6d changed my name a bit
pick 310154e updated README formatting and added blame
pick a5f4a0d added cat-file
#
# Commands:
#  p, pick = use commit
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

एक शाखा के सभी कमिट्स को एक एकल कमिट में स्क्वैश करने के लिए, पहले कमिट को "पिक" के रूप में रखें और बाद की सभी "पिक" प्रविष्टियों को "स्क्वैश" या "एस" के साथ बदलें। आपको प्रतिबद्ध संदेश बदलने का अवसर भी मिलेगा।

pick f7f3f6d changed my name a bit
s 310154e updated README formatting and added blame
s a5f4a0d added cat-file
#
# Commands:
#  p, pick = use commit
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit

तो हाँ, स्क्वाशिंग थोड़ा दर्द है, लेकिन मैं अभी भी इसे भारी मात्रा में उपयोग करने की सलाह दूंगा।


1
विस्तृत पोस्ट के लिए धन्यवाद! यह सुनिश्चित करने के लिए मेरे बहुत सारे मुद्दों को हल करता है - एकमात्र समस्या जो मुझे दिखाई देती है वह है हमारी वर्तमान टीम ने अनुरोध किया है कि हम सभी डिलीवरी को एक ही प्रतिबद्ध पर रखें। :(
मृदुक

1
यदि उन्हें उत्पादन रेपो में आपके कामकाजी इतिहास की आवश्यकता नहीं है या ठीक नहीं है तो: अपने ट्रैकिंग मास्टर इतिहास को मर्ज करने वाली शाखाओं के बजाय अलग-अलग लागू करके कम करें। आप यह जान सकते हैं कि एक सजी-संवरी शाखा को कैसे रखा जा सकता है जिसका वास्तविक विलय इतिहास हो और वह अपना वास्तविक काम करे, इस तरह सही अंतर पैदा करना आसान हो जाएगा।
jthill

2
ध्यान दें कि git checkout master; git checkout -b bug2छोटा किया जा सकता है git checkout -b bug2 master। वही लागू होता है git checkout bug1; git rebase master; git checkout master; git merge bug1, जो समान है git rebase master bug1; git push . bug1:master(दी गई है, pushचाल स्पष्ट नहीं है)
knittl

1
मैंने मुख्य उत्तर में ऊपर से
वार करने के

6
मैंने इसे अस्वीकार कर दिया है क्योंकि यह मूल प्रश्न का उत्तर नहीं देता है। मैं किसी चीज पर काम करने वाली शाखा में हूं, और मैंने सिर्फ एक बदलाव किया है जो मुझे लगता है कि एकीकरण शाखा के लिए अलग से प्रतिबद्ध होना चाहिए। मैं बस इतना ही करना चाहता हूं कि यह परिवर्तन हो और इसे स्टैश करें ताकि मैं अपनी वर्तमान "प्रगति में काम" शाखा के बजाय किसी अन्य शाखा में जाकर अलग से कमिट कर सकूं। (चेतावनी, आगे पीछे दौड़ते हुए।) यह बेतुका है कि ऐसा करना बहुत मुश्किल है; मुझे कल्पना करना है कि यह एक सामान्य घटना है। (एक शाखा में काम करना और एक त्वरित बदलाव
लाना जो

0

माइक Monkiewicz के जवाब के लिए आपकी टिप्पणियों में से मैं एक सरल मॉडल का उपयोग करने का सुझाव देता हूं: नियमित रूप से विकास शाखाओं का उपयोग करें, लेकिन अपनी मास्टर शाखा में एक एकल प्रतिबद्ध प्राप्त करने के लिए मर्ज के स्क्वैश विकल्प का उपयोग करें:

git checkout -b bug1    # create the development branch
* hack hack hack *      # do some work
git commit
* hack hack hack *
git commit
* hack hack hack *
git commit
* hack hack hack *
git commit
git checkout master     # go back to the master branch
git merge --squash bug1 # merge the work back
git commit              # commit the merge (don't forget
                        #    to change the default commit message)
git branch -D bug1      # remove the development branch

इस प्रक्रिया का लाभ यह है कि आप सामान्य गिट कार्य प्रवाह का उपयोग कर सकते हैं।


मैं नहीं देख सकता कि यह उत्तर कैसे मदद कर सकता है। यह मूल प्रश्न से संबंधित नहीं है।
फ्रैपन

0

टीएल; डीआर ;git stash-staged

एक उपनाम बनाने के बाद:

git config --global alias.stash-staged '!bash -c "git stash -- \$(git diff --staged --name-only)"'

यहाँ फ़ाइलों की git diffसूची देता है और फिर हम इस सूची को कमोड के रूप में पास करते हैं ।--staged--name-only
pathspecgit stash

से man git stash:

git stash [--] [<pathspec>...]

<pathspec>...
   The new stash entry records the modified states only for the files
   that match the pathspec. The index entries and working tree
   files are then rolled back to the state in HEAD only for these
   files, too, leaving files that do not match the pathspec intact.


-1

आकस्मिक परिवर्तन के लिए, विशेष रूप से कई फ़ाइलों को हटाने के लिए, निम्न कार्य करें:

git add <stuff to keep> && git stash --keep-index && git stash drop

दूसरे शब्दों में, बकवास को छिपाने और इसे पूरी तरह से छिपाने की जगह के साथ फेंक दें।

2.17.1 संस्करण में परीक्षण किया गया


एक टिप्पणी के बिना एक नीच मेरे लिए न तो सहायक है और न ही अगले पाठक ... zaenks क्रोधी एनॉन। हालांकि मैं इस वन-लाइनर के साथ एक समस्या की कल्पना कर सकता हूं: एक को बहुत सावधानी बरतनी चाहिए कि सभी वांछित बदलावों को सूचकांक में जोड़ना न भूलें, अन्यथा उन महत्वपूर्ण परिवर्तनों को भी हटा दिया जाएगा। लेकिन तब फिर से, किसी भी क्ली टूल का अन-सावधान उपयोग सबसे खराब स्थिति में किसी के कीमती समय और नौकरी के लिए बहुत खतरनाक हो सकता है।
wmax
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.