मैं Git रिपॉजिटरी में एक खाली निर्देशिका कैसे जोड़ सकता हूं?


4261

मैं Git रिपॉजिटरी में एक खाली निर्देशिका (जिसमें कोई फ़ाइल नहीं है) कैसे जोड़ सकता हूं?


16
हालांकि यह उपयोगी नहीं है, एक खाली (वास्तव में खाली) निर्देशिका को अपने रेपो में हैक करने का एक तरीका हैcheckoutहालांकि, यह Git के वर्तमान संस्करणों के साथ नहीं होगा ।
tiwo

335
@tiwo मैं एक असहमत हूं कि यह उपयोगी नहीं है। आपकी निर्देशिका पदानुक्रम आपकी परियोजना का हिस्सा है, इसलिए इसे संस्करण नियंत्रित किया जाना चाहिए।
जेंबले

114
मेरे मामले में, मैं tmp फ़ाइलों के लिए एक निर्देशिका संरचना जोड़ना चाहूंगा, लेकिन स्वयं tmp फ़ाइलें नहीं। ऐसा करने से, मेरे परीक्षक की सही संरचना होती है (अन्यथा त्रुटियां हैं) लेकिन मैं tmp डेटा के साथ अपने कमेंट्स को रोकना नहीं चाहता। तो हाँ, यह मेरे लिए उपयोगी है!
एडम मार्शल

45
@AdamMarshall मुझे लगता है कि tiwo यह कह रहा था कि हैक उपयोगी नहीं है, क्योंकि इसे चेकआउट द्वारा अनदेखा किया गया है। Tmp dirs एक VCS के लिए एक उपयोगी सुविधा की तरह ध्वनि करते हैं।
क्वांटम 7

31
क्यों नहीं प्रक्रिया है कि tmp फ़ाइलों को भी बनाता tmp निर्देशिका बनाता है?
RyPeck

जवाबों:


4125

एक निर्देशिका रहने का दूसरा तरीका (लगभग) खाली (भंडार में) .gitignoreउस निर्देशिका के अंदर एक फ़ाइल बनाना है जिसमें ये चार पंक्तियाँ हैं:

# Ignore everything in this directory
*
# Except this file
!.gitignore

तब आपको उस आदेश को सही तरीके से प्राप्त करने की आवश्यकता नहीं है जो आपको m104 के समाधान में करना है

यह भी लाभ देता है कि जब आप एक गिट स्थिति करते हैं तो उस निर्देशिका में फ़ाइलें "अनट्रैक" के रूप में दिखाई नहीं देंगी।

बनाना @GreenAsJade की टिप्पणी लगातार:

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


25
मुझे लगता है कि @ जोनी द्वारा प्रस्तावित README समाधान को इस एक के साथ प्रयोग किया जाना चाहिए; .gitignore फ़ाइल हम संस्करण नियंत्रण से बाहर रखना चाहते हैं की एक व्याख्या प्रदान करता है, जबकि README फ़ाइल बताती है कि निर्देशिका का उद्देश्य क्या है, जो दोनों जानकारी के बहुत महत्वपूर्ण टुकड़े हैं।
११

18
@pedromanoel मैं उस दस्तावेज़ को लिखता हूँ जिसे आप फ़ाइल के READMEअंदर डालेंगे .gitignore(टिप्पणियों के रूप में)।
कार्लोस कैंपडरो जूल 19'13

69
1 अंतर हाजिर करें: 1.) एक खाली फ़ोल्डर, 2.) .गितिग्नोर फ़ाइल के साथ एक फ़ोल्डर। ;-)
बजे पीटर पेर्ह

6
यह कैश फ़ोल्डर के लिए एकदम सही है ।
सुगन्धित

10
दुर्भाग्य से, यह एक गैर-खाली निर्देशिका में परिणामित होता है, इसमें एक छिपी हुई फ़ाइल होती है।
पेड्रो

1090

आप नहीं कर सकते। Git FAQ देखें ।

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

उनके अंदर फाइलें जोड़ते समय निर्देशिकाएँ अपने आप जुड़ जाती हैं। यही है, निर्देशिकाओं को रिपॉजिटरी में कभी नहीं जोड़ना पड़ता है, और अपने दम पर ट्रैक नहीं किया जाता है।

आप " git add <dir>" कह सकते हैं और यह वहां फाइलों को जोड़ देगा।

यदि आपको वास्तव में चेकआउट में मौजूद होने के लिए निर्देशिका की आवश्यकता है, तो आपको इसमें एक फ़ाइल बनानी चाहिए। .ignignore इस उद्देश्य के लिए अच्छी तरह से काम करता है; आप इसे खाली छोड़ सकते हैं, या उन फ़ाइलों के नाम भर सकते हैं, जिन्हें आप निर्देशिका में दिखाने की उम्मीद करते हैं।


67
नीचे उत्तर बेहतर है। तथ्य यह है कि निम्न स्तर के सॉफ़्टवेयर की अनुमति नहीं देता है यह मेरे लिए उतना महत्वपूर्ण नहीं है जितना कि खाली निर्देशिका की आवश्यकता होने पर वास्तव में Git का उपयोग करना। एक 2 पंक्ति को जोड़ने के लिए .itignore मुझे स्वीकार्य लगता है।
अमला

1
अच्छी तरह से अगर कोई एक नई निर्देशिका में फ़ाइलों को स्थानांतरित करना चाहता है, तो वे ऐसा नहीं कर सकते हैं git mvक्योंकि गिट शिकायत करेगा कि नई निर्देशिका संस्करण नियंत्रण में नहीं है
लालूला

16
आप इस लगातार सवाल के लिए इंटरनेट पर " यह असंभव है, आप नहीं कर सकते, आदि " पढ़ सकते हैं । .gitignoreचाल अक्सर जवाब है, और संतुष्ट कई जरूरतों को। हालाँकि यह वास्तव में खाली निर्देशिका बनाने के लिए संभव है , मेरा जवाब देखें
ofavre

2
हालांकि अधिक मैं इसके बारे में लगता है, और अधिक यह की तरह "रिक्त स्ट्रिंग का SHA हैश" लगता है, यदि वह मौजूद है, वास्तव में होता , एक खाली पेड़ के लिए एक अच्छी तरह से परिभाषित पहचानकर्ता हो जब तक यह बताने के लिए है कि वस्तु है कि क्या असंभव हो जाएगा एक पेड़ या एक बूँद।
एमिल लुंडबर्ग

21
मैंने बहुत सारे रिपोज देखे हैं जो .gitkeepइस उद्देश्य के लिए बुलाई गई खाली फाइल का उपयोग करते हैं ।
सुकिमा

759

.gitkeepनिर्देशिका में एक खाली फ़ाइल बनाएं , और उसे जोड़ें।


58
मैंने इसके बजाय बनाने के लिए प्रोत्साहित करने वाला उत्तर जोड़ा है .keep
एक्यूमेनस

205
.gitkeepGit द्वारा निर्धारित नहीं किया गया है और लोगों को इसके अर्थ का दूसरा अनुमान लगाने जा रहा है, जो उन्हें Google खोजों पर ले जाएगा, जो उन्हें यहां ले जाएगा। .gitउपसर्ग सम्मेलन फ़ाइलों और निर्देशिकाओं के लिए आरक्षित किया जाना चाहिए कि Git ही उपयोग करता है।
t-mart

10
@ t-mart " .gitउपसर्ग सम्मेलन आरक्षित होना चाहिए ..." क्यों? क्या जीआईटी इस आरक्षण का अनुरोध करता है?
सीमित प्रायश्चित

9
इस मामले में READMEया एक ABOUTफ़ाइल अच्छी या बेहतर होगी। अगले आदमी के लिए एक नोट छोड़ना, ठीक वैसे ही जैसे हम सभी यूआरएल से पहले करते थे।
डेव

5
अगर आप एक यूनिट टेस्ट लिख रहे हैं तो यह काम नहीं करता है कि खाली निर्देशिका पर कोड का परीक्षण करना चाहिए ...
thebjorn

435

आप हमेशा निर्देशिका में एक README फ़ाइल डाल सकते हैं कि आप यह क्यों चाहते हैं, अन्यथा रिक्त स्थान, रिपॉजिटरी में निर्देशिका।


39
+1, अच्छा सुझाव, एक खाली निर्देशिका का कोई मतलब नहीं है जब तक कि यह भविष्य में उपयोग नहीं होने वाला है। तो इसके अंदर एक README फाइल बनाएं और लिखें कि यह डायरेक्टरी किस लिए है, और भविष्य में कौन सी फाइलें वहां रखी जाएंगी। यह दोनों समस्याओं को हल करता है।
सईदग्नु

63
@ सिलसिला बकवास। खाली निर्देशिका वाली निर्देशिका संरचना कई स्थितियों में अत्यधिक वांछनीय हो सकती है (जैसे एमवीसी ऐप जहां आप एक मॉडल निर्देशिका चाहते हैं, लेकिन अभी तक कोई भी मॉडल बनाने के लिए आस-पास नहीं पहुंचे हैं, या एक साझा विचार निर्देशिका आप साझा विचारों को बाद में जोड़ने के लिए योजना बनाते हैं। )। इसके अलावा, इनमें से हर एक में एक README डालना अधिक स्पष्ट है क्योंकि यह स्पष्ट है कि वे वहाँ क्या कर रहे हैं, और उनमें से प्रत्येक में एक README को रखना भूल जाना आसान है। और जब आप उनके साथ कुछ अन्य फाइलें जोड़ते हैं तो आपको README को हटाना याद रखना होगा। मूल रूप से, गिट को निश्चित रूप से खाली निर्देशिका की अनुमति देनी चाहिए।
Jez

20
@ जेज: मैं असहमत हूं। मुद्दा यह है कि गिट को स्रोत (कोड) को नियंत्रित करने के लिए डिज़ाइन किया गया है। महत्वपूर्ण रूप से, एक कमिट की आईडी सामग्री का हैश है। यह कहना है, यह सामग्री होनी चाहिए। आपको पेड़ के हर हिस्से में एक README की आवश्यकता नहीं है , केवल पत्ती नोड्स हैं। यदि आपके पास स्थान हैं, तो आप कोड डालने का इरादा रखते हैं, लेकिन कोई कोड नहीं है, और आप समय को "मॉडल के लिए जगह" >> README पर भी ग्रहण करने में समय नहीं लेंगे, तो आपके पास जो विचार है वह एक प्रतिबद्ध नहीं है। यह हित के लिए नहीं है। "मैं XYZ खाली निर्देशिकाओं के लिए रनिंग ऐप चाहता हूं" कहना एक रनटाइम समस्या है, स्रोत समस्या नहीं। इसे w / अपने इंस्टॉलर को हैंडल करें।
जो एत्ज़बर्गर

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

7
@ jbo5112 हां, जिस "विशेष कोड" का आप उल्लेख करते हैं, वह "इंस्टॉलर" है जिसका मैंने उल्लेख किया है। आपके वेबएप्प इंस्टॉलेशन को पहले से ही डेटाबेस, लोकल कॉन्फिगरेशन, डिपेंडेंसी या 100 अन्य ऑपरेशंस बनाने के लिए संभालना है, लेकिन एक जोड़ी खाली डिरेक्टरी इससे परे हैं? ट्रायल, पैसेंजर, शेफ, एक आदिम मेकफाइल आदि की कोशिश करें। डायरेक्टरी बनाने और ऐप इंस्टॉल करने के दूसरे (संभावित रूप से अधिक जटिल / खतरनाक) काम के बीच कोई सुरक्षा अंतर नहीं है। और अगर आपके पास वास्तव में कोई deps, config, DB, आदि और कोई इंस्टॉलर नहीं है, तो बस README का उपयोग करें। किसी भी मामले में आपको दोनों करने की आवश्यकता नहीं है।
जो एत्ज़बर्गर

348
touch .keep

लिनक्स पर, यह एक खाली फ़ाइल बनाता है जिसका नाम है .keep। इसके लायक क्या है, यह नाम Git के लिए अज्ञेय है, जबकि Git के .gitkeepलिए विशिष्ट होगा। दूसरे, जैसा कि किसी अन्य उपयोगकर्ता ने नोट किया है, द.git उपसर्ग सम्मेलन को उन फाइलों और निर्देशिकाओं के लिए आरक्षित किया जाना चाहिए जो गिट खुद का उपयोग करते हैं।

वैकल्पिक रूप से, जैसा कि एक अन्य जवाब में कहा गया है , निर्देशिका में एक वर्णनात्मक READMEया README.mdफ़ाइल हो सकती है

बेशक इसके लिए यह आवश्यक है कि फ़ाइल की उपस्थिति आपके एप्लिकेशन को तोड़ने का कारण न बने।


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

14
सवाल और प्रमुख सामान्य चिंता एक खाली निर्देशिका को जोड़ने के बारे में है। यदि बाद में इसमें कोई निवासी फ़ाइल है, तो स्पष्ट रूप से .keepफ़ाइल को हटा दें या इसे अस्वीकृत करें। अगर इसके बजाय डायरेक्टरी की फाइलों को नजरअंदाज किया जाए, तो यह बिल्कुल अलग सवाल है।
एक्यूमेनस

3
यह सुझाव दिया गया था कि git clean -nd | sed s/'^Would remove '// | xargs -I{} touch "{}.keep"यह सभी अनुपयोगी खाली निर्देशिकाओं में करेगा।
एक्यूमेनस

1
इस समाधान को पसंद न करें, यह अनुमान लगाना कठिन है कि यह फ़ाइल क्या करती है। इसके अलावा, यदि आप अपने देव वातावरण (जैसे लॉग या चित्र, आदि) में फ़ाइलें उत्पन्न कर रहे हैं, तो यह isn`t उन फ़ाइल को संस्करण से रखने और उत्पादन में अपना रास्ता बनाने के लिए नहीं है, जो अच्छा नहीं है।
danielrvt

1
विंडोज़ को बिना नाम वाली फाइलें पसंद नहीं हैं और इसे पूरा करने के लिए विशेष जादू की आवश्यकता होती है (उर्फ बाश जैसा टर्मिनल ऐप या समकक्ष)।
EntangledLoops

303

हमें खाली संस्करण वाले फ़ोल्डर की आवश्यकता क्यों होगी

पहली चीजें पहले:

एक खाली निर्देशिका Git संस्करण प्रणाली के तहत एक पेड़ का हिस्सा नहीं हो सकती

इसे आसानी से ट्रैक नहीं किया जाएगा। लेकिन ऐसे परिदृश्य हैं जिनमें "संस्करण" रिक्त निर्देशिका सार्थक हो सकती हैं, उदाहरण के लिए:

  • एक पूर्वनिर्धारित फ़ोल्डर संरचना को मचान , रिपॉजिटरी के प्रत्येक उपयोगकर्ता / योगदानकर्ता को उपलब्ध कराना; या, ऊपर के एक विशेष मामले के रूप में , अस्थायी फ़ाइलों के लिए एक फ़ोल्डर बनाना , जैसे कि एक cache/या logs/निर्देशिका, जहाँ हम फ़ोल्डर प्रदान करना चाहते हैं लेकिन आपकी .gitignoreसामग्री
  • उपरोक्त से संबंधित, कुछ प्रोजेक्ट कुछ फ़ोल्डरों के बिना काम नहीं करेंगे (जो अक्सर खराब डिज़ाइन किए गए प्रोजेक्ट का एक संकेत है, लेकिन यह एक वास्तविक वास्तविक दुनिया का परिदृश्य है और हो सकता है, कहते हैं, अनुमति समस्याओं को संबोधित किया जा सकता है)।

कुछ ने वर्कअराउंड का सुझाव दिया

कई उपयोगकर्ता सुझाव देते हैं:

  1. READMEनिर्देशिका को गैर-रिक्त बनाने के लिए कुछ सामग्री के साथ एक फ़ाइल या दूसरी फ़ाइल रखना , या
  2. .gitignoreएक तरह के "रिवर्स लॉजिक" (यानी सभी फाइलों को शामिल करने के लिए) के साथ एक फाइल बनाना , जो अंत में दृष्टिकोण 1 के समान उद्देश्य को पूरा करता है।

जबकि दोनों समाधान निश्चित रूप से काम करते हैं मैं उन्हें Git संस्करण के लिए एक सार्थक दृष्टिकोण के साथ असंगत पाता हूं।

  • आपको फर्जी फाइलें या READMEs क्यों रखने हैं जो शायद आप वास्तव में अपनी परियोजना में नहीं चाहते हैं?
  • क्यों .gitignoreएक चीज़ करने के लिए उपयोग करें ( फ़ाइलों को रखते हुए ) जो कि इसके लिए है ( फ़ाइलों को छोड़कर ) के लिए बहुत विपरीत है , भले ही यह संभव है?

.आगामी दृष्टिकोण

वर्जनिंग सिस्टम में फोल्डर की मौजूदगी को मजबूर करने के लिए खाली फाइल का उपयोग करें .gitkeep

हालांकि यह इतना बड़ा अंतर नहीं लग सकता है:

  • आप एक फ़ाइल का उपयोग करते हैं जिसमें फ़ोल्डर रखने का एक ही उद्देश्य होता है। आप कोई ऐसी जानकारी नहीं रखते हैं जिसे आप नहीं डालना चाहते।

    उदाहरण के लिए, आपको READMEs का उपयोग करना चाहिए, साथ ही, उपयोगी जानकारी के साथ READMEs, फ़ोल्डर रखने के लिए एक बहाने के रूप में नहीं।

    चिंताओं का पृथक्करण हमेशा एक अच्छी बात है, और आप अभी भी .gitignoreअवांछित फ़ाइलों को अनदेखा करने के लिए जोड़ सकते हैं ।

  • इसका नामकरण यह .gitkeepफ़ाइल नाम से ही (और अन्य डेवलपर्स के लिए भी बहुत स्पष्ट और स्पष्ट है , जो एक साझा परियोजना के लिए अच्छा है और एक जीआईटी रिपॉजिटरी के मुख्य उद्देश्यों में से एक) यह फ़ाइल है

    • कोड के लिए एक फ़ाइल असंबंधित (अग्रणी बिंदु और नाम के कारण)
    • एक फाइल स्पष्ट रूप से Git से संबंधित है
    • इसका उद्देश्य ( रखना ) स्पष्ट रूप से बताया गया है और इसकी अनदेखी के अर्थ में सुसंगत और शब्दार्थ का विरोध किया गया है

दत्तक ग्रहण

मैंने लारवेल , कोणीय-सीएलआई.gitkeep जैसे बहुत महत्वपूर्ण ढाँचों द्वारा अपनाए गए दृष्टिकोण को देखा है ।


8
आपने एक विचार याद किया - फोल्डर रखने और खाली करने का क्या कारण है (जैसे / लॉग, / tmp, / अपलोड)? हां - इसका फोल्डर खाली रखने के लिए। :) इसलिए अगर आप किसी फोल्डर को खाली रखना चाहते हैं, तो आपको उसके अंदर मौजूद फाइलों को नजरअंदाज करना होगा।
रोमन

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

45
@Bhhnam: मैं डाउनवोट ले जाऊंगा, लेकिन एसओ मेटा पर मेरा शोध क्रिया के उत्तरों के प्रति कोई चिंता नहीं दिखाता है, जब तक कि वे हर पाठक (और हर कौशल स्तर) के लिए उपयोगी होने के लिए पर्याप्त विस्तार और स्पष्टता प्रदान करते हैं। फिर भी मैं किसी भी आलोचना के लिए खुला हूं और सार्वजनिक रूप से कारण घोषित करने के लिए धन्यवाद, मैं इसे बहुत सकारात्मक रूप से लेता हूं।
क्रैनियो

4
यदि आप अपने उत्तर को .gitkeepकिसी अन्य गैर-पूर्व-उपसर्गित फ़ाइल नाम से बदलने के लिए संपादित करते हैं, तो आपको मेरा उत्थान मिलेगा, मुझे लगता है कि यह सबसे अच्छा और सबसे जानकारीपूर्ण उत्तर है। कारण: मुझे लगता है कि ".गित *" को गिट निर्धारित फाइलों के लिए आरक्षित किया जाना चाहिए, जबकि यह सिर्फ एक मात्र प्लेसहोल्डर है। मेरा पहला अनुमान जब मैंने देखा कि उदाहरण के लिए एक ".गितिक" फ़ाइल को ऑटो-अनदेखा किया जाएगा (जो कि एक अच्छी सुविधा होगी) लेकिन यह मामला नहीं है, है ना?
जॉनी

5
मुझे आश्चर्य है कि लोगों के पास यह समझने का इतना कठिन समय क्यों है कि कोई "खाली" फ़ोल्डरों को गिट में जोड़ना चाहता है। आपको कहीं शुरू करना है, है ना? तो, आमतौर पर आप अपनी परियोजनाओं के साथ शुरू करते हैं फ़ोल्डर संरचना और - अफसोस - परियोजना की शुरुआत में अभी तक वहां कुछ भी नहीं है। एक बार आपका प्रोजेक्ट रेपो हो जाने के बाद, टीम के कार्यकर्ता क्लोन कर सकते हैं और एसएएमई संरचना पर काम करना शुरू कर सकते हैं।
BitTickler

127

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

find . -type d -empty -exec touch {}/.gitignore \;

21
आप find . -name .git -prune -o -type d -empty -exec touch {}/.gitignore \;
.गित

3
अधिकांश स्थितियों के लिए एक सरल भिन्नता हैfind * -type d -empty -exec touch {}/.gitignore \;
अखन

2
चूंकि OS X लगभग हर निर्देशन में .DS_Store फ़ाइल बनाता है, इसलिए यह वहां काम नहीं करता है। केवल (DANGEROUS!) वर्कअराउंड मैंने पाया, सभी .DS_Store फ़ाइलों को पहले के माध्यम से हटाना था find . -name .DS_Store -exec rm {} \;और फिर इस उत्तर से पसंदीदा संस्करण का उपयोग करना था। केवल सही फ़ोल्डर में इसे निष्पादित करना सुनिश्चित करें!
zerweck

1
क्या किसी को कमांड लाइन से विंडोज में ऐसा करने का तरीका पता है? मैंने रूबी और पायथन में यहां कुछ समाधान देखे हैं, लेकिन अगर यह प्रबंधित किया जा सकता है तो मैं एक नंगे पत्थर का समाधान चाहूंगा।
मिग 82

1
@ लखन कमांड .gitignoreके -emptyझंडे पर कोई प्रभाव नहीं डालता है find। मेरी टिप्पणी .DS_Storeनिर्देशिका ट्री में फ़ाइलों को हटाने के बारे में है, इसलिए -emptyध्वज को लागू किया जा सकता है।
zerweck

67

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

एक तरफ के रूप में, यह एक कार्यान्वयन मुद्दा है, न कि एक मौलिक गिट भंडारण डिजाइन समस्या। जैसा कि गिट मेलिंग सूची में कई बार उल्लेख किया गया है, इसका कारण यह है कि यह लागू नहीं किया गया है कि किसी ने इसके लिए एक पैच जमा करने के लिए पर्याप्त देखभाल नहीं की है, यह नहीं कि यह नहीं किया जा सकता है या नहीं किया जाना चाहिए।


4
ठीक यही बात मैंने कही है। मेरे द्वारा पोस्ट किए गए FAQ के स्निपेट में दोनों पैराग्राफ को संबोधित किया गया है।
एंडी लेस्टर

1
मुझे लगता है कि एक तरफ का पता लगाना और जानना उपयोगी है - इसे ठीक किया जा सकता है, बस जल्द से जल्द इसकी उम्मीद न करें, जब ज्यादातर मामलों के लिए इस तरह का आसान तरीका है।
wnoise

क्षमा करें, मैंने अंतिम पैराग्राफ नहीं पढ़ा है, और जब मैंने पहला पैराग्राफ पढ़ा, ठीक है, मुझे यकीन नहीं है कि मैंने वह जानकारी क्यों दोहराई।
अरस्तू पैग़ाल्टज़िस

2
बेशक, यह अतिरिक्त उत्तर तथ्य की ओर इशारा करता है।
माइकल जॉनसन

मैं यहाँ एक ऐसे मामले को देख रहा हूँ जहाँ निर्देशिका नहीं होने पर निर्माण गिर गया और डिफ़ॉल्ट रूप से यह खाली है, लेकिन इसे खाली करने की आवश्यकता नहीं है। .Gitignore बनाना सही काम करता है।
जोशुआ

33

रूबी ऑन रेल्स निर्माण रास्ता फ़ोल्डर लॉग इन करें:

mkdir log && touch log/.gitkeep && git add log/.gitkeep

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

लॉगफ़ाइल्स को जारी करके बाहर रखा जा सकता है,

echo log/dev.log >> .gitignore

लेकिन आपको शायद पता था।


23
रूबी को रेल पर क्या करना है?
क्वोलोन प्रश्न


30

गिट खाली निर्देशिकाओं को ट्रैक नहीं करता है। अधिक स्पष्टीकरण के लिए Git FAQ देखें । सुझाए गए समाधान को .gitignoreखाली निर्देशिका में एक फ़ाइल डालनी है । मुझे वह उपाय पसंद नहीं है, क्योंकि द.gitignore यूनिक्स सम्मेलन द्वारा "छिपा" है। इसके अलावा कोई स्पष्टीकरण नहीं है कि निर्देशिका खाली क्यों हैं।

मैं खाली निर्देशिका में एक README फ़ाइल डालने का सुझाव देता हूं जिसमें बताया गया है कि निर्देशिका खाली क्यों है और इसे Git में ट्रैक करने की आवश्यकता क्यों है। जगह में README फ़ाइल के साथ, जहाँ तक Git का संबंध है, निर्देशिका अब खाली नहीं है।

असली सवाल यह है कि आपको गिट में खाली निर्देशिका की आवश्यकता क्यों है? आमतौर पर आपके पास कुछ प्रकार की बिल्ड स्क्रिप्ट होती है जो संकलन / चलने से पहले खाली निर्देशिका बना सकती है। अगर नहीं तो एक बनाइए। यह खाली निर्देशिकाओं को गिट में डालने से कहीं बेहतर उपाय है।

तो आपके पास कुछ कारण है कि आपको गिट में खाली निर्देशिका की आवश्यकता क्यों है। उस कारण को README फाइल में डालें। इस तरह से अन्य डेवलपर्स (और भविष्य में) आपको पता है कि खाली निर्देशिका की आवश्यकता क्यों है। आपको यह भी पता चल जाएगा कि आप खाली निर्देशिका को हटा सकते हैं जब खाली निर्देशिका की आवश्यकता वाली समस्या हल हो गई है।


प्रत्येक खाली निर्देशिका को सूचीबद्ध करने के लिए निम्नलिखित कमांड का उपयोग करें:

find -name .git -prune -o -type d -empty -print

प्रत्येक खाली निर्देशिका में प्लेसहोल्डर READMEs बनाने के लिए:

find -name .git -prune -o -type d -empty -exec sh -c \
  "echo this directory needs to be empty because reasons > {}/README.emptydir" \;

निर्देशिका में सब कुछ अनदेखा करने के लिए README फ़ाइल को छोड़कर निम्नलिखित पंक्तियों को अपने में रखें .gitignore:

path/to/emptydir/*
!path/to/emptydir/README.emptydir
path/to/otheremptydir/*
!path/to/otheremptydir/README.emptydir

वैकल्पिक रूप से, आप हर README फाइल को नजरअंदाज करने से रोक सकते हैं:

path/to/emptydir/*
path/to/otheremptydir/*
!README.emptydir

पहले से ही बनाए जाने के बाद हर README को सूचीबद्ध करने के लिए:

find -name README.emptydir

28

चेतावनी: यह मोड़ वास्तव में काम नहीं कर रहा है क्योंकि यह निकला है। असुविधा के लिए खेद है।

नीचे मूल पोस्ट:

मुझे Git इंटर्नल्स के साथ खेलते हुए एक समाधान मिला!

  1. मान लीजिए कि आप अपने भंडार में हैं।
  2. अपनी खाली निर्देशिका बनाएँ:

    $ mkdir path/to/empty-folder
    
  3. प्लंबिंग कमांड और खाली पेड़ SHA-1 का उपयोग करके इसे सूचकांक में जोड़ें :

    $ git update-index --index-info
    040000 tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904    path/to/empty-folder
    

    कमांड टाइप करें और फिर दूसरी लाइन डालें। अपने इनपुट को समाप्त करने के लिए दबाएँ Enterऔर फिर Ctrl+ D। नोट: प्रारूप मोड है [स्पेस] टाइप [स्पेस] SHA-1hash [TAB] पथ (टैब महत्वपूर्ण है, उत्तर स्वरूपण इसे संरक्षित नहीं करता है)।

  4. बस! आपका खाली फ़ोल्डर आपके सूचकांक में है। आपको बस इतना करना है।

यह समाधान छोटा है और जाहिरा तौर पर ठीक काम करता है ( EDIT देखें)! ), लेकिन यह याद रखना इतना आसान नहीं है ...

खाली पेड़ SHA-1 को एक नया खाली Git रिपॉजिटरी बनाकर, cdउसमें और मुद्दा बनाया जा सकता है git write-tree, जो खाली पेड़ SHA-1 का उत्पादन करता है।

संपादित करें:

मैं इस समाधान का उपयोग कर रहा हूँ जब से मैंने इसे पाया। यह सबमॉड्यूल बनाने के ठीक उसी तरह काम करता प्रतीत होता है, जैसे कि कोई मॉड्यूल कहीं भी परिभाषित नहीं है। यह जारी करते समय त्रुटियों की ओर जाता है git submodule init|update। समस्या यह है कि भाग को git update-indexफिर से लिखना है040000 tree160000 commit

इसके अलावा, उस रास्ते के तहत रखी गई किसी भी फ़ाइल को कभी भी गिट द्वारा नहीं देखा जाएगा, क्योंकि यह सोचता है कि वे किसी अन्य भंडार से संबंधित हैं। यह बुरा है क्योंकि इसे आसानी से अनदेखा किया जा सकता है!

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


इंडेक्स में खाली फोल्डर डालने और कमिट करने के बाद, क्या यह git svn dcommitवांछित परिणाम के साथ संभव है ?
सीमित प्रायश्चित

2
यह संभावना नहीं है कि यह ट्वीक किसी अन्य टूल के साथ काम करेगा। जैसा कि चेतावनी और संपादन में कहा गया है, मैं इसका उपयोग करने को हतोत्साहित करता हूं जब तक कि काफी प्रतिबंधित मामले में इसका इस्तेमाल नहीं किया जाता।
इवेरे

1
और निश्चित रूप से यही कारण है कि गिट इंटर्नल के साथ खिलवाड़ को contraindicated है।
केसी

@abhisekp यह कैसे संभव है?
प्यरुलेज़

1
@PyRulez अच्छी तरह से, सॉफ्टवेयर की दुनिया में, कुछ भी असंभव नहीं है। : डी वास्तव में, मैंने जवाब का पालन किया।
१०:१६ पर abhisekp

21

मान लें कि आपको tmp नाम की खाली निर्देशिका की आवश्यकता है :

$ mkdir tmp
$ touch tmp/.gitignore
$ git add tmp
$ echo '*' > tmp/.gitignore
$ git commit -m 'Empty directory' tmp

दूसरे शब्दों में, आपको Git को इसे (और खाली निर्देशिका में सब कुछ) अनदेखा करने के लिए कहने से पहले सूचकांक में .gitignore फ़ाइल को जोड़ना होगा।


11
दो चीजें: आप केवल "इको '*' tmp / .ignignore" को छूने के बजाय, और "git कमिट-एम" कर सकते हैं, जब आपने अनुक्रमणिका में फ़ाइलों को जोड़ा है, तो "बदलाव कमिट-एम" नहीं किया गया है।
क्रिस्टोफर हम्मारस्तोम्म

6
यदि आप बस करते echo bla > fileहैं तो आपको नहीं मिलेगा file: File existsक्योंकि >यदि यह पहले से ही है तो फाइल को अधिलेखित कर देगा या यदि यह मौजूद नहीं है तो एक नया बनाएँ।
19

3
/bin/shसांस्कृतिक धारणा! * यदि "यहाँ" है cshऔर चर noclobberसेट है, तो आप वास्तव में प्राप्त करेंगे file: File exists। अगर कोई कहता है कि "मुझे यह मिल गया है", यह मत समझो कि वे एक बेवकूफ हैं और "नहीं, तुम नहीं" का जवाब देते हैं। * c2.com/cgi/wiki?AmericanCulturalAssumption
Clacke

1
@clacke यदि कोई अन्य सभी की तुलना में एक अलग शेल का उपयोग करने का निर्णय लेता है, तो उन्हें यह बताना चाहिए कि यदि वे समस्याओं का सामना कर रहे हैं तो स्पष्ट रूप से बताएं। राष्ट्रीयता के विपरीत, हर किसी के पास अपनी स्वतंत्र पसंद है।
SeldomNeedy

2
@SeldomNeedy शायद वे मदद की तलाश कर रहे हैं क्योंकि वे यह भी नहीं जानते कि वे हर किसी की तुलना में एक अलग शेल का उपयोग कर रहे हैं।
clacke

20

हो सकता है कि खाली निर्देशिका जोड़ने से ऐसा लगता है कि यह कम से कम प्रतिरोध का मार्ग होगा क्योंकि आपके पास स्क्रिप्ट हैं जो उस निर्देशिका के अस्तित्व की उम्मीद करते हैं (हो सकता है क्योंकि यह उत्पन्न बायनेरिज़ के लिए एक लक्ष्य है)। एक अन्य तरीका यह होगा कि निर्देशिका बनाने के लिए अपनी स्क्रिप्ट को संशोधित करें

mkdir --parents .generated/bin ## create a folder for storing generated binaries
mv myprogram1 myprogram2 .generated/bin ## populate the directory as needed

इस उदाहरण में, आप निर्देशिका में (टूटे हुए) प्रतीकात्मक लिंक की जांच कर सकते हैं ताकि आप इसे ".generated" उपसर्ग के बिना एक्सेस कर सकें (लेकिन यह वैकल्पिक है)।

ln -sf .generated/bin bin
git add bin

जब आप अपने स्रोत के पेड़ को साफ करना चाहते हैं तो आप कर सकते हैं:

rm -rf .generated ## this should be in a "clean" script or in a makefile

यदि आप लगभग-खाली फ़ोल्डर में चेक-इन के सुझाए गए दृष्टिकोण को लेते हैं, तो आपके पास ".ignignore" फ़ाइल को हटाने के बिना सामग्री को हटाने की मामूली जटिलता है।

आप निम्नलिखित सभी को अपनी जड़ से जोड़कर अनदेखा कर सकते हैं।

.generated

1
नोट: प्रतीकात्मक लिंक जो मैंने सुझाया था वह एक साफ चेकआउट में "टूटा हुआ" है क्योंकि .generatedनिर्देशिका शुरू में मौजूद नहीं है। एक बार जब आप अपना निर्माण करते हैं तो यह टूट नहीं जाएगा।
नोबार

2
मैं मानता हूं कि कुछ मामलों में यह एक बहुत अच्छा विचार है, लेकिन दूसरों में (जैसे कि एक प्रोजेक्ट वितरित करना जहां आपके पास फ़ोल्डर्स के साथ एक अन्यथा खाली कंकाल है जैसे कि मॉडल / और विचार /) आप चाहते हैं कि उपयोगकर्ता इन निर्देशिकाओं को हाथ में ले सकता है डॉक्स पढ़ने के लिए मैन्युअल रूप से पढ़ने की तुलना में, और रेपो को क्लोन करने के बाद उन्हें किसी प्रकार की इंस्टॉलेशन स्क्रिप्ट को चलाने की अपेक्षा करना थोड़ा अधिक हो सकता है। मुझे लगता है कि @ john-mee के README के ​​उत्तर के साथ यह उत्तर सभी मामलों को कवर करना चाहिए।
मोपेट

14

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

यही कारण है कि मैंने एक ओपन सोर्स टूल लिखने का फैसला किया, जो स्वचालित रूप से ऐसी प्लेसहोल्डर फ़ाइलों के निर्माण / विलोपन का प्रबंधन कर सकता है। यह .NET प्लेटफ़ॉर्म के लिए लिखा गया है और मोनो (लिनक्स के लिए .NET) और विंडोज के तहत चलता है।

बस इस पर एक नज़र: http://code.google.com/p/markemptydirs


14

मुझे @ Artur79 और @mjs के उत्तर पसंद हैं, इसलिए मैं दोनों के संयोजन का उपयोग कर रहा हूं और इसे हमारी परियोजनाओं के लिए एक मानक बना दिया है।

find . -type d -empty -exec touch {}/.gitkeep \;

हालांकि, मैक या लिनक्स पर हमारे मुट्ठी भर डेवलपर्स काम करते हैं। विंडोज पर बहुत सारे काम और मुझे वहाँ एक ही पूरा करने के लिए एक समान सरल एक-लाइनर नहीं मिला। कुछ लोग भाग्यशाली थे जिन्होंने Cygwin को अन्य कारणों से स्थापित किया था, लेकिन इसके लिए Cygwin को निर्धारित करना अधिक भारी लग रहा था।

बेहतर समाधान के लिए संपादित करें

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

हालांकि , मैंने बाद में सोचा कि इसे एक छोटी उपयोगिता कमांड में बनाना बेहतर होगा, इसलिए मैंने इसे पायथन का उपयोग करके पुनः बनाया और इसे यहाँ PyPI को प्रकाशित किया । आप इसे केवल चलाकर स्थापित कर सकते हैं:

pip3 install gitkeep2

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

$ gitkeep --help
Usage: gitkeep [OPTIONS] PATH

  Add a .gitkeep file to a directory in order to push them into a Git repo
  even if they're empty.

  Read more about why this is necessary at: https://git.wiki.kernel.org/inde
  x.php/Git_FAQ#Can_I_add_empty_directories.3F

Options:
  -r, --recursive     Add or remove the .gitkeep files recursively for all
                      sub-directories in the specified path.
  -l, --let-go        Remove the .gitkeep files from the specified path.
  -e, --empty         Create empty .gitkeep files. This will ignore any
                      message provided
  -m, --message TEXT  A message to be included in the .gitkeep file, ideally
                      used to explain why it's important to push the specified
                      directory to source control even if it's empty.
  -v, --verbose       Print out everything.
  --help              Show this message and exit.

मुझे उम्मीद है कि आप इसे उपयोगी पाएँ।


13

आप नहीं कर सकते और दुर्भाग्य से कभी नहीं कर पाएंगे। यह लिनुस टोरवाल्ड द्वारा स्वयं किया गया निर्णय है। वह जानता है कि हमारे लिए क्या अच्छा है।

वहाँ एक शेख़ी है जहाँ मैंने एक बार पढ़ा था।

मैंने पाया Re: खाली निर्देशिका ।। , लेकिन शायद एक और है।

आपको वर्कअराउंड के साथ रहना होगा ... दुर्भाग्य से।


1
मुझे पता है कि आपने इसे एक बुरे तर्क के उदाहरण के रूप में पोस्ट किया है, लेकिन मैं लिंक की सराहना करता हूं क्योंकि यह वास्तव में ट्रैकिंग निर्देशिकाओं के खिलाफ एक तर्कपूर्ण तर्क है। ;-)
क्लैक

1
यह उत्तर असंगत प्रतीत होता है, क्योंकि संदर्भित धागे पर अगली पोस्ट में, लिनुस टॉर्वाल्ड का कहना है कि उन्हें उम्मीद है कि उन्हें निर्देशिका ट्रैकिंग: markmail.org/message/libip4vpvvvxhybbl जोड़ने की आवश्यकता होगी । वास्तव में, वह कहता है कि वह "पैच का स्वागत करेगा कि [खाली निर्देशिकाओं को ट्रैक करने के लिए समर्थन जोड़ें]"
पैट्रिक एम

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

10

जब आप कोई .gitignoreफ़ाइल जोड़ते हैं , यदि आप उसमें किसी भी प्रकार की सामग्री डालने जा रहे हैं (जिसे आप अनदेखा करना चाहते हैं) तो आप *यह सुनिश्चित करने के लिए कि आप गलती से उपेक्षित सामग्री नहीं जोड़ते हैं, बस एक तारांकन के साथ एक पंक्ति जोड़ना चाहते हैं। ।


9

निर्देशिकाओं को ट्रैक करने के लिए Git प्राप्त करने का कोई तरीका नहीं है, इसलिए एकमात्र समाधान उस निर्देशिका के भीतर प्लेसहोल्डर फ़ाइल जोड़ना है जिसे आप ट्रैक करना चाहते हैं।

फ़ाइल को नाम दिया जा सकता है और उसमें कुछ भी हो सकता है, जिसे आप चाहते हैं, लेकिन ज्यादातर लोग नाम वाली खाली फ़ाइल का उपयोग करते हैं .gitkeep करते हैं (हालांकि कुछ लोग VCS-agnostic को पसंद करते हैं.keep )।

उपसर्ग .ने इसे एक छिपी हुई फ़ाइल के रूप में चिह्नित किया है।

एक और विचार यह है READMEकि निर्देशिका के लिए क्या उपयोग किया जाएगा यह बताते हुए एक फ़ाइल जोड़ना होगा।


8

जैसा कि उल्लेख किया गया है कि खाली निर्देशिकाओं को जोड़ना संभव नहीं है, लेकिन यहां एक लाइनर है जो सभी निर्देशिकाओं के लिए खाली .gitignore फ़ाइलों को जोड़ता है।

ruby -e 'require "fileutils" ; Dir.glob(["target_directory","target_directory/**"]).each { |f| FileUtils.touch(File.join(f, ".gitignore")) if File.directory?(f) }'

मैंने इसे आसान पहुँच के लिए Rakefile में अटका दिया है।


6
मैं बल्कि इस्तेमाल करूँगाfind . -type d -empty -print0 | xargs --null bash -c 'for a; do { echo "*"; echo "!.gitignore"; } >>"$a/.gitignore"; done' --
Tino

8

जेमी फ्लॉर्नॉय का समाधान महान काम करता है। यहाँ रखने के लिए थोड़ा बढ़ाया संस्करण है .htaccess:

# Ignore everything in this directory
*
# Except this file
!.gitignore
!.htaccess

इस समाधान के साथ आप एक खाली फ़ोल्डर बनाने में सक्षम हैं, उदाहरण के लिए /log, /tmpया /cacheफ़ोल्डर खाली रहेगा।


2
वह खाली निर्देशिका रखना चाहता है न कि कोई फाइल।
gvsrepins

2
और मैंने उल्लेख किया है कि यह .htaccess भी रखेगा। उदाहरण: यदि किसी सॉफ्टवेयर में लॉग-फाइल (जैसे ऑक्सीडेंट नाइयों) के लिए एक निर्देशिका है, जिसे वेब के माध्यम से पहुंच योग्य नहीं होना चाहिए, तो निर्देशिका में एक .htaccess है। यदि आप उपर्युक्त .gitignore को फ़ोल्डर में रखते हैं, तो .htaccess को कॉमिफ़ाइ नहीं किया जाएगा और फ़ोल्डर वेब के माध्यम से पहुँचा जा सकेगा।
रोमन

यदि आपके पास एक .htaccess फ़ाइल है जो संस्करण नियंत्रण में है, तो आपके पास पहले से ही निर्देशिका है जो संस्करण नियंत्रण में है। इस प्रकार, समस्या पहले से ही हल हो गई है। .ignignore फ़ाइल अप्रासंगिक हो जाती है।
पोंकाडूडल

1
@Wallacoloo संबंधित प्रश्न के लिए आप सही हैं, फिर भी फ़ाइल उपयोगी है, मैं इसे एक अपलोड-निर्देशिका के लिए उपयोग करूँगा, जहाँ फ़ाइलों को .htaccess द्वारा संरक्षित किया जाएगा। रोमन स्पष्टीकरण के विपरीत .htaccess- फ़ाइल को अनदेखा किया जाएगा क्योंकि इसे अनदेखा-नियम द्वारा बाहर रखा गया है। [पुराना सूत्र, मुझे पता है]
डेविड

7

मैं हमेशा अपने वांछित फ़ोल्डर संरचना की जांच करने के लिए एक फ़ंक्शन का निर्माण करता हूं और परियोजना के भीतर मेरे लिए इसका निर्माण करता हूं। यह इस समस्या के आसपास हो जाता है क्योंकि प्रॉक्सी द्वारा खाली फ़ोल्डर्स Git में रखे जाते हैं।

function check_page_custom_folder_structure () {
    if (!is_dir(TEMPLATEPATH."/page-customs"))
        mkdir(TEMPLATEPATH."/page-customs");    
    if (!is_dir(TEMPLATEPATH."/page-customs/css"))
        mkdir(TEMPLATEPATH."/page-customs/css");
    if (!is_dir(TEMPLATEPATH."/page-customs/js"))
        mkdir(TEMPLATEPATH."/page-customs/js");
}

यह PHP में है, लेकिन मुझे यकीन है कि अधिकांश भाषाएं समान कार्यक्षमता का समर्थन करती हैं, और क्योंकि फ़ोल्डरों के निर्माण में अनुप्रयोग द्वारा ध्यान रखा जाता है, इसलिए फ़ोल्डर हमेशा रहेंगे।


2
बस हम सभी एक ही पृष्ठ पर हैं, मैं अब ऐसा नहीं करता। यह समय की बर्बादी है। .gitkeepसम्मेलन में एक बेहतर अभ्यास है।
हल्दी फज

मैं यह नहीं देख सकता कि यह समय की बर्बादी कैसे हो सकती है। जब आपका TEMPLATEPATH स्पष्ट रूप से गतिशील है तो आप .गिति समाधान का उपयोग नहीं कर सकते। और यहां तक ​​कि एक nondynamic फ़ोल्डर संरचना के साथ आपको चेकिंग निर्देशिकाओं के बहुत अच्छे समाधान को हटाने के बजाय कुछ और सामान जोड़ना चाहिए जैसे कि अनुमतियों के लिए जाँच करें और फ़ाइलों को चोद दें। एक वैश्विक .gitignore के अंदर निर्देशिकाओं को चिह्नित करने का एक तरीका जोड़ना मेरे लिए एकदम सही होगा। #Keep / पथ की तरह कुछ / to / dir
जोचेन शुल्ज़

7

यहाँ एक हैक है, लेकिन यह मज़ेदार है कि यह काम करता है (Git 2.2.1)। @Teka ने जो सुझाव दिया, उसके समान, लेकिन याद रखना आसान है:

  • किसी भी रिपॉजिटरी में एक सबमॉड्यूल जोड़ें ( git submodule add path_to_repo)
  • यह एक फ़ोल्डर और एक फ़ाइल जोड़ देगा .submodules। एक बदलाव करें।
  • .submodulesफ़ाइल हटाएं और परिवर्तन करें।

अब, आपके पास एक निर्देशिका है जो प्रतिबद्ध होने पर बनाई गई है। हालांकि एक दिलचस्प बात यह है कि यदि आप इस फ़ाइल की ट्री ऑब्जेक्ट की सामग्री को देखेंगे तो आपको मिलेगा:

घातक: मान्य वस्तु का नाम b64338b90b4209263b50244d18278c0999867193

मैं इसे उपयोग करने के लिए प्रोत्साहित नहीं करूंगा, क्योंकि यह भविष्य के Git संस्करणों में काम करना बंद कर सकता है। जो आपके भंडार को दूषित कर सकता है।


यह वास्तव में काम करता है, लेकिन मुझे लगता है कि इंटेलीज से बिल्ली को भ्रमित करता है ...: |
रोजरपैक

मैंने इसके आधार पर एक बेहतर समाधान बनाया है जिसमें ये कमियां नहीं हैं: stackoverflow.com/a/58543445/277882
ntninja

7

कई लोग इस सवाल का जवाब पहले ही दे चुके हैं। बस यहाँ एक PowerShell संस्करण जोड़ना।

निर्देशिका में सभी खाली फ़ोल्डर खोजें

वहां एक खाली .गितक फ़ाइल जोड़ें

Get-ChildItem 'Path to your Folder' -Recurse -Directory | Where-Object {[System.IO.Directory]::GetFileSystemEntries($_.FullName).Count -eq 0} | ForEach-Object { New-Item ($_.FullName + "\.gitkeep") -ItemType file}

नाइस। ͡☉ ͡☉ ͜ʖ ‌ F
फेयरिंगस्क्वैडिटवेयर

6

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

/app/data/**/*.* !/app/data/**/*.md

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

आप इन सभी निर्देशिकाओं को xml / images files या जो कुछ भी भर सकते हैं और /app/data/समय के साथ और अधिक निर्देशिकाएं जोड़ सकते हैं, क्योंकि आपके ऐप के विकास के लिए स्टोरेज की जरूरत है (README.md फाइलों के साथ जो कि प्रत्येक स्टोरेज डायरेक्टरी के विवरण के लिए है। बिल्कुल सही)।

प्रत्येक नई निर्देशिका के लिए .gitignoreएक नया बनाकर अपने या विकेंद्रीकरण को और अधिक बदलने की आवश्यकता नहीं है .gitignore। संभवत: सबसे चतुर समाधान नहीं है, लेकिन यह मेरे लिए सबसे अच्छा काम है। अच्छा और सरल! ;)

यहां छवि विवरण दर्ज करें


6

ऐसा करने का एक आसान तरीका .gitkeepउस निर्देशिका में एक फ़ाइल जोड़कर है जिसे आप (वर्तमान में) खाली रखना चाहते हैं।

आगे की जानकारी के लिए इस SOF उत्तर को देखें - जो यह भी बताता है कि क्यों कुछ लोग .gitignore फ़ाइल (जैसा कि यहां कई उत्तरों में कहा गया है) को भ्रमित करने के लिए प्रतिस्पर्धात्मक सम्मेलन को जोड़ते हैं।


4

मैदान में एक और विकल्प जोड़ना।

यह मानते हुए कि आप इसके लिए एक निर्देशिका जोड़ना चाहते हैं git, से संबंधित सभी उद्देश्यों के लिए git, खाली रहना चाहिए और कभी भी इसकी सामग्री ट्रैक नहीं की जानी चाहिए, .gitignoreजैसा कि यहां कई बार सुझाया गया है, यह चाल चलेगा।

प्रारूप, जैसा कि बताया गया है:

*
!.gitignore

अब, यदि आप कमांड लाइन पर ऐसा करने का तरीका चाहते हैं, तो एक में झपकी आ गई, जबकि निर्देशिका के अंदर जिसे आप जोड़ना चाहते हैं, आप निष्पादित कर सकते हैं:

$ echo "*" > .gitignore && echo '!.gitignore' >> .gitignore && git add .gitignore

मेरे पास, मेरे पास एक शेल स्क्रिप्ट है जो मैं ऐसा करने के लिए उपयोग करता हूं। स्क्रिप्ट का नाम जो भी आप लिखते हैं, और या तो इसे अपने शामिल पथ में कहीं जोड़ दें, या इसे सीधे संदर्भ दें:

#!/bin/bash

dir=''

if [ "$1" != "" ]; then
    dir="$1/"
fi

echo "*" > $dir.gitignore && \
echo '!.gitignore' >> $dir.gitignore && \
git add $dir.gitignore

इसके साथ, आप इसे उस निर्देशिका के भीतर से निष्पादित कर सकते हैं जिसे आप जोड़ना चाहते हैं, या निर्देशिका का संदर्भ दें क्योंकि यह पहला और एकमात्र पैरामीटर है:

$ ignore_dir ./some/directory

एक अन्य विकल्प (@GreenAsJade द्वारा एक टिप्पणी के जवाब में), यदि आप किसी रिक्त फ़ोल्डर कि ट्रैक करना चाहते मई भविष्य में पता लगाया फ़ाइलें हो, लेकिन अब के लिए खाली हो जाएगा, तो आप कर सकते हैं ommit *से .gitignoreफ़ाइल, और जाँच कि में। मूल रूप से, सभी फ़ाइल कह रही है " मुझे अनदेखा न करें ", लेकिन अन्यथा, निर्देशिका खाली और ट्रैक की गई है।

आपकी .gitignoreफ़ाइल इस तरह दिखाई देगी:

!.gitignore

यही है, जाँच करें कि और आपके पास एक खाली, अभी तक ट्रैक की गई निर्देशिका है, जिसे आप बाद के समय में फ़ाइलों को ट्रैक कर सकते हैं।

कारण है कि मैं फ़ाइल में एक पंक्ति रखने का सुझाव देता हूं कि यह .gitignoreउद्देश्य देता है । अन्यथा, कुछ नीचे की रेखा इसे हटाने के लिए सोच सकती है। यदि आप पंक्ति के ऊपर टिप्पणी रखते हैं तो यह मदद कर सकता है।


4

कभी-कभी आपको खराब लिखित पुस्तकालयों या सॉफ़्टवेयर से निपटना पड़ता है, जिन्हें "वास्तविक" खाली और मौजूदा निर्देशिका की आवश्यकता होती है। एक साधारण डालने .gitignoreया .keepउन्हें तोड़ने और एक बग का कारण हो सकता है। निम्नलिखित इन मामलों में मदद कर सकते हैं, लेकिन कोई गारंटी नहीं ...

पहले आवश्यक निर्देशिका बनाएं:

mkdir empty

फिर आप इस निर्देशिका के लिए एक टूटे हुए प्रतीकात्मक लिंक को जोड़ते हैं (लेकिन ऊपर वर्णित उपयोग के मामले के अलावा किसी अन्य मामले पर, कृपया READMEस्पष्टीकरण के साथ उपयोग करें ):

ln -s .this.directory empty/.keep

इस निर्देशिका में फ़ाइलों को अनदेखा करने के लिए, आप इसे अपनी जड़ में जोड़ सकते हैं .gitignore:

echo "/empty" >> .gitignore

उपेक्षित फ़ाइल को जोड़ने के लिए, इसे बाध्य करने के लिए एक पैरामीटर का उपयोग करें:

git add -f empty/.keep

प्रतिबद्ध के बाद आपके पास अपने सूचकांक में एक टूटी हुई प्रतीकात्मक कड़ी है और गिट निर्देशिका बनाता है। टूटी हुई लिंक के कुछ फायदे हैं, क्योंकि यह कोई नियमित फ़ाइल नहीं है और न ही नियमित फ़ाइल की ओर इशारा करती है। तो यह प्रश्न के भाग के लिए भी फिट बैठता है "(जिसमें कोई फ़ाइल नहीं है)", इरादे से नहीं बल्कि अर्थ से, मुझे लगता है:

find empty -type f

यह आदेश एक खाली परिणाम दिखाता है, क्योंकि इस निर्देशिका में कोई फाइल मौजूद नहीं है। इसलिए अधिकांश एप्लिकेशन, जो एक निर्देशिका में सभी फाइलें प्राप्त करते हैं, आमतौर पर इस लिंक को नहीं देखते हैं, कम से कम अगर वे "फाइल मौजूद है" या "पठनीय है"। यहां तक ​​कि कुछ स्क्रिप्ट को वहां कोई भी फाइल नहीं मिलेगी:

$ php -r "var_export(glob('empty/.*'));"
array (
  0 => 'empty/.',
  1 => 'empty/..',
)

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


4

पढ़ना @ofavre की और @ स्टानिस्लाव-bashkyrtsev टूट GIT submodule संदर्भों का उपयोग GIT निर्देशिका बनाने के लिए के जवाब, मैं हैरान हूँ कि कोई भी विचार की अभी तक इस सरल संशोधन का सुझाव दिया है पूरी बात समझदार और सुरक्षित बनाने के लिए:

GIT में एक नकली सबमॉडल हैक करने के बजाय , बस एक खाली वास्तविक जोड़ें

दर्ज: https://gitlab.com/empty-repo/empty.git

ठीक एक कमिट के साथ एक जीआईटी भंडार:

commit e84d7b81f0033399e325b8037ed2b801a5c994e0
Author: Nobody <none>
Date: Thu Jan 1 00:00:00 1970 +0000

कोई संदेश नहीं, कोई प्रतिबद्ध फ़ाइल नहीं।

प्रयोग

आपके लिए एक खाली निर्देशिका जोड़ने के लिए GIT रेपो:

git submodule add https://gitlab.com/empty-repo/empty.git path/to/dir

सभी मौजूदा खाली निर्देशिकाओं को सबमॉड्यूल में बदलने के लिए:

find . -type d -empty -delete -exec git submodule add -f https://gitlab.com/empty-repo/empty.git \{\} \;

सबमॉडल संदर्भ बनाते समय Git नवीनतम कमिट हैश को स्टोर करेगा, इसलिए आपको दुर्भावनापूर्ण फ़ाइलों को इंजेक्ट करने के लिए इसका उपयोग करने के लिए मुझे (या GitLab) के बारे में चिंता करने की आवश्यकता नहीं है। दुर्भाग्य से मुझे चेकआउट के दौरान किस कमिट आईडी का उपयोग करने के लिए बाध्य करने का कोई तरीका नहीं मिला है, इसलिए आपको मैन्युअल रूप से जांचना होगा कि रेफ़र जोड़ने के बाद संदर्भ कमिट आईडी e84d7b81f0033399e325b8037ed2b801a5c994e0उपयोग कर रही है या नहीं git submodule status

फिर भी नहीं एक देशी समाधान है, लेकिन सबसे अच्छा हम शायद हो सकता है किसी को अपने अपने हाथ हो रही बिना वास्तव में , वास्तव में GIT codebase में गंदा।

परिशिष्ट: इस प्रतिबद्ध को फिर से बनाना

आपको (सटीक निर्देशिका में) का उपयोग करके इस सटीक प्रतिबद्ध को फिर से बनाने में सक्षम होना चाहिए:

# Initialize new GIT repository
git init

# Set author data (don't set it as part of the `git commit` command or your default data will be stored as “commit author”)
git config --local user.name "Nobody"
git config --local user.email "none"

# Set both the commit and the author date to the start of the Unix epoch (this cannot be done using `git commit` directly)
export GIT_AUTHOR_DATE="Thu Jan 1 00:00:00 1970 +0000"
export GIT_COMMITTER_DATE="Thu Jan 1 00:00:00 1970 +0000"

# Add root commit
git commit --allow-empty --allow-empty-message --no-edit

प्रतिलिपि प्रस्तुत करने योग्य GIT बनाना आश्चर्यजनक रूप से कठिन है ...


3

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


60
मैं इस दृष्टिकोण से चुनाव लड़ता हूं। संरचना सामग्री है, और आप जो कुछ भी नाम देते हैं वह सामग्री में योगदान देता है।
थॉमस एचएच

20
एक खाली फ़ाइल स्रोत कोड या सामग्री नहीं है। यह सिर्फ एक नाम है। फिर भी गिट खुशी से खाली फाइलों को ट्रैक करेगा। मुझे नहीं लगता कि खाली निर्देशिकाओं को ट्रैक करने से इंकार करने के लिए यह जानबूझकर किया गया निर्णय था। मुझे लगता है कि खाली निर्देशिकाओं को ट्रैक करना एक ऐसी सुविधा है, जिसमें केवल 99% समय की आवश्यकता नहीं होती है, इसलिए वे इस काम को ठीक से करने के लिए आवश्यक अतिरिक्त काम करने की जहमत नहीं उठाते हैं। यदि कोई व्यक्ति इसे लागू करने के लिए सुविधा को बुरी तरह से चाहता है, तो गिट इसे कर सकता है। मुझे संदेह है कि गिट अनुचर ऐसे पैच का विरोध करेंगे यदि यह सही ढंग से किया गया था।
दान मोल्डिंग

1
यहाँ @TobyAllen अपडेटेड FAQ लिंक है । शीर्ष उत्तर भी वही है जो FAQ द्वारा अधिक सटीक निर्देशों के साथ सुझाया गया है।
डेनियल दा कुन्हा

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

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

2

आप इस कोड को create_readme.php के रूप में सहेज सकते हैं और अपने Git प्रोजेक्ट के रूट डायरेक्टरी से PHP कोड चला सकते हैं।

> php create_readme.php

यह उन सभी निर्देशिकाओं में README फाइलें जोड़ देगा जो खाली हैं इसलिए उन निर्देशिकाओं को फिर सूचकांक में जोड़ा जाएगा।

<?php
    $path = realpath('.');
    $objects = new RecursiveIteratorIterator(new RecursiveDirectoryIterator($path),       RecursiveIteratorIterator::SELF_FIRST);
    foreach($objects as $name => $object){
        if ( is_dir($name) && ! is_empty_folder($name) ){
            echo "$name\n" ;
            exec("touch ".$name."/"."README");
        }
    }

    function is_empty_folder($folder) {
        $files = opendir($folder);
        while ($file = readdir($files)) {
            if ($file != '.' && $file != '..')
                return true; // Not empty
            }
        }
?>

फिर करो

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