अस्थायी रूप से तोड़फोड़ में अवाँछित बदलावों को दूर रखें (एक ला "गिट-स्टैश")

Question

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

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

git-stash सिर्फ यही करने की अनुमति देता है। क्या तोड़फोड़ के साथ ऐसा करने का कोई तरीका है, या तो सीधे या कुछ प्लगइन या स्क्रिप्ट के साथ। ग्रहण प्लग भी ठीक होगा।

Comments

बस जिज्ञासु, लेकिन क्यों नहीं git-svn का उपयोग करें?

— cmcginty

कुछ प्रासंगिक समाचार: infoworld.com/d/application-development/… (उद्धृत करते हुए: "वह यह भी नोट करता है कि आगामी सबवर्सन 1.8 रिलीज को गिट की क्षमताओं के करीब लाना चाहिए, जिसमें गिट स्टैश जैसी विशेषताएं हैं, जिसमें एक डेवलपर स्थानीय रूप से बदलाव कर सकता है। और फिर उन्हें एक तरफ सेट करें, और ऑफलाइन कमिट करें, जो एक डेवलपर के ऑफ़लाइन होने पर रिकॉर्ड को पूरा करता है और जब डेवलपर फिर से आता है, तो मास्टर रिपॉजिटरी में चला जाता है। "

— सेबेस्टियन वैन डेन ब्रुक

अपडेट (2012-04-26 तक): शेल्टिंग अब 1.9 के लिए निर्धारित है, बिना किसी ईटीए के। इसलिए इसमें थोड़ा समय लग सकता है ...

— sleske

अद्यतन (2012-11-17 के अनुसार): शेल्विंग अब 1.10 के लिए निर्धारित है। शायद यह हमेशा <अगली रिलीज़ +1> के लिए निर्धारित है? ;-)

— सालेस्के

अपडेट (2015-03-23, 2 साल और आधे समय के बाद): अच्छी खबर यह है कि शेविंग अभी भी 1.10 के लिए निर्धारित है। बुरी खबरें ईटीए: Q2 2015 (अस्थायी) रिलीज 1.9.0 / 2017 हैं? (सर्वश्रेष्ठ पर सट्टा) १.१०.० रिलीज़ ( subversion.apache.org/roadmap.html )

— रिबामार

Answer 1

जब मुझे अपनी कार्य प्रतिलिपि में एक कार्य से परिवर्तन नहीं मिला और मुझे किसी अन्य कार्य पर स्विच करने की आवश्यकता है, तो मैं दो चीजों में से एक करता हूं:

1. दूसरे कार्य के लिए एक नई कार्य प्रतिलिपि देखें।

   या

2. एक शाखा शुरू करें:

   workingcopy$ svn copy CURRENT_URL_OF_WORKING_COPY SOME_BRANCH
   workingcopy$ svn switch SOME_BRANCH
   workingcopy$ svn commit -m "work in progress"
   workingcoyp$ svn switch WHATEVER_I_WAS_WORKING_ON_BEFORE
   

मेरे पास कुछ स्क्रिप्ट हैं जो इसे स्वचालित करने में मदद करती हैं।

Comments

यह आपके तोड़फोड़ सर्वर पर बहुत कूड़ेदान का परिणाम देगा

— knittl

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

— भारतीय स्टेट बैंक

@knittl: शाखा को असंगत पथ में बनाया जा सकता है जो परियोजना की डिफ़ॉल्ट शाखाओं या टैग स्थान से बाहर है। उदाहरण के लिए, एक टीम नामित project\temp\<creationdate-reason>या project\personal\<creationdate-reason>इस उद्देश्य के लिए कर सकती है ।

— rwong

यह अभी भी दुर्भाग्यपूर्ण है कि शाखा को सर्वर पर बिल्कुल बनाया जाना है। ऐसा नहीं है कि इस तरह की शाखाएं बहुत सारे डेटा की नकल करती हैं, लेकिन यह कि वे बहुत सारे अनावश्यक संदर्भ बनाते हैं जो कि बिना git जैसी प्रणाली करता है।

— थेपेर

यह एक बड़े भंडार के साथ उपयोगी नहीं है। यह मेरे काम के माहौल में एक विकल्प नहीं है। और जब मैं चाहता हूं कि हमारी रिपॉजिटरी छोटी और बेहतर संगठित थी, और काफी स्पष्ट रूप से, svn के बजाय एक गिट रिपॉजिटरी, मैं इस बात तक सीमित हूं कि हमारे संगठन में हमारे कोड को कैसे व्यवस्थित किया जाता है।

— एड्रियनवीट

Answer 2

यह ब्लॉग पोस्ट अंतर और पैच का उपयोग करने की सलाह देता है।

• git stash लगभग बन जाता है svn diff > patch_name.patch; svn revert -R .
• git stash apply हो जाता है patch -p0 < patch_name.patch

ध्यान दें कि यह मेटाडेटा परिवर्तन या (मुझे नहीं लगता) निर्देशिका निर्देशिका बनाता / हटाता नहीं है। (हां, svn उन कंटेंट को अलग-अलग डायरेक्टरी कंटेंट से अलग करता है, git के विपरीत।)

Comments

यह stackoverflow.com/questions/1554278/… का एक आकस्मिक डुप्लिकेट है - वहां अपवोट्स भेजें।

— वाल्टर मुंड

यह बाइनरी फ़ाइलों को भी शामिल नहीं करता है, जो कष्टप्रद है। पैच उत्पन्न करने के लिए कम से कम TortoiseSVN का उपयोग करते समय।

— कोणीय काल

stackoverflow.com/questions/159853/… इससे मदद मिल सकती है।

— वाल्टर मुंड

आप कम या ज्यादा मेटाडेटा ट्रैक कर सकते हैं यदि आप svn patch patch_name.patchइसके बजाय का उपयोग करते हैं patch -p0, क्योंकि वे पैच फ़ाइल में हैं, और svn पैच उन्हें समझता है।

— चटाई

इसमें बाहरी लोगों के परिवर्तन शामिल नहीं हैं।

— कॉंगसबोंगस

Answer 3

आप अपने वर्तमान परिवर्तनों svn diffको एक पैच फ़ाइल में संगृहीत कर सकते हैं , फिर अपनी कार्य प्रति को वापस लाएं:

svn diff > stash.patch
svn revert -R .

अपनी तैयारी सुविधा लागू करने के बाद, आप पैच उपयोगिता के साथ अपना पैच लागू कर सकते हैं:

patch < stash.patch

जैसा कि अन्य ने नोट किया है कि यह काम नहीं करेगा svn:properties पेड़ के संचालन (जोड़ने, हटाने, फ़ाइलों और निर्देशिकाओं को जोड़ने) के ।

बाइनरी फाइलें भी समस्याएं दे सकती हैं, मुझे नहीं पता कि पैच (या इस मामले में TortoiseSVN उन्हें कैसे संभालता है)।

Comments

मुझे लगता है कि यह हटाए गए / पुनर्नामित फ़ाइलों के साथ बहुत अच्छा काम नहीं करता है।

— जेसपेरे

"क्यों पैच के बजाय उपयोग क्यों करें" शीर्षक वाला बॉक्स देखें? svnbook.red-bean.com/en/1.5/… पर यह समझने के लिए कि यह एक बुरा विचार क्यों है।

— भारतीय स्टेट बैंक

@ एसबीआई: मुझे नहीं लगता कि डाउनवोट के लिए वैध औचित्य है। यह एक "बुरा जवाब" नहीं है। यह बिल्कुल सही जवाब नहीं है। मुझे नहीं लगता कि यह व्यक्ति अपने सुझाव के लिए सजा का हकदार है। क्या आप उसके बजाय जवाब देना पसंद करेंगे? यदि हाँ, तो हाँ, आपको डाउनवोट होना चाहिए। अन्यथा यह अच्छे इरादों को दंडित कर रहा है।

— सेदत कपपनोग्लू

अगर मेरे जैसे किसी और ने सोचा कि यह सबसे हल्का-वजन समाधान जैसा दिखता है और इसे आज़माने का फैसला किया, तो मुझे पैच -p0 <stash.patch का उपयोग करना पड़ा - अन्यथा यह शिकायत करता था कि वे पैच को खोजने में सक्षम नहीं हैं

— CupcTae

यह सलाह विशेष रूप से मदद करती है यदि आप एक पृष्ठभूमि पृष्ठभूमि से आ रहे हैं और विभिन्न कारणों से SVN का उपयोग करने के लिए मजबूर हैं। पैच के पहली बार उपयोगकर्ताओं के लिए पहले से दी गई सलाह में एक छोटा सा सुधार: $ patch --strip=0 < stash.patch इससे यह सुनिश्चित हो जाएगा कि जब आप अपना पैच अप्लाई कर रहे हैं तो पैच आपसे फ़ाइल का नाम नहीं पूछेगा।

— ksinkar

Answer 4

सबसे आसान तरीका इस तरह से एक अस्थायी शाखा का उपयोग करना होगा:

$ svn copy ^/trunk ^/branches/tempbranch
$ svn switch ^/branches/tempbranch
$ svn commit -m "Stashed"
$ svn switch ^/trunk
$ ... hack away in trunk ...
$ svn commit -m "..."
$ svn merge ^/branches/tempbranch .
$ svn rm ^/branches/tempbranch
$ ... continue hacking

यदि इसे और अधिक नियमित रूप से किया जाता है, तो इसे एक स्क्रिप्ट में रखा जा सकता है।

Comments

यह मतदान क्यों किया जाता है, जबकि "समाधान" को वोट दिया जाता है जो तब भी काम नहीं करता है जब आपने फ़ाइलों को हटा दिया है / जोड़ा है या किसी भी गुण को बदल दिया है? हां, जब आप इसे पहली बार करते हैं, तो यह सबसे आसान काम नहीं है, लेकिन, समानांतर में काम करने के लिए एक और कॉपी की जाँच करने के अलावा, यह एकमात्र समाधान है जो सभी मामलों में काम करता है।

— भारतीय स्टेट बैंक

रेपो रूट के लिए ^ सिंटैक्स का अच्छा उपयोग (svn 1.6 के बाद से)। अच्छा समाधान जब आपके रेपो में शीर्ष स्तर पर ट्रंक / टैग / शाखाएं हों।

— बेन्डिन

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

— साल्स्के

@ स्लेसके: हाँ, आप सर्वर पर अपना अस्थायी स्लैश कर रहे हैं, लेकिन शाखा ही हटा दी जाती है। वैसे भी, मुझे लगता है कि यह सबसे तेज और सबसे मजबूत तरीका है।

— जेसपर

@ एसएमएस: एसवीएन एक वितरित वीसीएस नहीं है, इसलिए सब कुछ सर्वर पर होना चाहिए। यह वैसा ही है जैसा होना चाहिए।

— sbi

Answer 5

1.10.0 (2018-04-13) के अनुसार, आपके पास प्रयोगात्मक svn shelveकमांड है । ( TortoiseSVN कमांड का समर्थन करता है ) यह एक पैच को बचाने और वापस लागू करने के लिए एक हेल्पर के अलावा कुछ भी नहीं है, इसलिए इसकी svn diff+ जैसी सीमाएं होती हैं patch(यानी बाइनरी फ़ाइलों और नाम बदलने में सक्षम नहीं)। ( संपादित करें : लगता है कि बाइनरी समर्थन अगले संस्करण 1.11.0 पर आ रहा है )

^ ^ 2 संपादित करें: 1.11.0 (2018-10-30 जारी) के साथ, बाइनरी फाइलें समर्थित हैं । शेल्फ़ किए गए फ़ाइलों का नामकरण असमर्थित रहा। 1.11 में आश्रय 1.10 द्वारा बनाई गई अलमारियों के साथ असंगत है।

^ ^ 3 संपादित करें: 1.12.0 (2019-04-24 को जारी किया गया) के साथ, कॉपी और नाम बदलने का समर्थन किया जाता है । 1.12 में शेलिंग पहले के संस्करणों द्वारा बनाई गई अलमारियों के साथ असंगत है।

संपादित करें ^ 4: 1.13.0 और के साथ ठंडे बस्ते में कोई बदलाव नहीं हुआ है 1.14.0 के हुआ है । कमांड अभी भी प्रयोगात्मक के रूप में चिह्नित हैं और आपको SVN_EXPERIMENTAL_COMMANDS=shelf3सुविधा को सक्षम करने के लिए परिभाषित करने की आवश्यकता है । ऐसा लगता है कि यह सुविधा वर्तमान में अप्राप्त है ।

डिजाइन नोट्स डेवलपर्स के विकी पर पाए जा सकते हैं ।

$ svn x-shelve --help
x-shelve: Move local changes onto a shelf.
usage: x-shelve [--keep-local] SHELF [PATH...]

  Save the local changes in the given PATHs to a new or existing SHELF.
  Revert those changes from the WC unless '--keep-local' is given.
  The shelf's log message can be set with -m, -F, etc.

  'svn shelve --keep-local' is the same as 'svn shelf-save'.

  The kinds of change you can shelve are committable changes to files and
  properties, except the following kinds which are not yet supported:
     * copies and moves
     * mkdir and rmdir
  Uncommittable states such as conflicts, unversioned and missing cannot
  be shelved.

  To bring back shelved changes, use 'svn unshelve SHELF'.

  Shelves are currently stored under <WC>/.svn/experimental/shelves/ .
  (In Subversion 1.10, shelves were stored under <WC>/.svn/shelves/ as
  patch files. To recover a shelf created by 1.10, either use a 1.10
  client to find and unshelve it, or find the patch file and use any
  1.10 or later 'svn patch' to apply it.)

  The shelving feature is EXPERIMENTAL. This command is likely to change
  in the next release, and there is no promise of backward compatibility.

Valid options:
  -q [--quiet]             : print nothing, or only summary information
  --dry-run                : try operation but make no changes
  --keep-local             : keep path in working copy

(...)

$ svn x-unshelve --help
x-unshelve: Copy shelved changes back into the WC.
usage: x-unshelve [--drop] [SHELF [VERSION]]

  Apply the changes stored in SHELF to the working copy.
  SHELF defaults to the newest shelf.

  Apply the newest version of the shelf, by default. If VERSION is
  specified, apply that version and discard all versions newer than that.
  In any case, retain the unshelved version and versions older than that
  (unless --drop is specified).

  With --drop, delete the entire shelf (like 'svn shelf-drop') after
  successfully unshelving with no conflicts.

  The working files involved should be in a clean, unmodified state
  before using this command. To roll back to an older version of the
  shelf, first ensure any current working changes are removed, such as
  by shelving or reverting them, and then unshelve the desired version.

  Unshelve normally refuses to apply any changes if any path involved is
  already modified (or has any other abnormal status) in the WC. With
  --force, it does not check and may error out and/or produce partial or
  unexpected results.

  The shelving feature is EXPERIMENTAL. This command is likely to change
  in the next release, and there is no promise of backward compatibility.

Valid options:
  --drop                   : drop shelf after successful unshelve
(...)

$ svn help | grep x-
 x-shelf-diff
 x-shelf-drop
 x-shelf-list (x-shelves)
 x-shelf-list-by-paths
 x-shelf-log
 x-shelf-save
 x-shelve
 x-unshelve

Answer 6

मैं सिर्फ svn के साथ ऐसा करने का एक आसान तरीका नहीं जानता। ईमानदारी से, मैं git-svnएक git रेपो बनाने के लिए उपयोग करने की सलाह दूंगा जो एक svn वर्किंग कॉपी के रूप में काम करता है, और बस उसी के git stashसाथ उपयोग कर रहा है। बस के git pullसाथ git svn rebaseऔर git pushसाथ बदलें git svn dcommitऔर आप वास्तव में अपने git वर्कफ़्लो का 90% रख सकते हैं और अभी भी एक svn सर्वर से बात कर रहे हैं।

Comments

लेकिन लिंक stackoverflow.com/questions/1554278/… मैं उपरोक्त टिप्पणियों में उल्लेख करता हूं कि व्यावहारिक समाधान का प्रस्ताव केवल svn में ही करना है।

— VonC

काफी उचित; वास्तव में, Google मुझे अभी उस समाधान पर एक ब्लॉग पर ले जाता है। मैं अब भी इस सवाल का जवाब देता हूं कि इस प्रश्नकर्ता के लिए git-svn एक प्राकृतिक समाधान है।

— वाल्टर मुंड

मुझे संदेह है कि समाधान फ़ाइल नाम का अनुसरण करता है, क्योंकि गिट नहीं करता है।

— NO_NAME

Answer 7

svn-stashGPL 3 के तहत उपलब्ध एक छोटा अजगर 2 स्क्रिप्ट है : https://github.com/frankcortes/sive-shash ।

यह svn diff/patchबताए गए समाधानों की तरह काम करता है और कुछ स्थानीय निर्देशिका में बदलाव के रूप में धकेलने और पॉपिंग प्रदान करता है। दुर्भाग्य से, स्टैम्स का नाम नहीं दिया जा सकता है, और केवल पिछले एक को पॉप किया जा सकता है (ठीक है, हाँ, यह एक स्टैक है, लेकिन इस तरह की सीमा का कोई वास्तविक कारण नहीं है।) लेकिन फिर, आप हमेशा लापता सुविधाओं का निर्माण कर सकते हैं। स्रोत।

यह * ix के लिए लिखा गया है, लेकिन हर "/" को बदलने के बाद os.sepयह अच्छी तरह से विंडोज के तहत काम करता है।

यदि आप svn 1.7 या उच्चतर का उपयोग करते हैं, तो आपको बदलने की आवश्यकता है is_a_current_stash(): लाइन को हटा दें if ".svn" in os.listdir(CURRENT_DIR):, क्योंकि 1.7 WC में केवल एक शीर्ष-स्तर .svn उपखंड है।

Comments

यह विंडोज़ के तहत मेरे लिए नहीं है! :(

— एंटोनियो पेट्रीका

Answer 8

आप इसे Intellij IDEA - Shelve Changes का उपयोग करके आसानी से कर सकते हैं

Comments

इस तरह से संभाल सकता है metadata changesऔर directory creates/deletes? जैसे क्या git stashकरता है?

— वॉनसुक

Answer 9

एक अन्य विकल्प अपने वर्तमान चेकआउट को एक नई निर्देशिका में कॉपी करना और अपने सभी परिवर्तनों को वापस करना है। इस तरह से आप अपने सर्वर पर एक अस्थायी शाखा बनाने के झंझट से बच जाएंगे - आखिर चोरी एक स्थानीय ऑपरेशन है, जिसे हर किसी को नहीं देखना चाहिए और इसे अक्सर किया जा सकता है।

अपना हॉटफ़िक्स करने के बाद आप अपनी मुख्य वर्किंग कॉपी को अपडेट कर सकते हैं और अपना "स्टैशिंग एरिया" हटा सकते हैं

Comments

नोट: यह अनिवार्य रूप से दूसरी वर्किंग कॉपी की जाँच के समान है - केवल चेकआउट के बिना :-)।

— sleske

@ स्लेस्क: हाँ, एक नए चेकआउट के लिए आवश्यक बड़ी मात्रा में बैंडविड्थ के बिना

— knittl

यह पसंद है या नहीं, यह वह जवाब है जो अधिक बारीकी से "गिट स्टैश" व्यवहार को प्रतिबिंबित करता है। एक शाखा आईएस कूल है, लेकिन टीएफएस ठंडे बस्ते में डालने से संबंधित है।

— चार्ल्स रॉबर्टो कैनाटो

Answer 10

मुझे भी यह सुविधा चाहिए थी। मैं वर्तमान में TortoiseSVN का उपयोग करता हूं।

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

या, एक और समाधान HEAD से दूसरे निर्देशिका में शाखा करने के लिए हो सकता है, अपने परिवर्तन और कमिट करें। एक बार जब आप उन लोगों को अपनी दूसरी कामकाजी कॉपी में वापस करने के लिए तैयार हो जाते हैं, तो एक अपडेट करें और अपने परिवर्तनों को मर्ज करें।

Answer 11

मैं हमेशा एक दूसरा चेकआउट रखता हूं, जिसे मैं "ट्रंक_क्लाइन" कहता हूं। जब भी मुझे जो करना है उससे संबंधित एक त्वरित, अलग-थलग परिवर्तन करने की आवश्यकता है, मैं इसके बजाय उस चेकआउट पर प्रतिबद्ध हूं।

Answer 12

ऊपर दिए गए ब्रांचिंग और पैचिंग विचार बहुत अच्छे हैं, लेकिन वे मेरे लिए अच्छी तरह से काम नहीं करते हैं। मैं एक दृश्य भिन्न उपकरण का उपयोग करता हूं, इसलिए रनिंग git diffटेक्स्ट-आधारित पैच का उत्पादन नहीं करता है। हमारी बिल्ड सिस्टम हर बार एक शाखा बनने पर एक नए वातावरण का निर्माण करती है, इसलिए अस्थायी "स्टैश" शाखाओं को बनाने से गड़बड़ हो जाएगी।

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

Answer 13

वाल्टर के जवाब के आधार पर मैंने अपनी बाश आर्क फ़ाइल में निम्नलिखित उपनाम बनाए हैं:

alias svn.stash='read -p "saving local changes in raq.patch. Existing stash in raq.patch will be overwritten. Continue?[y/N]" && [[ $REPLY =~ ^[yY] ]] && rm -f raq.patch && svn diff > raq.patch && svn revert -R .'
alias svn.stash.apply='patch -p0 < raq.patch; rm -f raq.patch'

ये उपनाम उपयोग करने और याद रखने में बहुत आसान हैं।

उपयोग:

svn.stash to stash बदलाव और svn.stash.apply stash लगाने के लिए।

Answer 14

मेरे व्यवहार में, मैं अपने तोड़फोड़ भंडार की निर्देशिका git initमें एक गिट रिपॉजिटरी बनाने के लिए उपयोग करता trunkहूं, और फिर मैं *.gitनीलामी में पैटर्न को अनदेखा करता हूं।

कुछ फ़ाइलों को संशोधित करने के बाद, अगर मैं अपने काम को तोड़फोड़ की मुख्य धारा के साथ जारी रखना चाहता हूं, तो मैं सिर्फ git stashअपने काम को रोकने के लिए उपयोग करता हूं। तोड़फोड़ भंडार के लिए प्रतिबद्ध करने के बाद, मैं git stash popअपने संशोधनों को बहाल करने के लिए उपयोग करता हूं।

Comments

यह वास्तव में एक अच्छा समाधान है! कई अन्य समाधान समस्या को हल करने के लिए 3 पार्टी टूल का उपयोग करते हैं; यह एक Git को 3rd पार्टी टूल के रूप में उपयोग करता है। इसके कई फायदे हैं: 1) Git बहुत सामान्य और शक्तिशाली है। 2) कई लोगों के पास पहले से ही Git इंस्टॉल है।

— Lii

मैं उत्सुक हूँ कि यह कैसे काम करता है अगर आप भी एक कमिट नहीं करते हैं।

— बी 2 के

Answer 15

उपयोग:

svn cp --parents . ^/trash-stash/my-stash

यह वर्तमान स्थान और वर्तमान संशोधन से एक शाखा बनाएगा, और फिर यह उस शाखा में काम करने की प्रतिलिपि में परिवर्तन किए बिना परिवर्तन करेगा।

उपयोग: कॉपी SRC [@REV] ... DST

SRC और DST प्रत्येक कार्यशील प्रति (WC) पथ या URL हो सकते हैं:

WC  -> URL:  immediately commit a copy of WC to URL

ध्यान दें कि काम की प्रतिलिपि में परिवर्तन स्वचालित रूप से वापस नहीं किया जाएगा ( cpयह सिर्फ एक नई शाखा में परिवर्तन सह रहा है ) और आपको उन्हें मैन्युअल रूप से वापस करना होगा।

परिवर्तनों को पुनर्स्थापित करने के लिए, आप नई बनाई गई शाखा से परिवर्तन को अपनी कार्य प्रति में मर्ज कर सकते हैं।

svn merge --ignore-ancestry ^/trash-stash/my-stash -c <commited revision>

--ignore-ancestry काम की प्रतिलिपि में मर्ज जानकारी को अद्यतन नहीं करने के लिए उपयोग किया जाता है।

उपयोग:

svn ls -v ^/trash-stash/

यह देखने के लिए कि आपके पास क्या मार्ग है। प्रतिबद्ध संशोधन भी मुद्रित हैं।

यदि आपको अब स्टैश की आवश्यकता नहीं है, तो बस चलाएं:

svn rm ^/trash-stash/my-stash

यह समाधान पैच का उपयोग करने से बेहतर है कि यदि कॉपी में परिवर्तन के साथ काम की प्रतिलिपि में या वर्तमान शाखा संघर्ष में नए परिवर्तन, आप svn साधनों का उपयोग करके संघर्षों को हल कर सकते हैं, जबकि patchकुछ मामलों में बस विफल हो जाएंगे या गलत तरीके से पैच भी लगा सकते हैं।

Answer 16

चूंकि तोड़फोड़ stashपूरी तरह से सुविधा का समर्थन नहीं करता है,
मैं बस इस तरह से मैनुअल तरीके से करता हूं।

एक अलग पथ के लिए जगह Developmentऔर Production(release)परियोजना।

source\code\MyApp         -- Development
release\MyApp(release)    -- Production(release)

आप विकास पथ में अपनी परियोजना के लिए कोई नई सुविधाएँ काम कर सकते हैं,
और आप केवल सार्थक प्रगति करेंगे या स्थिर के लिए कुछ जारी किया जाना चाहिए।

जब आपको इसे उत्पादन के लिए जारी करना है, तो उत्पादन परियोजना खोलें, svn को अपडेट करें और रिलीज (निर्माण, निर्यात ... आदि) के लिए सामान करें।

मुझे पता है कि यह थोड़ा परेशान करता है, लेकिन प्रगति जारी करना अक्सर नहीं होता है (यह मेरे लिए नहीं है, लेकिन मुझे पता है कि कुछ परियोजनाएं प्रगति को विकसित करने के लिए तुलना करती हैं, यह तरीका मेरे लिए फिट बैठता है।

मैं विशिष्ट परियोजनाओं के लिए svn का उपयोग कर रहा हूं क्योंकि परियोजना टीम के सदस्य इसका उपयोग करते हैं, इसलिए मुझे पालन करना होगा।
सबसे अच्छा समाधान यह है gitकि एक पूर्ण संस्करण नियंत्रण प्रणाली का उपयोग करें और इससे बेहतर है svn।

Comments

यह बिल्कुल स्पष्ट नहीं है कि आप क्या कर रहे हैं (आपके द्वारा उल्लिखित निर्देशिकाओं में क्या संस्करण की जाँच की गई है?), लेकिन यह शीर्ष-मतित उत्तर के डुप्लिकेट की तरह दिखता है ("नई वर्किंग कॉपी देखें")।

— 19:51 पर साल्स्के

@ सॉल्स क्षमा करें, मैंने आपके मामले का विवरण नहीं पढ़ा है। मेरे मामले में, मुझे केवल devऔर केवल prod2 स्थितियों की आवश्यकता है। पूरी तरह से नई कार्यक्षमता विकसित करने के लिए svn के साथ जटिल होगा। मुझे यकीन नहीं है अगर svn दुनिया में आपके मामले को हल करने के लिए स्पष्ट विधि है।

— वॉनसुक