ओपन सोर्स हार्डवेयर के लिए संस्करण नियंत्रण: 10 कदम

2024 लेखक: John Day | [email protected]. अंतिम बार संशोधित: 2024-01-30 09:22

ब्रेनबो की टीम के पास हमारे बेल्ट के तहत कई इलेक्ट्रॉनिक्स प्रोजेक्ट हैं, और हम अपने इलेक्ट्रॉनिक्स डिज़ाइन वर्कफ़्लो को प्रबंधित करने के लिए संस्करण नियंत्रण का उपयोग करने के लिए अपनी प्रक्रिया को साझा करना चाहते थे। इस वर्कफ़्लो का उपयोग बड़े और छोटे प्रोजेक्ट्स के लिए किया गया है, साधारण 2 लेयर बोर्ड से लेकर कॉम्प्लेक्स 10 लेयर बीहमोथ तक, और यह ओपन-सोर्स टूल्स पर आधारित है। उम्मीद है, अन्य लोग हमारे वर्कफ़्लो को अपने लिए अपना सकते हैं, और अपने स्वयं के प्रोजेक्ट के लिए संस्करण नियंत्रण के लाभ प्राप्त कर सकते हैं। लेकिन संस्करण नियंत्रण एक इलेक्ट्रॉनिक्स परियोजना को क्या लाभ प्रदान कर सकता है?

चरण 1: क्यों संस्करण आपके इलेक्ट्रॉनिक्स को नियंत्रित करता है?

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

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

चरण 2: उपकरण: KiCad और Git

हम इस परियोजना में दो मुख्य उपकरणों का उपयोग करते हैं: संस्करण नियंत्रण प्रणाली (वीसीएस) और इलेक्ट्रॉनिक्स डिजाइन स्वचालन कार्यक्रम (ईडीए या ईसीएडी)।

वहाँ कई संस्करण नियंत्रण प्रणालियाँ हैं, लेकिन हम वितरित VCS Git का उपयोग करते हैं। हम इसे कई कारणों से उपयोग करते हैं, लेकिन मुख्य बात यह है कि यह ओपन-सोर्स (चेक!), उपयोग में आसान (चेक!), और ओपन-सोर्स सॉफ़्टवेयर के लिए वास्तविक मानक वीसीएस (चेक!) है। हम अपने ECAD प्रोग्राम द्वारा उपयोग की जाने वाली फ़ाइलों में परिवर्तनों को ट्रैक करने के लिए Git का उपयोग VCS के रूप में करेंगे। इस निर्देशयोग्य को Git से परिचित होने की आवश्यकता नहीं है, लेकिन कमांड लाइन का उपयोग करके सामान्य आराम माना जाता है। मैं आवश्यकतानुसार गिट और कमांड लाइन उपयोग दोनों के लिए सहायक संसाधनों से लिंक करने का प्रयास करूंगा।

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

चरण 3: स्थापना

इन प्रोग्रामों को स्थापित करने के लिए, नीचे लिंक की गई उनकी विभिन्न डाउनलोड साइटों के निर्देशों का पालन करें।

• KiCad क्रॉस-प्लेटफ़ॉर्म है (और बहुत ही रोमांचक है; उनके डाउनलोड पृष्ठ में 13 समर्थित OS सूचीबद्ध हैं, और यदि उनमें से कोई भी आपको सूट नहीं करता है तो एक स्रोत कोड डाउनलोड प्रदान करता है)। किकाड-एकीकृत डिफ़ॉल्ट इंस्टॉल का उपयोग करें, न कि रात्रिकालीन विकास बिल्ड का। पुस्तकालय स्थापना पर उन्नत वैकल्पिक विवरण के लिए चरण 4 देखें।
• गिट भी क्रॉस-प्लेटफॉर्म है। यदि विंडोज का उपयोग कर रहे हैं, तो मैं अधिक उपयोगी, पूरी तरह से चित्रित अनुभव के लिए विंडोज प्रोजेक्ट के लिए प्रभावशाली गिट की सिफारिश करूंगा।

इन दोनों साइटों पर उपलब्ध संस्थापन दस्तावेज मेरे द्वारा यहां दिए जा सकने वाले किसी भी विवरण की तुलना में अधिक पूर्ण होंगे। एक बार दोनों प्रोग्राम डाउनलोड और इंस्टॉल हो जाने के बाद, आप हमारे जीथब रिपॉजिटरी से ब्रेनबो के प्रोजेक्ट टेम्प्लेट को क्लोन कर सकते हैं। गिट क्लोन कमांड संरचना लेता है `गिट क्लोन {src निर्देशिका} {लक्ष्य निर्देशिका}`; हमारे प्रोजेक्ट के लिए, `गिट क्लोन https://github.com/builtbybrainbow/kicad-starter.git {target directory}` का उपयोग करें।

एक गिट रेपो क्लोनिंग प्रतिलिपि बनाने का एक विशेष रूप है; जब आप किसी प्रोजेक्ट का क्लोन बनाते हैं, तो आपको रेपो में शामिल सभी फाइलों के साथ-साथ प्रोजेक्ट के संपूर्ण गिट-ट्रैक इतिहास की एक प्रति प्राप्त होती है। हमारे रेपो को क्लोन करके, आपको KiCad के साथ Git का उपयोग करने के लिए हमारी सिफारिशों के साथ पहले से ही संरचित एक परियोजना निर्देशिका मिलती है। हम चरण 6 में परियोजना संरचना के बारे में अधिक जानकारी देंगे, या यदि आप काम करने के लिए खुजली कर रहे हैं तो आप चरण 7 पर जा सकते हैं।

कुछ त्वरित हाउसकीपिंग कार्य - आपके द्वारा क्लोन किए गए जीथब प्रोजेक्ट के लिंक को हटाने के लिए `गिट रिमोट आरएम ओरिजिन` चलाएं। इसके अलावा, 'गिट कमिट --amend --author="John Doe "` चलाएं, लेखक पैरामीटर को अपने नाम और ईमेल से बदलें। यह अंतिम प्रतिबद्धता में संशोधन करता है (जो इस मामले में भी पहली प्रतिबद्धता है) और ब्रेनबो के बजाय लेखक को आपके लिए बदल देता है।

चरण 4: स्थापना नोट: KiCad पुस्तकालय

KiCad की लाइब्रेरी संरचना के बारे में एक त्वरित नोट। KiCad विद्युत घटकों की एक विस्तृत श्रृंखला के लिए डेवलपर टीम द्वारा बनाए गए पुस्तकालयों का एक सेट प्रदान करता है। तीन मुख्य पुस्तकालय हैं:

• योजनाबद्ध प्रतीक: सर्किट योजनाबद्ध ड्राइंग में इलेक्ट्रॉनिक घटकों का प्रतिनिधित्व करने के लिए उपयोग किए जाने वाले प्रतीक।
• पीसीबी फुटप्रिंट्स: पीसीबी पर सर्किट बिछाते समय उपयोग किए जाने वाले वास्तविक पदचिह्न (तांबे के पैड, सिल्कस्क्रीन टेक्स्ट, आदि) का प्रतिनिधित्व करने वाले 2 डी चित्र।
• 3D मॉडल: इलेक्ट्रॉनिक उपकरणों के 3D मॉडल।

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

यदि आप पुस्तकालयों का क्लोन बनाना चाहते हैं, तो यह साइट विभिन्न गिथब रेपो KiCad ऑफ़र का विवरण देती है। गिट आपके कंप्यूटर पर पुस्तकालयों को क्लोन करता है (उदा: `गिट क्लोन https://github.com/KiCad/kicad-symbols.git`), फिर KiCad खोलें, मेनू बार "प्राथमिकताएं" आइटम का चयन करें, और "पथ कॉन्फ़िगर करें … ". यह आपको KiCad को प्रत्येक पुस्तकालय को देखने के लिए निर्देशिका पथ बताने देता है। ये पर्यावरण चर KiCad स्थापना के साथ स्थापित पुस्तकालयों के पथ के लिए डिफ़ॉल्ट हैं; मैंने इन मूल्यों पर ध्यान दिया ताकि यदि आवश्यक हो तो मैं डिफ़ॉल्ट पुस्तकालयों में वापस जा सकता हूं। KICAD_SYMBOL_DIR पथ को आपके क्लोन किए गए kicad-symbols लाइब्रेरी, KISYSMOD को क्लोन किए गए kicad-footprints लाइब्रेरी और KISYS3DMOD को क्लोन किए गए kicad-packages3d लाइब्रेरी की ओर इंगित करना चाहिए।

जब आप पुस्तकालयों को अद्यतन करना चाहते हैं, तो आप पुस्तकालय रेपो में एक साधारण `गिट पुल` कमांड चला सकते हैं जो गिट को पुस्तकालय रेपो और जीथब "रिमोट" रेपो की आपकी स्थानीय प्रति के बीच अंतर की जांच करने के लिए कहेगा, और स्वचालित रूप से आपके अपडेट को अपडेट करेगा। परिवर्तनों को शामिल करने के लिए स्थानीय प्रति।

चरण 5: गिट फंडामेंटल

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

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

ब्रांचिंग और रिमोट जैसे अधिक जटिल विषय हैं, लेकिन स्रोत नियंत्रण के लाभ प्राप्त करने के लिए हमें इनका उपयोग करने की आवश्यकता नहीं है। हमें केवल अपनी KiCad डिज़ाइन फ़ाइलों में कमिट की एक श्रृंखला के साथ परिवर्तनों को ट्रैक करने की आवश्यकता है।

चरण 6: KiCad परियोजना संरचना

आइए पहले क्लोन किए गए KiCad-Starter प्रोजेक्ट की संरचना पर करीब से नज़र डालें। इसे आसान संगठन के लिए कई उपनिर्देशिकाओं में विभाजित किया गया है:

• सर्किट: इस फ़ोल्डर में वास्तविक KiCad प्रोजेक्ट फ़ाइलें (योजनाबद्ध, PCB, आदि) हैं। मैं इस फ़ोल्डर का नाम नहीं बदलता, लेकिन मैं प्रोजेक्ट के नाम के साथ सभी फाइलों का नाम बदलता हूं (Circuit.pro => ArduinoMini.pro)।

  • सर्किट.प्रो: KiCad प्रोजेक्ट फ़ाइल
  • circuit.sch: KiCad योजनाबद्ध फ़ाइल।
  • सर्किट.किकैड_पीसीबी: KiCad PCB लेआउट फ़ाइल।
• दस्तावेज़ीकरण: यह फ़ोल्डर परियोजना के संबंध में दस्तावेज़ीकरण संग्रहीत करने के लिए है। हमारे पास भविष्य में इस स्थान को बेहतर बनाने की योजना है, लेकिन अभी के लिए इसमें एक साधारण README फ़ाइल है। भविष्य में समीक्षा के लिए परियोजना पर नोट्स स्टोर करने के लिए इसका इस्तेमाल करें।
• फैब्रिकेशन: यह फोल्डर वह जगह है जहां आप गेरबर फाइलों को स्टोर करेंगे जो कि ज्यादातर फैब हाउस आपके सर्किट बोर्ड के निर्माण के लिए उपयोग करेंगे। हम इसका उपयोग बीओएम फाइलों और अन्य दस्तावेजों को स्टोर करने के लिए भी करते हैं जिनकी विनिर्माण और असेंबली के लिए आवश्यकता हो सकती है।
• पुस्तकालय: यह फ़ोल्डर परियोजना-विशिष्ट पुस्तकालय फ़ाइलों को संग्रहीत करने के लिए है (हम इसे कुछ चरणों में और अधिक कवर करेंगे)।

आपने कुछ अन्य फाइलें भी देखी होंगी (खासकर यदि आप निर्देशिका `ls -a` करते हैं)।.git निर्देशिका वह जगह है जहाँ Git अपना जादू करता है, रिपॉजिटरी के इतिहास को संग्रहीत करता है।.gitignore फ़ाइल का उपयोग Git को यह बताने के लिए किया जाता है कि उसे किन फ़ाइलों को अनदेखा करना चाहिए और स्रोत नियंत्रण में संग्रहीत नहीं करना चाहिए। ये ज्यादातर बैकअप फाइलें हैं जो KiCad उत्पन्न करती हैं, या कुछ अलग "जेनरेट" फाइलें, जैसे नेटलिस्ट, जिन्हें स्रोत नियंत्रण में संग्रहीत नहीं किया जाना चाहिए क्योंकि वे स्रोत से उत्पन्न होते हैं जो कि योजनाबद्ध फ़ाइल है।

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

चरण 7: KiCad परियोजनाओं के लिए Git का उपयोग करना

हम अंततः यह देखने के लिए तैयार हैं कि आपकी परियोजनाओं को ट्रैक करने के लिए Git का उपयोग कैसे करें। यह निर्देश आपको KiCad का उपयोग करने का तरीका सिखाने के लिए नहीं है (हालाँकि मैं भविष्य में ऐसा कर सकता हूँ अगर इसकी माँग है), तो हम आपको यह दिखाने के लिए कुछ तुच्छ उदाहरणों के माध्यम से चलेंगे कि वर्कफ़्लो कैसे चलता है। यह समझना आसान होना चाहिए कि इन विचारों को वास्तविक परियोजना में कैसे अनुकूलित किया जाए।

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

फिलहाल आपके रेपो में कोई बदलाव नहीं होना चाहिए। आइए एक बदलाव करें। KiCad प्रोजेक्ट खोलें और योजनाबद्ध में एक रोकनेवाला जोड़ें, फिर सहेजें। अब `गिट स्टेटस` चलाना यह दिखाना चाहिए कि आपने योजनाबद्ध फ़ाइल को संशोधित किया है, लेकिन उन परिवर्तनों को अभी तक प्रतिबद्ध नहीं किया है। यदि आप उत्सुक हैं कि वास्तव में KiCad ने क्या किया जब आपने रोकनेवाला जोड़ा, तो आप संशोधित फ़ाइल `git diff सर्किट/Circuit.sch` पर diff कमांड चला सकते हैं। यह कार्यशील निर्देशिका में फ़ाइल के वर्तमान संस्करण और अंतिम प्रतिबद्धता पर फ़ाइल की स्थिति के बीच परिवर्तनों को उजागर करेगा।

अब जबकि हमने एक परिवर्तन कर दिया है, आइए उस परिवर्तन को अपने प्रोजेक्ट इतिहास में करने का प्रयास करें। हमें अपनी कार्यशील निर्देशिका से स्टेजिंग क्षेत्र में परिवर्तनों को स्थानांतरित करने की आवश्यकता है। यह वास्तव में फ़ाइल सिस्टम में फ़ाइलों को स्थानांतरित नहीं करता है, लेकिन वैचारिक रूप से Git को यह बताने का एक तरीका है कि आपने किसी विशेष फ़ाइल के लिए अपने सभी नियोजित परिवर्तन किए हैं और उन परिवर्तनों को करने के लिए तैयार हैं। जब आप अगली क्रिया के लिए `गिट स्थिति` चलाते हैं तो मदद से, गिट कुछ संकेत प्रदान करता है। संदेश पर ध्यान दें `(जो प्रतिबद्ध होगा उसे अपडेट करने के लिए "गिट एड …" का उपयोग करें)` के तहत `परिवर्तन के लिए मंचन नहीं किया गया:`। गिट आपको बता रहा है कि स्टेजिंग क्षेत्र में परिवर्तनों को कैसे स्थानांतरित किया जाए। परिवर्तनों को चरणबद्ध करने के लिए `git add circuit/Circuit.sch` चलाएं, फिर जो हुआ उसे देखने के लिए `git status` चलाएं। अब हम योजनाबद्ध फ़ाइल को किए जाने वाले परिवर्तनों के अंतर्गत देखते हैं। यदि आप अभी तक इन परिवर्तनों को नहीं करना चाहते हैं, तो Git मददगार रूप से एक और टिप प्रदान करता है: `(अनस्टेज करने के लिए "git रीसेट HEAD …" का उपयोग करें)`। हम इन परिवर्तनों को करना चाहते हैं, इसलिए हम `गिट कमिट-एम "एडेड रेसिस्टर टू स्किमैटिक"` चलाते हैं। यह दिए गए संदेश के साथ परिवर्तन करता है। रनिंग git log इस कमिटमेंट को प्रोजेक्ट कमिट हिस्ट्री में दिखाएगा।

कमिट के बारे में कुछ और टिप्स।

1. हर बचत के साथ प्रतिबद्ध न हों। जब आपको लगे कि आप एक ऐसे बिंदु पर पहुंच गए हैं, जहां आपके परिवर्तन कुछ हद तक ठोस हो गए हैं, तब प्रतिबद्ध रहें। मैं एक योजनाबद्ध समाप्त करने के बाद प्रतिबद्ध हूं, प्रत्येक घटक जोड़ के बाद नहीं। आप बहुत बार-बार प्रतिबद्ध नहीं होना चाहते हैं, क्योंकि 3 सप्ताह बाद आपने जो परिवर्तन किए हैं, उनके संदर्भ को याद रखना मुश्किल हो सकता है। यह पता लगाना कि कब प्रतिबद्ध होना एक कला है, लेकिन जैसे-जैसे आप Git का अधिक उपयोग करेंगे, आप अधिक सहज होते जाएंगे।
2. केवल स्रोत (ज्यादातर) स्टोर करें। इसमें प्रोजेक्ट, योजनाबद्ध और लेआउट फ़ाइलें, साथ ही प्रोजेक्ट-विशिष्ट लाइब्रेरी शामिल हैं। इसमें दस्तावेज़ीकरण फ़ाइलें भी शामिल हो सकती हैं। व्युत्पन्न वस्तुओं को संग्रहीत करते समय सावधान रहें क्योंकि वे मूल स्रोत के साथ आसानी से सिंक से बाहर हो सकते हैं, और इससे बाद में सिरदर्द होता है। BOM और gerber फ़ाइलें विशेष रूप से आसानी से डी-सिंक्रनाइज़ हो जाती हैं, इसलिए बेहतर तरीके से बचा जाता है (हालाँकि अधिक विस्तृत मार्गदर्शन चरण 9 में शामिल है)।
3. प्रतिबद्ध संदेश बहुत उपयोगी हैं, लेकिन अच्छी तरह से संरचित प्रतिबद्ध संदेश अमूल्य हैं। यह उत्कृष्ट लेख स्पष्ट, संक्षिप्त, उपयोगी प्रतिबद्ध संदेश लिखने के लिए कुछ दिशानिर्देश प्रदान करता है। ऐसा करने के लिए कमांड लाइन टेक्स्ट एडिटर का उपयोग करने की आवश्यकता हो सकती है, जो मुझे शुरुआती लोगों के लिए जटिल कर सकता है (-एम संदेश विकल्प के बिना 'गिट प्रतिबद्ध' एक टेक्स्ट एडिटर खोल देगा)। ज्यादातर लोगों के लिए, मैं नैनो संपादक की सलाह देता हूं। StackOverflow में आपके संपादक को बदलने की अच्छी व्याख्या है

चरण 8: उन्नत: इलेक्ट्रॉनिक्स के लिए सिमेंटिक वर्जनिंग

साहसी लोगों के लिए, निम्नलिखित टिप्स उन्नत विचार हैं, जो KiCad के कई घंटों के विकास से प्राप्त हुए हैं। वे छोटी परियोजनाओं पर विशेष रूप से उपयोगी नहीं हैं, लेकिन वे वास्तव में आपको दिल के दर्द से बचा सकते हैं क्योंकि आपकी परियोजनाएं जटिलता में बढ़ती हैं।

सॉफ्टवेयर में सिमेंटिक वर्जनिंग (सेवर) की अवधारणा है। Semver "Major. Minor. Patch" के पैटर्न का अनुसरण करते हुए "संस्करण संख्या" द्वारा सॉफ़्टवेयर रिलीज़ की पहचान करने के लिए एक सामान्य नामकरण पद्धति को परिभाषित करता है। सेवर की कल्पना को उद्धृत करने के लिए, आप निम्न परिवर्तन श्रेणियों के अनुसार संस्करण संख्या को आगे बढ़ाते हैं।

1. प्रमुख संस्करण जब आप असंगत एपीआई परिवर्तन करते हैं,
2. माइनर संस्करण जब आप पश्च-संगत तरीके से कार्यक्षमता जोड़ते हैं,
3. जब आप पश्च-संगत बग फिक्स करते हैं तो पैच संस्करण।

ब्रेनबो में हम हार्डवेयर परियोजनाओं की जरूरतों को पूरा करने के लिए अनुकूलित सेवर के अपने संस्करण का उपयोग करते हैं। हमारी कल्पना उसी "Major. Minor. Patch" पैटर्न का अनुसरण करती है, हालांकि हमारी परिभाषाएं किस श्रेणी के अंतर्गत आती हैं, स्पष्ट रूप से भिन्न होती हैं।

1. प्रमुख संस्करण: सर्किट की मुख्य कार्यक्षमता में महत्वपूर्ण परिवर्तनों के लिए उपयोग किया जाता है (उदा: ATmega से ESP8266 में प्रोसेसर स्विच करना)।
2. माइनर संस्करण: घटक स्वैप के लिए उपयोग किया जाता है जो सर्किट ऑपरेशन को प्रभावित कर सकता है (उदा: पिन-संगत भाग के साथ एसपीआई फ्लैश स्वैप जिसमें एक अलग कमांड सेट हो सकता है) या कुछ मामूली अतिरिक्त सुविधा (उदा: अतिरिक्त तापमान सेंसर जोड़ा गया)।
3. पैच संस्करण: छोटे बग फिक्स के लिए उपयोग किया जाता है जो सर्किट ऑपरेशन को नहीं बदलेगा (उदा: सिल्क्सस्क्रीन समायोजन, मामूली ट्रेस लेआउट समायोजन, 0603 कैपेसिटर से 0805 तक सरल घटक स्वैप)।

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

एक अच्छी तरह से परिभाषित नामकरण प्रणाली पर स्विच करने से आपको मिलने वाली स्थिरता और बोधगम्यता के लाभों के अलावा, आप फर्मवेयर संगतता और ग्राहकों की संतुष्टि में भी लाभ प्राप्त करते हैं। फर्मवेयर को उस बोर्ड के संस्करण को ध्यान में रखते हुए लिखा जा सकता है जिसे वह लक्षित कर रहा है, और यह डिबग करना आसान हो सकता है कि कोई विशेष प्रोग्राम किसी विशेष बोर्ड पर क्यों काम नहीं कर रहा है ("ठीक है, 2.4.1 फर्मवेयर 1.2 पर नहीं चलता है बोर्ड क्योंकि हमारे पास नहीं है ….")। ग्राहकों को हमारे हार्डवेयर सेवर से भी लाभ हुआ है क्योंकि ग्राहक सेवा और समस्या निवारण एक परिभाषित मानक के साथ बहुत आसान है।

चरण 9: उन्नत: हार्डवेयर शब्दार्थ संस्करण का उपयोग करना

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

रिलीज टैग को प्रतिबद्ध इतिहास में जोड़ा जाता है और 1.0.0 निर्माण पर फाइलों की स्थिति को इंगित करता है। यह विशेष रूप से बाद में कई संशोधनों के लिए उपयोगी हो सकता है जब आपको समस्या निवारण के लिए इस बिंदु पर वापस जाने की आवश्यकता होती है। एक निर्दिष्ट रिलीज टैग के बिना, यह पता लगाना मुश्किल हो सकता है कि निर्माण के समय कौन सी प्रतिबद्धता सबसे हालिया थी। एक 1.0.0 (और 1.1, 1.1.1, आदि) टैग आपको यह निर्दिष्ट करने देता है कि ये विशिष्ट स्रोत फ़ाइलें किसी विशेष निर्माण कार्य में उपयोग की गई थीं।

Gerbers पर एक नोट। कुछ फैब हाउसों को आपका बोर्ड बनाने के लिए गेरबर फाइलों की आवश्यकता होती है, और आप उन्हें KiCad के साथ उत्पन्न कर सकते हैं। ये व्युत्पन्न वस्तुएं हैं, जो स्रोत.kicad_pcb फ़ाइल से उत्पन्न होती हैं, और हम सामान्य रूप से व्युत्पन्न फ़ाइलों का संस्करण नियंत्रण नहीं करते हैं। जब हम किसी रिलीज़ को टैग करते हैं तो ब्रेनबो में हम जेरबर्स को वर्जन कंट्रोल में स्टोर नहीं करते हैं। जब हम निर्माण के लिए तैयार होते हैं, तो हम gerber फ़ाइलें उत्पन्न करते हैं, उन्हें निर्माण फ़ोल्डर में संग्रहीत करते हैं, और प्रतिबद्ध और टैग करते हैं। फिर हम गेरबर्स को हटाते हैं और हटाने के लिए प्रतिबद्ध होते हैं। यह पहली बार में थोड़ा भ्रमित करने वाला लग सकता है, लेकिन यह सुनिश्चित करता है कि सामान्य केवल स्रोत फ़ाइलों को संग्रहीत करता है, और टैग की गई रिलीज़ भी बोर्डों के निर्माण के लिए उपयोग की जाने वाली सटीक फ़ाइलों को संग्रहीत करती हैं। यह हफ्तों बाद विनिर्माण त्रुटियों को ट्रैक करने में उल्लेखनीय रूप से उपयोगी साबित हुआ है।

चरण 10: अगले चरण

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

Brainbow हमारे वर्कफ़्लो की कुछ अधिक उन्नत सुविधाओं के लिए अधिक विस्तृत मार्गदर्शिका पर काम कर रहा है। हमें उम्मीद है कि अगले कुछ महीनों में इसे किसी समय प्रकाशित किया जाएगा। इंस्ट्रक्शंस पर हमें यहां फॉलो करें, और हम आपको यह बताना सुनिश्चित करेंगे कि आप इसे कब पढ़ सकते हैं।

पढ़ने के लिए धन्यवाद, और हम यह देखने के लिए इंतजार नहीं कर सकते कि आप क्या बनाते हैं!