क्या मुझे स्रोत नियंत्रण के लिए .vscode फोल्डर बनाना चाहिए?


294

क्या .vscodeफ़ोल्डर स्रोत नियंत्रण के लिए प्रतिबद्ध है?

एक ताजा परियोजना में, फ़ोल्डर खाली है, settings.jsonफ़ाइल को छोड़कर । इस फोल्डर में किस तरह की चीजें होंगी? क्या यह मशीन-विशिष्ट, .vsफ़ोल्डर की तरह डेवलपर-विशिष्ट है और इस तरह प्रतिबद्ध नहीं है? या सभी डेवलपर्स को इस फ़ोल्डर को साझा करना चाहिए और इस प्रकार यह प्रतिबद्ध होना चाहिए?

फ़ाइल के शीर्ष पर टिप्पणी में .vscode/settings.jsonकहा गया है:

// Place your settings in this file to overwrite default and user settings.
{
}

ऐसा लगता है कि फ़ोल्डर में प्रोजेक्ट-विशिष्ट सेटिंग्स होनी चाहिए और इस तरह स्रोत में शामिल होना चाहिए। इसके अलावा, UserVoice पर इस पोस्ट का अर्थ है कि कुछ टाइपिंग वहाँ जाएगी, यह भी सुझाव है कि इसे प्रतिबद्ध होना चाहिए।


यदि आप Visual Studio में कोई प्रोजेक्ट शुरू करते हैं और फिर इसे करते हैं तो एक उचित (कम से कम विशिष्ट) start .gitignore FE होना चाहिए। अगर यह वहाँ होने का मतलब है तो शायद यही होगा। आप इस का संदर्भ भी ले सकते हैं जिसे मैंने बिना किसी समस्या के उपयोग किया है।
चीफवूवेन्सिल्स

2
एक अच्छा विचार, @ChiefTwoPencils! रिकॉर्ड के लिए, .gitignoreविज़ुअल स्टूडियो जो डिफ़ॉल्ट बनाता है, उसमें .vscodeइस समय फ़ोल्डर को बाहर रखा जाता है। लेकिन चूंकि वीएस कोड अपने आप में नया है, इसलिए हो सकता है कि वे अभी तक इसके आसपास नहीं पहुंचे हों। जब मैंने इसके बारे में अधिक जानकारी प्राप्त की है, मैंने अभी के लिए फ़ोल्डर को छोड़ दिया है।
रोनाल्ड ज़रीट्स

जवाबों:


313

.vscodeयदि आप टीम के साथ सेटिंग्स, कार्य कॉन्फ़िगरेशन और डीबग कॉन्फ़िगरेशन साझा करना चाहते हैं, तो फ़ोल्डर में जांचें । मुझे लगता है कि अगर आप किसी टीम में सेटिंग्स लागू करना चाहते हैं तो आमतौर पर टीम के साथ सेटिंग्स (जैसे व्हॉट्सएप बनाम टैब) साझा करना समझ में आता है। हम वीएस कोड टीम में डिबग और टास्क विशिष्ट सेटिंग्स साझा करते हैं, क्योंकि हम चाहते हैं कि हमारी टीम वीएस कोड के लिए डिबग लक्ष्य और कार्य लक्ष्य का एक ही सेट हो।

Btw आपको .vscodeसेटिंग्स के लिए अपने प्रोजेक्ट में एक फ़ोल्डर रखने की आवश्यकता नहीं है । आप उपयोगकर्ता स्तर पर सेटिंग्स भी कॉन्फ़िगर कर सकते हैं।


54
धन्यवाद! "वीएस कोड टीम में हम ..." मेरे लिए काफी अच्छा है - शुरू करने के लिए, कम से कम!
रोनाल्ड ज़रीट्स

97
यदि आप "व्हॉट्सएप बनाम टैब" जैसी फ़ाइल-स्तरीय सेटिंग्स साझा करना चाहते हैं, तो आपको इसके बजाय EditorConfig जैसे क्रॉस-एडिटर समाधान को देखना चाहिए।
तंज87

2
इस निर्देशिका में 80 एमबी आकार का एक उपनिर्देशिका "क्रोम" है। क्या आप सुनिश्चित हैं कि यह भंडार के लिए प्रतिबद्ध होना चाहिए?
योन्गे

10
आप किसी चीज़ प्रोजेक्ट के लिए VSCode का उपयोग नहीं कर रहे होंगे जहाँ कार्यक्षेत्र सेटिंग्स में VirtualEnv या एनाकोंडा वातावरण जैसी चीज़ों के लिए वातावरण विशिष्ट पायथन पथ होने वाले हैं। इन फ़ाइलों की जाँच करना अधिकांश परिदृश्यों के लिए एक बड़ी समस्या की तरह लगता है। इसके बजाय एक नमूना / डिफ़ॉल्ट फ़ाइल में जांचें।
स्टीफनगोर्डन

3
फॉलोअप symbols.json: stackoverflow.com/questions/51876769/…
ripper234

39

प्रतिबद्ध / उपेक्षा के बीच तीसरा चतुर विकल्प है: .defaultप्रत्यय के साथ प्रतिबद्ध ।

उदाहरण के लिए आप जोड़ सकते हैं settings.jsonकरने के लिए .gitignore, और प्रतिबद्ध settings.json.default, बिल्कुल वैसे ही जैसे इसके साथ आम बात (मेरी टीम में) है .envफ़ाइलें।

मैंने वीडियो नियंत्रण संपादक सेटिंग्स से संस्करण नियंत्रण के लिए यह सलाह ली है ? मटियास पेटर जोहानसन द्वारा


5
एक settings.json.defaultसमझ में आता है लेकिन यह मान रहा है कि आपकी पूरी टीम बनाम कोड का उपयोग कर रही है और आपके कोडबेस को व्यापक दर्शकों के साथ साझा नहीं किया जा रहा है। मुझे लगता है कि GitHub पर मेरी ओपन सोर्स परियोजनाएं हैं, मैं सिर्फ यह सुनिश्चित करता हूं कि मैं इसे अपने डिफ़ॉल्ट gitignore में जोड़ दूं, क्योंकि मैं अपने कोडबेस के संभावित उपयोगकर्ताओं पर एक विशेष आईडीई को बाध्य नहीं करना चाहता हूं।
jamescampbell

2
@jamescampbell आईडीई-विशिष्ट फ़ाइलों को जोड़ना कभी भी उस आईडीई पर किसी को मजबूर नहीं करता है - यह सिर्फ उन्हें आपके सामान्य पर्यावरण सेटिंग्स को प्राप्त करने का विकल्प देता है यदि वे उस आईडीई का उपयोग करने के लिए करते हैं। बड़ा quesiton है कि क्या उन फ़ाइलों को आधिकारिक तौर पर समर्थन किया जाता है - यानी हमेशा अप-टू-डेट और काम करने का इरादा। सैद्धांतिक रूप से आपके पास विभिन्न IDE के लिए कई IDE वातावरण फ़ाइलें हो सकती हैं जो बिना किसी विरोध के सभी मौजूद हों।
लाइटसीसी

23
  • कभी नहीं .vscode/settings.json- के अजीब अपवाद के साथ search.exclude। यदि आपको वास्तव में जरूरत है, तो केवल अपने प्रोजेक्ट की विशेष सेटिंग्स लगाने से सावधान रहें जिन्हें आप अन्य डेवलपर्स के लिए लागू करना चाहते हैं ।
  • सत्यापन के लिए, स्वरूपण, अन्य फ़ाइलों संकलन उपयोग की तरह package.json, .eslint, tsconfig.json, आदि
  • एकमात्र .vscode जिसमें शामिल करने के लिए समझ में आता है, डीबगिंग के लिए जटिल लॉन्च कॉन्फ़िगरेशन हैं।
  • सावधान रहें, आपके सिस्टम में एक थर्ड पार्टी एक्सटेंशन हो सकता है जो वहाँ निजी जानकारी रख सकता है!

आप जो नहीं कर सकते हैं वह संपूर्ण सेटिंग कॉपी करें और चिपकाएँ .vscode/settings.json। मैं कुछ लोगों को ऐसा करते हुए देख रहा हूं और फ़ाइल करना एक अत्याचार है। उस स्थिति में आप न केवल दूसरों के कार्यक्षेत्र को तोड़ेंगे, बल्कि सबसे खराब यह होगा कि आप उन उपयोगकर्ताओं के लिए सेटिंग्स लागू करेंगे, जिन्हें आपको सौंदर्यशास्त्र, यूआई, अनुभव पसंद नहीं करना चाहिए। आप शायद उनके वातावरण को तोड़ देंगे क्योंकि कुछ बहुत ही सिस्टम पर निर्भर हैं। कल्पना कीजिए कि मेरे पास विज़न समस्याएं हैं इसलिए मेरी editor.*उपयोगकर्ता सेटिंग वैयक्तिकृत हैं और जब मैं आपकी परियोजना को खोलता हूं तो दृश्य बदल जाते हैं। कल्पना कीजिए कि मेरे पास विज़न समस्याएं हैं जिन्हें मुझे उपयोगकर्ता संपादक को निजीकृत करने की आवश्यकता है। * सेटिंग्स काम करने में सक्षम होने के लिए। मुझे गुस्सा होगा।

यदि आप गंभीर हैं तो प्रतिबद्ध न हों .vscode/settings.json। सामान्य तौर पर, सेटिंग्स जो एक विशेष परियोजना के लिए उपयोगी हो सकती हैं जैसे कि सत्यापन, संकलन, समझ में आता है, लेकिन सामान्य तौर पर आप विशेष रूप से कॉन्फ़िगरेशन कॉन्फ़िगरेशन फ़ाइलों जैसे .llint, tsconfig.json, .gitignore, package.json का उपयोग कर सकते हैं। मुझे लगता है कि vscode लेखकों ने सिर्फ नवागंतुक अनुभव को सरल बनाने के लिए फ़ाइल को जोड़ा है, लेकिन यदि आप गंभीर नहीं होना चाहते हैं!

एकमात्र अपवाद और विशेष मामलों में खोज की जा सकती है


3
मुझे लगता है कि आपका सुझाव .vscode/settingsबहुत अधिक प्रतिबंधात्मक है। यदि आप कर सकते हैं .eslintया .editorconfigफ़ाइलों का उपयोग करें , लेकिन आपको अभी भी जांचना चाहिए .vscode/settingsकि क्या आप वास्तव में टीम / प्रोजेक्ट पर सभी डेवलपर्स के बीच एक सेटिंग साझा करना चाहते हैं
मैट बिएनर

3
मैट, आप यह क्यों मानते हैं कि अन्य सभी डेवलपर्स vscode का उपयोग करते हैं? वेबस्टॉर्म, विम, सबलाइम का उपयोग करने वाले लोग हो सकते हैं, यही कारण है कि आपको एस्लिंट के साथ काम करना चाहिए, आदि और सेटिंग्स नहीं। json।
कैंसरबारो

फिर से, इस बात की जाँच .vscode/settingsकरें कि क्या आपकी टीम vscode का उपयोग करने वाली टीम पर काम कर रही है या आप एक ऐसी परियोजना पर काम कर रहे हैं जहाँ कई डेवलपर्स vscode का उपयोग करते हैं। इन सभी सेटिंग्स में क्रॉस-एडिटर समतुल्य नहीं हैं
मैट बिएनर

@MattBierner फेयर काफी, अगर आप किसी कंपनी में क्लोज सोर्स प्रोजेक्ट्स विकसित कर रहे हैं जो एडिटर को लागू करता है, लेकिन मुझे नहीं लगता कि यह एक सामान्य स्थिति है और विशेष रूप से ओपन सोर्स प्रोजेक्ट्स में ...
कैंसरबेरो

थर्ड पार्टी एक्सटेंशन के बारे में बात बहुत मान्य है - एक उदाहरण के रूप में, मेरा मानना ​​है कि एमएस एसक्यूएल एक्सटेंशन प्रोजेक्ट / वर्कस्पेस सेटिंग में कनेक्शन प्रोफाइल जोड़ देगा। मौजूद होने पर इसे हटा दें - हालाँकि यह क्रेडेंशियल स्टोर नहीं करता है, यह सर्वर के नाम आदि में जाँच हो सकती है। ।
दान हैरिस

18

अन्य उत्तरों को सारांशित करना

सिफारिश आम तौर पर .vscodeफ़ोल्डर को बाहर करने के लिए है , लेकिन चुनिंदा JSON फ़ाइलों को छोड़ दें जो अन्य डेवलपर्स को साझा सेटिंग्स को फिर से बनाने की अनुमति देती हैं।

शामिल करने के लिए सेटिंग्स के उदाहरण:

  • परीक्षण सूट चलाने के लिए भाषा विशिष्ट परीक्षण कॉन्फ़िगरेशन ( settings.json)
  • इस रेपो ( settings.json) में प्रयुक्त भाषा नियमों को लागू करने के लिए लिंटर और कोड फॉर्मेटिंग टूल्स के लिए एक्सटेंशन सेटिंग्स
  • रन और डिबग कॉन्फ़िगरेशन ( launch.json)
  • साझा कार्य - यदि VS कोड के साथ प्रबंधित किया गया है ( tasks.json)

ध्यान दें कि कुछ सेटिंग्स को कार्यक्षेत्र फ़ाइल में संग्रहीत किया जा सकता है, या इसे .vscode फ़ोल्डर से स्थानांतरित किया जा सकता है। निचे देखो।


.gitignoreउपयोग करने के लिए नमूना कोड (और इसे कहाँ प्राप्त करें)

यहाँ सेटिंग्स हैं, जैसा कि https://gitignore.io पर सुझाव दिया गया है । आप "VisualStudioCode" के लिए नवीनतम अनुशंसित .gitignoreफ़ाइल प्राप्त करने के लिए वहां खोज सकते हैं । मैं इस वेबसाइट को .gitignoreअपने अधिकांश नए रिपॉजिट के लिए शुरुआती बिंदु के रूप में उपयोग करता हूं:

# Created by https://www.gitignore.io/api/visualstudiocode
# Edit at https://www.gitignore.io/?templates=visualstudiocode

### VisualStudioCode ###
.vscode/*
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json

### VisualStudioCode Patch ###
# Ignore all local history of files
**/.history

# End of https://www.gitignore.io/api/visualstudiocode

इसके बाद के संस्करण में .gitignoreफ़ाइल, .vscode/*लाइन में सब कुछ बाहर करने के लिए कहते हैं .vscodeफ़ोल्डर है, लेकिन फिर !.vscode/a_specific_fileलाइनों के लिए "नहीं" उस फ़ोल्डर (में कुछ विशिष्ट फ़ाइलों को अनदेखा git बताओ settings.json, launch.json, आदि)। अंतिम परिणाम यह है कि .vscodeफ़ोल्डर में सब कुछ बाहर रखा गया है, विशेष रूप से उन अन्य लाइनों में से एक में नामित फ़ाइलों को छोड़कर।


अन्य कारकों और कैसे खुद के लिए बाहर चित्रा करने के लिए ...

.vscodeअपने रेपो में फ़ोल्डर को शामिल करना वास्तव में किसी को भी चोट नहीं पहुंचाता है जो एक अलग आईडीई (या पाठ / कोड संपादक) का उपयोग करता है।

हालाँकि, यह वीएस कोड का उपयोग करने वाले अन्य लोगों को चोट पहुंचा सकता है, अगर इन फ़ाइलों में जेनेरिक सेटिंग्स शामिल होती हैं, जो आपके पर्यावरण के लिए कुछ विशिष्ट की आवश्यकता होती है, जो कि उनके वातावरण में भिन्न होती है - जैसे कि निरपेक्ष पथ में रेपो स्थापित होता है (जो वीएस कोड पायथन एक्सटेंशन में लगातार डालता है। pythonpathमें .vscode/settings.json)। कुंजी बचत सेटिंग्स से बचने के लिए है जो आपके स्थानीय वातावरण के लिए कस्टम हैं, केवल उन लोगों को साझा करना जो सभी द्वारा उपयोग किए जा सकते हैं।

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


उपयोगकर्ता, कार्यक्षेत्र और फ़ोल्डर सेटिंग्स के बारे में

नोट:.vscode फ़ोल्डर में सेटिंग्स फाइलें आम तौर पर केवल तब अपडेट की जाती हैं जब आप सेटिंग्स के फ़ोल्डर संस्करण में बदलाव करते हैं (हालांकि बहुत सारे अपवाद प्रतीत होते हैं)।

  • यदि आप उपयोगकर्ता सेटिंग्स में बदलाव करते हैं, तो वे आमतौर पर कहीं और संग्रहीत किए जाते हैं।
  • यदि आप कार्यक्षेत्र सेटिंग्स में परिवर्तन करते हैं, तो वे सामान्य रूप से उस *.code-workspaceफ़ोल्डर में संग्रहीत होते हैं जिसे आप वर्तमान में उपयोग कर रहे हैं (वे अभी भी फ़ोल्डर सेटिंग्स फ़ाइलों में जाते हैं - लेकिन आप मैन्युअल रूप से उन्हें स्थानांतरित कर सकते हैं!)।

इसका मतलब है कि आपको अपने व्यक्तिगत पीसी के लिए कस्टम सेटिंग्स उपयोगकर्ता सेटिंग्स में डालनी चाहिए, और जब भी संभव हो, किसी विशेष प्रोजेक्ट / पैकेज के लिए सामान्य लोगों को डाल दें।

  • मैंने देखा है कि पायथन एक्सटेंशन का उपयोग करते समय, .vscode/settings.jsonफ़ाइल (जो फ़ोल्डर सेटिंग्स को बचाता है ) हमेशा pythonpathसेटिंग के तहत निरपेक्ष पथ को बचाता है , इसलिए मैंने अपनी .gitignoreफ़ाइलों से इसके बहिष्करण को हटा दिया है और अब इसे मेरे पायथन रिपोज को नहीं बचा सकता। यहां तक ​​कि अगर मैं इसे एक रिश्तेदार पथ के साथ सहेजता हूं, तो वीएस कोड बस इसे पूर्ण पथ पर रीसेट करता है।
  • इसके बजाय, मैं कोड को कार्यक्षेत्र के रूप में उपयोग करने की आवश्यकता वाले किसी भी फ़ोल्डर को सहेजता हूं (जैसे myproject.code-workspaceफ़ाइल के साथ एक फ़ाइल बनाएं -> इस प्रकार कार्यक्षेत्र सहेजें । इस तरह, आप कार्यक्षेत्र फ़ाइल में जाने वाली सामग्री को नियंत्रित कर सकते हैं और इसे हटाते हुए रेपो में सहेज सकते हैं। फ़ोल्डर सेटिंग्स फ़ाइल ( .vscode/settings.json)। आप बहुत अधिक कार्यक्षेत्र और फ़ोल्डर सेटिंग्स फ़ाइलों के बीच किसी भी सेटिंग को नियंत्रित कर सकते हैं कि क्या सहेजा जाता है और क्या नहीं। बस ध्यान रखें कि कार्यक्षेत्र फ़ाइल फ़ोल्डर सेटिंग फ़ाइल में कुछ भी ओवरराइड करेगी।

इसका लंबा और छोटा हिस्सा है - आप फ़ोल्डर सेटिंग्स फ़ाइल में स्थानीय सेटिंग्स डालते समय, केवल एक कार्यक्षेत्र फ़ाइल का उपयोग कर सकते हैं, और इसमें अधिकांश सामान्य सेटिंग्स डाल सकते हैं, हालांकि यह निर्भर करता है कि आप किन एक्सटेंशन / भाषाओं का उपयोग कर रहे हैं।

बेशक, आपके पास .vscode/settings.jsonफ़ाइल को बचाने या इसके कुछ हिस्से के लिए अन्य कारण हो सकते हैं । या यह आपकी वर्तमान भाषा में सेटिंग्स के लिए एक मुद्दा नहीं हो सकता है।

आपकी माइलेज भिन्न हो सकती है...


10

क्यों न सिर्फ प्रैक्टिस को देखा जाए, इधर-उधर के तर्कों के अलावा?

सबसे बड़ी परियोजना में से एक जो .vscodeमुझे अब तक मिली है वह मोज़िला फ़ायरफ़ॉक्स है । ऐसा लगता है कि फ़ायरफ़ॉक्स टीम अपने सामान्य कार्यों और अनुशंसित एक्सटेंशन को साझा करती है।

इसलिए मुझे लगता है कि यह एक बुरा विचार नहीं है .vscode, जब तक आप जानते हैं कि आप क्या कर रहे हैं।

जब मैं अन्य बड़ी परियोजनाओं को देखता हूं तो मैं इस पोस्ट को अपडेट करूंगा .vscode


8

अन्य उत्तरों के समान: नहीं।

चित्रण के रूप में, Git 2.19 (Q3 2018) द्वारा चुने गए दृष्टिकोण पर विचार करें, जो contrib/GSC कोडबेस के साथ VSCode के उपयोगकर्ताओं को बेहतर काम करने में मदद करने के लिए एक स्क्रिप्ट (इन ) जोड़ता है ।

दूसरे शब्दों में, .vscodeसामग्री उत्पन्न करें (यदि यह अभी तक मौजूद नहीं है), तो इसे संस्करण न दें।

देखें प्रतिबद्ध 12861e2 , 2a2cdd0 प्रतिबद्ध , 5482f41 प्रतिबद्ध , f2a3b68 प्रतिबद्ध , 0f47f78 प्रतिबद्ध , b4d991d प्रतिबद्ध , 58930fd प्रतिबद्ध , dee3382 प्रतिबद्ध , प्रतिबद्ध 54c06c6 द्वारा (30 जुला 2018) जोहानिस Schindelin ( dscho)
(द्वारा विलय Junio सी Hamano - gitster- में प्रतिबद्ध 30cf191 , 15 अगस्त 2018)

contrib: VS कोड कॉन्फ़िगरेशन को इनिशियलाइज़ करने के लिए एक स्क्रिप्ट जोड़ें

वीएस कोड एक हल्का लेकिन शक्तिशाली स्रोत कोड संपादक है जो आपके डेस्कटॉप पर चलता है और विंडोज, मैकओएस और लिनक्स के लिए उपलब्ध है।
अन्य भाषाओं में, इसका विस्तार के माध्यम से C / C ++ के लिए समर्थन है, जो न केवल कोड का निर्माण और डिबग करने की पेशकश करता है, बल्कि Intellisense, यानी कोड-अवगत पूर्ण और इसी तरह की बारीकियों को भी प्रस्तुत करता है।

यह पैच एक स्क्रिप्ट जोड़ता है जो पर्यावरण को वीएस कोड के साथ प्रभावी ढंग से काम करने में मदद करता है: बस यूनिक्स शेल स्क्रिप्ट चलाएं contrib/vscode/init.sh, जो प्रासंगिक फाइलें बनाता है, और वीएस कोड में गिट के स्रोत कोड के शीर्ष स्तर के फ़ोल्डर को खोलता है


1

इसका उत्तर "NO" है, क्योंकि .vscode फ़ोल्डर इस संपादक के लिए है और आपको दूसरों को भ्रमित करने के मामले में रेपो करने के लिए इन व्यक्तिगत सेटिंग्स को धकेलना नहीं चाहिए, इसलिए आप परिवर्तनों को अनदेखा करने के लिए इसे अपने प्रोजेक्ट की .gitignore फ़ाइल में जोड़ सकते हैं।


17
मैं आपके सख्त रुख से असहमत हूं। जैसा कि @BenjaminPasero द्वारा उत्तर में उल्लेख किया गया है, आपके पास नहीं है, लेकिन यह कई मामलों में समझ में आता है, जैसे कार्य कॉन्फ़िगरेशन साझा करना। बेशक, किसी के टीम के साथी का दिमाग होना अच्छा है और अनावश्यक रूप से उन पर तरजीह नहीं देना।
रोनाल्ड ज़रीट्स

हां, यही कारण है कि हमारे पास अलग-अलग उपयोगकर्ता सेटिंग्स और कार्यक्षेत्र सेटिंग्स (कार्यक्षेत्र में .vscode/settings.jsonफ़ाइल): code.visualstudio.com/docs/getstarted/… केवल उपकरण कॉन्फ़िगरेशन जैसे कार्यस्थान सेटिंग्स में जाते हैं
मैट बिएनर

@ RonaldZarīts .vscode फ़ोल्डर आपके स्वयं के संपादक की सेटिंग और कोड शैलियों के बारे में है, मुझे लगता है कि यह सिर्फ अपने उपयोग के लिए है, इसलिए जैसा कि मैंने पहले कहा था, फ़ोल्डर को नियंत्रण प्रवाह को धक्का न दें।
जियालिन ने

6
@jialinwang क्षमा करें, मैंने पहले ही कर दिया था। ;) एक तरफ चुटकुले, इसमें वे आइटम भी शामिल हैं जो साझा करने के लिए उपयोगी हैं, उदाहरण के लिए मेरी परियोजना में हमारे पास (1) launch.json- डिबगिंग के लिए लॉन्च कॉन्फ़िगरेशन हैं जो सेट करने के लिए गैर-तुच्छ हो सकते हैं। (2) settings.jsonप्रोजेक्ट स्तर सेटिंग्स, टाइपस्क्रिप्ट कंपाइलर का उपयोग करने के लिए, व्हाट्सएप नियमों की तरह, (3) tasks.json- कमांड का निर्माण। आप साझा नहीं करना चुन सकते हैं, लेकिन हम इसे उपयोगी पाते हैं।
रोनाल्ड ज़रीट्स

@jialinwang नहीं वे नहीं हैं। वे फ़ोल्डर-स्तरीय सेटिंग्स हैं। न केवल आपको शीर्ष-स्तरीय एक को शामिल करना चाहिए, यदि आपके पास उप-फ़ोल्डरों के लिए विशिष्ट कोई सेटिंग्स है, तो आपको उन्हें भी शामिल करना चाहिए। महत्वपूर्ण बात यह है कि अपनी उपयोगकर्ता प्राथमिकताओं को फ़ोल्डर-स्तरीय सेटिंग्स से बाहर रखें (यह अन्य कारणों से भी महत्वपूर्ण है)। आपके फ़ोल्डर-स्तरीय सेटिंग्स में आपके पास जिस तरह की चीज़ें होनी चाहिए, वह पूरे फ़ोल्डर पर लागू होनी चाहिए: फ़ॉर्मेटर्स, लिंटर, व्हॉट्सएप कन्वेंशन (जैसे ट्रिम अंतिम अनुरेखण नई लाइनें, टैब आकार ...) ...
डायलनयुंग

1

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

जब आप एक कार्यक्षेत्र बनाते हैं, तो आपको एक फ़ाइल सहेजने की आवश्यकता होती है code-workspace। इस फ़ाइल में कस्टम सेटिंग्स हैं, बस इस फ़ाइल को गिट रिपॉजिटरी से बाहर सहेजें और फ़ाइल .vscodeमें जोड़ने के लिए स्वतंत्र होंगे .gitignore

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.