क्या दस्तावेज और परियोजना प्रबंधन के लिए Git का उपयोग किया जाना चाहिए? क्या कोड एक अलग रिपॉजिटरी में होना चाहिए?

68

मैं एक ग्रुप प्रोजेक्ट के लिए Git रिपॉजिटरी शुरू कर रहा हूं। क्या यह कोड के रूप में समान गिट रिपॉजिटरी में दस्तावेजों को संग्रहीत करने के लिए समझ में आता है - ऐसा लगता है कि यह गिट संशोधन संशोधन की प्रकृति के साथ टकराव है।

यहाँ मेरे प्रश्न का एक सारांश है:

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

अब तक की प्रतिक्रिया के लिए धन्यवाद!

git version-control project-management

— EmpireJones
स्रोत

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

— टिमटिमा

1

मैं यह नहीं देखता कि यह विषय पर कैसा है। आप सॉफ्टवेयर प्रलेखन और DVCS

— टिम पोस्ट

शायद प्रलेखन और आपकी आवश्यकताओं पर निर्भर करता है। क्या आपको अंतर की आवश्यकता है और क्या यह एक प्रारूप में है जो इसे संभाल सकता है? यदि git आवश्यक सेवाओं को सुनिश्चित करता है। एक अलग दस्तावेज प्रबंधन प्रणाली वाले बीट्स ...

— रिग

यदि आपका प्रलेखन सादे पाठ में है - ठीक है। यदि यह एक द्विआधारी प्रारूप है, तो आपको अनिवार्य रूप से एक संस्करण नियंत्रण प्रणाली की आवश्यकता होती है जो द्विआधारी प्रारूप को समझती है - यह अपने शुद्ध रूप में विक्रेता लॉक-इन है।

संबंधित: सोर्स कोड कंट्रोल में आपके प्रोजेक्ट का क्या हिस्सा होना चाहिए?

— gnat

53

हम एसवीएन में हर समय प्रलेखन संग्रहीत करते हैं। वास्तव में, हमारा पूरा उपयोगकर्ता मैनुअल LaTeX में लिखा गया है, और एसवीएन में संग्रहीत है। हमने LaTeX को विशेष रूप से चुना क्योंकि यह एक पाठ-आधारित भाषा है, और लाइन-बाय-लाइन को अलग दिखाने में आसान है।

जब आवश्यक हो तो हम कुछ गैर-पाठ स्वरूपित फ़ाइलों को भी संग्रहीत करते हैं, जैसे कि Microsoft Office .doc फ़ाइलें, स्प्रेड शीट, .zip फ़ाइलें, आदि ... लेकिन जब आप वृद्धिशील नहीं देख सकते हैं, तो RCS के लाभ में से कुछ खो जाता है। डिफ।

कुंजी वास्तव में यह सुनिश्चित करने के लिए है कि आपका प्रलेखन अच्छी तरह से व्यवस्थित है, ताकि लोग आवश्यकता पड़ने पर प्रलेखन (और स्रोत) को ढूंढ सकें (और अपडेट कर सकें)।

— Flimzy
स्रोत

11

यदि आप एक Microsoft दुकान हैं, तो TortoiseSVN MS Office लाइन-बाय-लाइन भिन्न का समर्थन करता है।

— फिल

2

द्विआधारी डॉक्टर प्रारूप को छोड़ने से दुनिया बेहतर जगह बन जाएगी। o यह देखते हुए कि डॉक्स सादे-पाठ हैं, DVCS के साथ कोई वास्तविक समस्या नहीं होनी चाहिए।

— काई इनकिनन

ओह, और पहली बार मैंने TortoiseSVN और doc फ़ाइलों के बारे में सुना, तो उसके लिए +1। आश्चर्य है कि भविष्य में कभी भी कछुआ [AnyDVCS] पर समाप्त हो जाएगा।

— काई इनकिनन

@Phil: TortoiseSVN इसे कैसे पूरा करता है? क्या doc-diff दर्शक SVN क्लाइंट के साथ एकीकृत है, या इसे स्वतंत्र रूप से उपयोग किया जा सकता है?

— फ्लिमज़ी

1

एक अच्छा विकल्प पंडोक का उपयोग करना होगा ताकि आपके अधिकांश दस्तावेज मार्कडाउन में हों, लेकिन महत्वपूर्ण बिट्स अभी भी TeX का उपयोग कर सकते हैं। चूंकि यह मार्कडाउन को LaTeX में संकलित करता है, इसलिए परिणाम समान दिखते हैं। हालाँकि, यह आपको विभिन्न स्वरूपों में निर्यात करने देगा और स्रोत को पढ़ना आसान बना देगा।

— तिखन जेल्विस

22

वैसे यह इस बात पर निर्भर करता है कि आप प्रलेखन के लिए किस प्रारूप का उपयोग करते हैं। अगर यह कुछ पाठ आधारित है तो यह सब अच्छा है।

Git बाइनरी कंटेंट को भी स्टोर कर सकता है और आप रिविजन को ट्रैक कर सकते हैं, लेकिन अलग आउटपुट से कोई मतलब नहीं होगा।

यह भी कोड को perldoc फली की तरह ही स्टोर करना संभव है, जावा के पास इसके लिए कुछ प्रारूप / एनोटेशन भी है।

— cstamas
स्रोत

मैं सहमत हूं, जबकि गैर-पाठ प्रलेखन को संग्रहीत करना संभव है, अगर आप पाठ को संग्रहीत करते हैं तो git बहुत बेहतर करेगा। वहाँ एक अलग ड्राइवर की बात की गई है जो जानता है कि शब्द (या समान) के दस्तावेज़ों को कैसे अलग किया जाए, लेकिन मुझे यकीन नहीं है कि इसे लागू किया गया था या नहीं

— Sverre Rabbelier

हालाँकि, Word ने उनके प्रारूप को बाइनरी से XML में स्थानांतरित कर दिया था।

— cledoux

3

@ karategeek6 वर्ड का 'XML' प्रारूप मानव पठनीय नहीं है। और पाठ की एक पंक्ति Word के XML की एक पंक्ति के अनुरूप नहीं है, यहां तक कि सन्निकटन में भी। तो यह बाइनरी भी हो सकता है।

आप अपने निर्देश को असम्पीडित XML में सहेजने के लिए Word को निर्देश दे सकते हैं। चुनें Save As, फिर Word XML Document (*.xml)डिफ़ॉल्ट के बजाय चुनें Word Document (*.docx)। एक्सएमएल काफी जटिल है, इसलिए यह कोई गारंटी नहीं है कि परिवर्तन आसानी से पढ़ने योग्य होगा, लेकिन कम से कम यह द्विआधारी नहीं होगा।

— Kyralessa

> लेकिन अलग आउटपुट का कोई मतलब नहीं होगा। अंतर के कारण, हम एक दस्तावेज़ के 2 पुनरीक्षण को कंधे से कंधा मिलाकर खोल सकते हैं और अपनी आँखों से तुलना कर सकते हैं :)

— ल्यूक

14

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

6

केवल अगर प्रलेखन एक पाठ रूप में है। बाइनरी ब्लब्स संस्करण नियंत्रण से पूरी तरह से लाभान्वित नहीं होते हैं।

2

@ ThorbjørnRavnAndersen: यहां तक कि, जब तक कि आपके पास एक बाइनरी-विशिष्ट संस्करण प्रणाली नहीं है, तो संभवतः अपने बजाए Git में भी बाइनरी फ़ाइलों को रखना बेहतर है।

— तिकोन जेल्विस

@TikhonJelvis मैंने यह सवाल नहीं किया कि क्या द्विआधारी फ़ाइलों को गिट में डालना एक अच्छा विचार है - यदि वे मूल कलाकृतियों हैं, तो यह है। हालाँकि, Word दस्तावेज़ों पर "git diff" चलाने के लिए प्रयास करें।

@ user1249: आप डेस्कटॉप पर 2 "संशोधन" निर्यात कर सकते हैं, my_docs_rev15.docx और my_docs_rev14.docx कहें, फिर इसे कंधे से कंधा मिलाकर खोलें और अपनी आंखों और मस्तिष्क से तुलना करें, यह मुश्किल नहीं है :)

— ल्यूक

14

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

— Ma99uS
स्रोत

3

हां, "वही स्थान" पहलू इस प्रश्न के प्रमुख भागों में से एक है!

यदि आप इसे प्रबंधित कर सकते हैं तो समान स्थान अच्छा है, क्योंकि यह या तो आदिवासी ज्ञान (जहां देखने के लिए जाना जाता है), या जहां सामान है, वहां जाने की आवश्यकता को जानने से बचता है।

— जल्‍दी से जल्‍दी_जुन 22’11

उन्हें कोड तक पहुंच की आवश्यकता नहीं हो सकती है, लेकिन उनके लिए उस पहुंच के लिए चोट नहीं पहुंचनी चाहिए। वे इसे देखने के लिए नहीं है। रहस्य आम तौर पर वैसे भी संस्करण नियंत्रण में नहीं होना चाहिए।

— bdsl

9

जिस कंपनी में मैं काम करता हूं उस कंपनी में हम एसवीएन में प्रलेखन करते हैं। हालाँकि, कुछ संघर्षों और इसे साझा करने की आवश्यकता के बाद, हमने इसे Mediawiki में स्थानांतरित करने का निर्णय लिया।

सबसे पहले यह trac था, उसके बाद Mediawiki ले जाया गया क्योंकि यह उपयोग करने के लिए आसान था ...

एसवीएन के साथ मुख्य समस्या साझाकरण का कारण था, हमारे पास एसवीएन के लिए प्राधिकरण प्रणाली थी।

— confiq
स्रोत

2

क्या आपका मतलब मीडियाविकि नहीं है, विकिपीडिया जिस विकी इंजन का उपयोग करता है?

— @ मर्टिजेन

— @ मर्टिज़न

मैं बहुत सी फाइलें भेजने के बजाय एक विकी के साथ रहना चाहूंगा जो एक एससीएम के लिए पाठ्यक्रम नहीं हैं, लेकिन व्यक्तिगत प्राथमिकता के साथ ऐसा करने के लिए अधिक है। बहुत कुछ है जो आप इसके साथ कर सकते हैं। मुझे विशेष रूप से फोसवीकी और उनकी वेबसाइट आधारित / परियोजना आधारित टेम्पलेट पसंद हैं। खुशी है कि किसी ने समस्याओं के कारण विकि का उपयोग करने का निर्णय लिया :) १।

— ओउफ़्कोके पेंटेनो

9

रिपॉजिटरी में सिर्फ सोर्स कोड से ज्यादा होना बहुत अच्छी बात है।

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

आप चीजों को व्यवस्थित रखना चाहते हैं। srcसे से अलग करने के लिए एक प्रणाली imagesहै docs। .gitignoreरिपॉजिटरी और इतिहास को साफ रखने के लिए आप हमेशा एक निर्देशिका में जोड़ सकते हैं । चूँकि Git commits फ़ाइल-आधारित हैं, * आप दस्तावेज़ परिवर्तनों से स्रोत परिवर्तन को जोरदार तरीके से हटा सकते हैं जैसे आप चाहते हैं।
जैसा कि अन्य लोगों ने कहा है, जब तक यह पाठ-आधारित है, तब तक प्रलेखन संस्करण के लिए Git महान है।
मैं पूरी तरह से सहमत; कोड के साथ प्रलेखन का सही संस्करण होना चाहिए।

मेरी विश्वसनीयता एक GitHub उपयोगकर्ता होने और एक परियोजना में योगदान देने और कई अन्य लोगों की खोज करने से आती है। मेरे अनुभव में, एक पूर्ण, एकीकृत परियोजना एक आधे-लापता से बताना आसान है। मैं जब भी संभव हो, अपनी सभी परियोजनाओं को एकल निर्देशिकाओं में समाहित करने की कोशिश करता हूं।

* यह बहुत सटीक नहीं है, क्योंकि फ़ाइल के कुछ हिस्सों को निर्दिष्ट करने के तरीके हैं ( यहां एक उदाहरण )।

— टायलर वेन
स्रोत

4

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

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

— इल्के ब्लोक
स्रोत

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

— tbc0

पैकेजों को वितरित करते समय, मैं आंशिक रूप से .deb शैली का हिस्सा हूं जो मुझे सभी सर्वरों के लिए निष्पादनयोग्य डाउनलोड करने की अनुमति देता है, जबकि मेरे विकास बॉक्स में प्रलेखन पैकेज भी हैं।

— tbc0

1

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

— माइकल ब्राउन
स्रोत

-1

कोड में, विचारों को आम तौर पर लाइन-बाय-लाइन अलग किया जाता है। मैं सॉफ्ट लाइन रैप्स के साथ डॉक्यूमेंट लिखना चाहता हूं। जब मैं उन फ़ाइलों को प्रतिबद्ध करता हूं, तो लाइनें पूरी तरह से लंबी होती हैं। में पढ़ने के लिए यह बहुत उपयोगी नहीं है git diff। वह समस्या जिसे मैं हल करने की कोशिश कर रहा था जब मैंने Googled और यह पृष्ठ पाया। मुझे शुरू करने के लिए Arne Hartherz को धन्यवाद git diff --word-diff। आपको और git diff --color-wordsभी अच्छा लग सकता है।

— tbc0
स्रोत