Skip to content

Latest commit

 

History

History
284 lines (187 loc) · 37.2 KB

README_hi.md

File metadata and controls

284 lines (187 loc) · 37.2 KB
Raw

मानक Go परियोजना अभिन्यास

अनुवाद:

अवलोकन

यह Go एप्लिकेशन1 परियोजनाओं2 के लिए एक बुनियादी अभिन्यास3 है। ध्यान दें कि यह सामग्री के संदर्भ में बुनियादी है क्योंकि यह केवल सामान्य अभिन्यास3 पर ध्यान केंद्रित करता है न कि इसके अंदर क्या है। यह बुनियादी भी है क्योंकि यह बहुत उच्च स्तर का है और यह इस संदर्भ में विस्तृत विवरण में नहीं जाता है कि आप अपनी परियोजना2 को और भी आगे कैसे संरचित4 कर सकते हैं। उदाहरण के लिए, यह आपके पास उपस्थित परियोजना2 संरचना4 को स्वच्छ वास्तुकला जैसी किसी चीज़ से ढकने का प्रयास नहीं करता है।

यह मूल5 Go डेवलपर6 दल द्वारा परिभाषित आधिकारिक मानक7 नहीं है। यह Go परितंत्र में सामान्य ऐतिहासिक और उभरती परियोजना2 अभिन्यास3 नमूनों8 का एक समूह है। इनमें से कुछ नमूनें8 दूसरों की तुलना में अधिक लोकप्रिय हैं। इसमें किसी भी बड़े वास्तविक एप्लिकेशन1 के लिए सामान्य सहायक फ़ोल्डरों9 के साथ-साथ कई छोटे संवर्द्धन भी हैं। ध्यान दें कि मूल5 Go दल Go परियोजनाओं2 की संरचना4 के बारे में सामान्य दिशानिर्देशों का एक बड़ा सेट प्रदान करते है और जब इसे आयात10 किया जाता है और जब इसे स्थापित11 किया जाता है तो आपकी परियोजना2 के लिए इसका क्या अर्थ होता है। अधिक विवरण के लिए आधिकारिक Go दस्तावेज़ों12 में Organizing a Go module पृष्ठ देखें। इसमें internal और cmd फ़ोल्डर9 नमूनें8 (नीचे वर्णित) और अन्य उपयोगी जानकारी शामिल है।

यदि आप Go सीखने की कोशिश कर रहे हैं या यदि आप अपने लिए एक अवधारणा प्रमाण13 या एक साधारण परियोजना2 बना रहे हैं तो यह परियोजना2 अभिन्यास3 ज़रूरत से ज़्यादा है। इसके स्थान पर वास्तव में कुछ सरल से शुरू करें (एक main.go फ़ाइल14 और go.mod पर्याप्त से अधिक है)। जैसे-जैसे आपकी परियोजना2 बढ़ती है, ध्यान रखें कि यह सुनिश्चित करना महत्वपूर्ण होगा कि आपका कोड15 ठीक से संरचित4 है अन्यथा आप बहुत सारी छिपी हुई निर्भरताओं16 और वैश्विक स्थिति के साथ गड़बड़ कोड15 पाएंगे। जब आपके पास परियोजना2 पर काम करने वाले अधिक लोग हों तो आपको और भी अधिक संरचना4 की आवश्यकता होगी। तभी संकुलों17/भंडारों18 को प्रबंधित19 करने का एक सामान्य तरीका पेश करना महत्वपूर्ण है। जब आपके पास एक खुला-स्रोत20 परियोजना2 होती है या जब आप जानते हैं कि अन्य परियोजनाएं2 आपकी परियोजना2 रिपॉजिटरी21 से कोड15 आयात10 करती हैं, तब निजी (उर्फ internal) संकुल17 और कोड15 होना महत्वपूर्ण है। रिपॉजिटरी21 को क्लोन करें, जो आपको चाहिए उसे रखें और बाकी सब हटा दें! सिर्फ इसलिए कि यह वहाँ है इसका मतलब यह नहीं है कि आपको इसका पूरा उपयोग करना होगा। प्रत्येक परियोजनाओं2 में इनमें से किसी भी नमूनों8 का उपयोग नहीं किया जाता है। यहां तक कि vendor नमूनां8 भी सार्वभौमिक22 नहीं है।

Go १.१४ के साथ Go Modules अंततः उत्पादन के लिए तैयार हैं। Go Modules का उपयोग करें जब तक कि आपके पास उनका उपयोग न करने का कोई विशेष कारण न हो और यदि आप ऐसा करते हैं तो आपको $GOPATH और के बारे में चिंता करने की आवश्यकता नहीं है जहाँ आपने अपनी परियोजना2 रखी है। रिपॉजिटरी21 में मूल5 go.mod फ़ाइल14 मानती है कि आपकी परियोजना को GitHub पर होस्ट किया गया है, लेकिन यह कोई आवश्यकता नहीं है। अनुखंड23 पथ कुछ भी हो सकता है, हालांकि पहले अनुखंड23 पथ अंग के नाम में एक बिंदु होना चाहिए (Go का वर्तमान संस्करण अब इसे लागू नहीं करता है, लेकिन यदि आप थोड़े पुराने संस्करणों का उपयोग कर रहे हैं तो आश्चर्यचकित न हों यदि आपका निर्माण24 विफल हो जाए)। यदि आप चाहें तो विवाद ३७५५४ और ३२८१९ इसके बारे में और अधिक जानने के लिए देखें।

यह परियोजना2 अभिन्यास3 जानबूझकर सामान्य है और यह किसी विशिष्ट Go संकुल17 संरचना4 को लागू करने का प्रयास नहीं करती है।

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

यदि आपको नामकरण, संरूपण, और शैली25 में मदद चाहिए तो gofmt और staticcheck चलाकर शुरुआत करें। पिछला मानक7 लिंटर26, golint, अब अप्रचलित है और इसका रखरखाव नहीं किया जा रहा है; staticcheck जैसे रखरखाव किए गए लिंटर26 के उपयोग की अनुशंसा27 की जाती है। इन Go कोड15 शैली25 दिशानिर्देशों और अनुशंसाओं27 को पढ़ना भी सुनिश्चित करें:

अतिरिक्त पृष्ठभूमि जानकारी के लिए Go Project Layout देखें।

संकुलों17 के नामकरण और आयोजन के साथ-साथ अन्य कोड15 संरचना4 अनुशंसाओं27 के बारे में अधिक जानकारी:

Go फ़ोल्डर

/cmd

इस परियोजना2 के लिए मुख्य अनुप्रयोग।

प्रत्येक एप्लिकेशन1 के लिए फ़ोल्डर9 का नाम उस executable के नाम से मेल खाना चाहिए जिसे आप रखना चाहते हैं (उदाहरण के लिए, /cmd/myapp)।

एप्लिकेशन1 फ़ोल्डर9 में बहुत सारा कोड15 न डालें। यदि आपको लगता है कि कोड15 को आयात10 किया जा सकता है और अन्य परियोजनाओं2 में उपयोग किया जा सकता है, तो इसे /pkg फ़ोल्डर9 में रहना चाहिए। यदि कोड15 पुन: उपयोग करने योग्य नहीं है या यदि आप नहीं चाहते कि अन्य लोग इसका पुन: उपयोग करें, तो उस कोड15 को /internal फ़ोल्डर9 में रखें। आप आश्चर्यचकित होंगे कि दूसरे क्या करेंगे, इसलिए अपने इरादों के बारे में स्पष्ट रहें!

एक छोटा main फलन28 होना आम बात है जो /internal और /pkg फ़ोल्डरों9 से कोड15 आयात10 और उपयोग करता है और कुछ नहीं।

उदाहरण के लिए /cmd फ़ोल्डर9 देखें।

/internal

निजी एप्लिकेशन1 और भंडार18 कोड15। यह वह कोड15 है जिसे आप नहीं चाहते कि अन्य लोग अपने एप्लिकेशन1 या भंडार18 में आयात10 करें। ध्यान दें कि यह अभिन्यास3 नमूनां8 Go संकलनकर्ता29 द्वारा ही लागू किया गया है। अधिक विवरण के लिए Go १.४ release notes देखें। ध्यान दें कि आप शीर्ष स्तर की internal फ़ोल्डर9 तक सीमित नहीं हैं। आपकी परियोजना2 संरचना4 के किसी भी स्तर पर एक से अधिक internal फ़ोल्डर9 हो सकते है।

आप वैकल्पिक रूप से अपने साझा और गैर-साझा आंतरिक कोड15 को अलग करने के लिए अपने आंतरिक संकुलों17 में कुछ अतिरिक्त संरचना4 जोड़ सकते हैं। इसकी आवश्यकता नहीं है (विशेषकर छोटी परियोजनाओं2 के लिए), लेकिन इच्छित संकुल17 उपयोग को दर्शाने वाले दृश्य सुराग होना अच्छा है। आपका वास्तविक एप्लिकेशन1 कोड15 /internal/app फ़ोल्डर9 में जा सकता है (उदाहरण के लिए, /internal/app/myapp) और उन एप्लिकेशनों1 द्वारा साझा किया गया कोड15 /internal/pkg फ़ोल्डर9 में जा सकता है (उदाहरण के लिए, /internal/pkg/myprivlib).

/pkg

भंडार18 कोड15 जो बाहरी एप्लिकेशनों1 द्वारा उपयोग करने के लिए ठीक है (उदाहरण के लिए, /pkg/mypubliclib)। अन्य परियोजनाएं2 इन भंडारों18 को काम करने की उम्मीद में आयात10 करेंगी, इसलिए यहां कुछ भी डालने से पहले दो बार सोचें 😄। ध्यान दें कि internal फ़ोल्डर9 यह सुनिश्चित करने का एक बेहतर तरीका है कि आपके निजी संकुल17 आयात10 योग्य नहीं हैं क्योंकि यह Go द्वारा लागू किया गया है। /pkg फ़ोल्डर9 अभी भी स्पष्ट रूप से यह बताने का एक अच्छा तरीका है कि उस फ़ोल्डर9 का कोड15 दूसरों के उपयोग के लिए सुरक्षित है। Travis Jeffrey द्वारा I'll take pkg over internal ब्लॉग लेख pkg और internal फ़ोल्डरों9 का एक अच्छा अवलोकन30 प्रदान करता है और कब उनका उपयोग करना उचित हो सकता है।

यह Go कोड15 को एक ही स्थान पर समूहित करने का एक तरीका है जब आपके मूल5 फ़ोल्डर9 में बहुत सारे गैर-Go अंग और फ़ोल्डर9 होते हैं जिससे विभिन्न Go उपकरण31 चलाना आसान हो जाता है (जैसा कि इन वार्ताओं में बताया गया है: Best Practices for Industrial Programming GopherCon EU २०१८ से, GopherCon 2018: Kat Zien - How Do You Structure Your Go Apps और GoLab 2018 - Massimiliano Pippi - Project layout patterns in Go)।

यदि आप देखना चाहते हैं कि कौनसी लोकप्रिय Go रिपॉजिटरीयाँ21 इस परियोजना2 अभिन्यास3 का उपयोग करती हैं तो /pkg फ़ोल्डर9 देखें। यह एक सामान्य अभिन्यास3 नमूनां8 है, लेकिन यह सार्वभौमिक22 रूप से स्वीकृत नहीं है और Go समुदाय के कुछ लोग इसकी अनुशंसा27 नहीं करते हैं।

यदि आपकी एप्लिकेशन1 परियोजना2 वास्तव में छोटी है और जहां अतिरिक्त स्तर का नेस्टिंग32 अधिक मूल्य नहीं जोड़ता है (जब तक कि आप वास्तव में नहीं चाहते 😄) तो इसका उपयोग न करना ठीक है। इसके बारे में तब सोचें जब यह काफी बड़ी हो रहा हो और आपका मूल5 फ़ोल्डर9 काफी व्यस्त हो जाए (खासकर यदि आपके पास बहुत सारे गैर-Go एप्लिकेशन1 अंग हैं)।

pkg फ़ोल्डर9 की उत्पत्ति: पुराने Go स्रोत20 कोड15 द्वारा अपने संकुलों17 के लिए pkg का उपयोग किया जाता था और फिर समुदाय में विभिन्न Go परियोजनाओं2 ने नमूनें8 की प्रतिलिपि बनाना शुरू कर दिया (अधिक संदर्भ के लिए Brad Fitzpatrick का यह 𝕏 (पूर्व Twitter) पोस्ट33 देखें)।

/vendor

एप्लिकेशन1 निर्भरताएं16 (हाथों से या आपके पसंदीदा निर्भरता16 प्रबंधन19 उपकरण31 जैसे नए अंतर्निहित34 Go Modules सुविधा द्वारा प्रबंधित19)। go mod vendor निर्देश35 आपके लिए /vendor फ़ोल्डर9 बनाएगा। ध्यान दें कि यदि आप Go १.१४ का उपयोग नहीं कर रहे हैं, जहाँ यह पूर्व-निर्धारित36 रूप से चालू है, तो आपको अपने go build निर्देश35 में -mod=vendor सूचक37 जोड़ने की आवश्यकता हो सकती है।

यदि आप भंडार18 का निर्माण24 कर रहे हैं तो अपनी एप्लिकेशन1 निर्भरताऔं16 को सुपुर्द38 न करें।

ध्यान दें कि चूंकि 1.13 से Go ने अनुखंड23 प्रॉक्सी39 सुविधा को भी सक्षम किया है (https://proxy.golang.org का उपयोग करके) पूर्व-निर्धारित36 रूप से उनके अनुखंड23 प्रॉक्सी39 सर्वर40 के रूप में। इसके बारे में और अधिक पढ़ें यहाँ यह देखने के लिए कि क्या यह आपकी सभी आवश्यकताओं और बाधाओं पर फिट बैठता है। यदि ऐसा होता है, तो आपको vendor फ़ोल्डर9 की बिल्कुल भी आवश्यकता नहीं होगी।

सेवा एप्लिकेशन फ़ोल्डर

/api

OpenAPI/Swagger विनिर्देशों41, JSON स्कीमा42 फ़ाइलों14, प्रोटोकॉल43 परिभाषा फ़ाइलों14 के लिए।

उदाहरण के लिए /api फ़ोल्डर9 देखें।

वेब एप्लिकेशन फ़ोल्डर

/web

वेब44 एप्लिकेशन1 विशिष्ट अंग: स्थिर वेब44 संपत्तियाँ45, सर्वर40 पक्ष टेम्पलेट46 और SPA (एक पृष्ठ एप्लिकेशन1)।

सामान्य एप्लिकेशन फ़ोल्डर

/configs

कॉन्फ़िगरेशन47 फ़ाइल14 टेम्पलेट46 या पूर्व-निर्धारित36 कॉन्फ़िगरेशन47।

अपनी confd या consul-template टेम्प्लेट46 फ़ाइलें14 यहाँ रखें।

/init

तंत्र48 प्रारंभिकरण49 (systemd, upstart, sysv) और प्रक्रिया50 प्रबंधक19/पर्यवेक्षक (runit, supervisord) कॉन्फ़िगरेशन47।

/scripts

विभिन्न निर्माण24, स्थापना11, विश्लेषण आदि संचालन करने के लिए स्क्रिप्टें51।

ये स्क्रिप्टें51 मूल5 स्तर कि Makefile को छोटा और सरल रखती हैं (उदाहरण के लिए, https://github.com/hashicorp/terraform/blob/main/Makefile).

उदाहरण के लिए /scripts फ़ोल्डर9 देखें।

/build

Packaging और Continuous Integration।

अपने क्लाउड52 (AMI), कंटेनर53 (Docker), OS (deb, rpm, pkg) संकुल17 कॉन्फ़िगरेशनों47 और स्क्रिप्टों51 को /build/package फ़ोल्डर9 में रखें।

अपने CI (travis, circle, drone) कॉन्फ़िगरेशनों47 और स्क्रिप्टों51 को /build/ci फ़ोल्डर9 में रखें। ध्यान दें कि कुछ CI उपकरण31 (उदाहरण के लिए, Travis CI) अपनी कॉन्फ़िगरेशन47 फ़ाइलों14 के स्थान के बारे में बहुत चुनिंदा हैं। कॉन्फ़िगरेशन47 फ़ाइलों14 को /build/ci फ़ोल्डर9 में डालने का प्रयास करें और उन्हें उस स्थान से लिंक54 करें जहाँ CI उपकरण31 उनसे अपेक्षा करते हैं (जब संभव हो)।

/deployments

IaaS, PaaS, तंत्र48 और कंटेनर53 ऑर्केस्ट्रेशन55 परिनियोजन56 कॉन्फ़िगरेशनों47 और टेम्पलेटों46 (docker-compose, kubernetes/helm, terraform)। ध्यान दें कि कुछ रिपॉजिटरीयाँ21 (विशेष रूप से kubernetes के साथ परिनियोजित56 एप्लिकेशनें1) में इस फ़ोल्डर9 को /deploy कहा जाता है।

/test

अतिरिक्त बाहरी परीक्षण57 एप्लिकेशनों1 और परीक्षण57 डेटा58 के लिए। बेझिझक /test फ़ोल्डर9 को अपनी इच्छानुसार संरचित4 करें। बड़ी परियोजनाओं2 के लिए डेटा58 उप-फ़ोल्डर9 का होना सार्थक है। उदाहरण के लिए, यदि आप चाहते हैं कि उस फ़ोल्डर9 में जो कुछ है उसे अनदेखा करें तो आपके पास /test/data या /test/testdata हो सकता है। ध्यान दें कि Go "." या "_" से शुरू होने वाले फ़ोल्डरों9 या फ़ाइलों14 को भी अनदेखा कर देगा, इसलिए आपके पास अपने परीक्षण57 डेटा58 फ़ोल्डर9 को नाम देने के मामले में अधिक लचीलापन है।

उदाहरणों के लिए /test फ़ोल्डर9 देखें।

अन्य फ़ोल्डर

/docs

डिज़ाइन59 और उपयोगकर्ता दस्तावेज़ों12 (आपके godoc द्वारा उत्पन्न दस्तावेज़ों12 के अतिरिक्त) के लिए।

उदाहरणों के लिए /docs फ़ोल्डर9 देखें।

/tools

परियोजना2 के लिए सहायक उपकरणों31 के लिए। ध्यान दें कि ये उपकरण31 /pkg और /internal फ़ोल्डरों9 से कोड15 आयात10 कर सकते हैं।

उदाहरणों के लिए /tools फ़ोल्डर9 देखें।

/examples

आपकी एप्लिकेशनों1 और/या सार्वजनिक60 भंडारों18 के लिए उदाहरणों के लिए।

उदाहरणों के लिए /examples फ़ोल्डर9 देखें।

/third_party

बाहरी सहायक उपकरणों31, फोर्क61 किया हुए कोड15 और अन्य तृतीय पक्ष उपयोगिताऔं (उदाहरण के लिए, Swagger UI) के लिए।

/githooks

Git हुकों62 के लिए।

/assets

अन्य संपत्तियाँ45 जैसे चित्र, प्रतीक-चिन्ह63 इत्यादि के लिए जो परियोजना2 से संबंधित हैं।

/website

यदि आप GitHub Pages का उपयोग नहीं कर रहे हैं तो यह आपकी परियोजना2 की वेबसाइट64 डेटा58 डालने का स्थान है।

उदाहरणों के लिए /website फ़ोल्डर9 देखें।

फ़ोल्डर जो आपके पास नहीं होना चाहिए

/src

कुछ Go परियोजनाओं2 में एक src फ़ोल्डर9 होता है, लेकिन यह आमतौर पर तब होता है जब डेवलपर6 Java दुनिया से आते हैं जहाँ यह एक सामान्य नमूनां8 है। यदि आप अपनी मदद कर सकते हैं तो इस Java नमूनें8 को न अपनाने का प्रयास करें। आप वास्तव में नहीं चाहते कि आपका Go कोड15 या Go परियोजना2 Java जैसे दिखें। 😄

परियोजना2 स्तर के /src फ़ोल्डर9 को उस /src फ़ोल्डर9 के साथ भ्रमित न करें जिसका उपयोग Go अपने कार्यक्षेत्रों65 के लिए करता है जैसा कि How to Write Go Code में वर्णित है। $GOPATH पर्यावरण चर66 आपके (वर्तमान) कार्यक्षेत्र65 को इंगित करता है (डिफ़ॉल्ट रूप से यह गैर-Windows तंत्र48 पर $HOME/go को इंगित करता है)। इस कार्यक्षेत्र65 में शीर्ष स्तर /pkg, /bin और /src फ़ोल्डरें9 शामिल हैं। आपकी वास्तविक परियोजना2 /src के अंतर्गत एक उप-फ़ोल्डर9 बनकर समाप्त होता है, इसलिए यदि आपकी परियोजना2 में /src फ़ोल्डर9 है तो परियोजना2 पथ इस तरह दिखेगा: /some/path/to/workspace/src/your_project/src/your_code.go. ध्यान दें कि Go १.११ के साथ आपकी परियोजना2 को आपके $GOPATH के बाहर रखना संभव है, लेकिन फिर भी इसका मतलब यह नहीं है कि इस अभिन्यास3 नमूनें8 का उपयोग करना एक अच्छा विचार है।

बैज

  • Go Report Card - यह आपके कोड15 को gofmt, go vet, gocyclo, golint, ineffassign, license और misspell के साथ स्कैन करेगा। github.com/golang-standards/project-layout को अपनी परियोजना2 संदर्भ से बदलें।

    Go Report Card

  • GoDoc - यह आपके GoDoc जनित दस्तावेज़12 का ऑनलाइन संस्करण प्रदान करेगा। अपनी परियोजना2 को इंगित करने के लिए लिंक54 बदलें।

    Go Doc

  • pkg.go.dev - pkg.go.dev Go खोज और दस्तावेज़ों12 के लिए एक नया ठिकाना है। आप बैज निर्माण24 उपकरण31 का उपयोग करके एक बैज बना सकते हैं।

    PkgGoDev

  • प्रकाशन - यह आपकी परियोजना2 के लिए नवीनतम प्रकाशन अंक दिखाएगा। अपनी परियोजना2 को इंगित करने के लिए GitHub लिंक54 बदलें।

    Release

टिप्पणी

नमूनें8/पुन: उपयोगी कॉन्फ़िगरेशनें47, स्क्रिप्टें51 और कोड15 के साथ एक अधिक विचारशील परियोजना2 टेम्पलेट46 कार्य प्रगति पर है।

शब्द सूची

नीचे दिए गए तिरछे शब्द आगत शब्द हैं।

Footnotes

  1. एप/एप्लिकेशन - app/application ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18

  2. परियोजना - project ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20 ↩21 ↩22 ↩23 ↩24 ↩25 ↩26 ↩27 ↩28 ↩29 ↩30 ↩31 ↩32 ↩33 ↩34 ↩35 ↩36 ↩37 ↩38 ↩39 ↩40

  3. अभिन्यास - layout ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  4. संरचना - structure ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

  5. मूल - core/root ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  6. डेव/डेवलपर - dev/developer ↩ ↩2

  7. मानक - standard ↩ ↩2

  8. नमूनां - pattern ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14

  9. फ़ोल्डर - folder ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20 ↩21 ↩22 ↩23 ↩24 ↩25 ↩26 ↩27 ↩28 ↩29 ↩30 ↩31 ↩32 ↩33 ↩34 ↩35 ↩36 ↩37 ↩38 ↩39 ↩40 ↩41 ↩42 ↩43 ↩44 ↩45 ↩46

  10. आयात - import ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  11. स्थापन - install ↩ ↩2

  12. दस्तावेज़ - document ↩ ↩2 ↩3 ↩4 ↩5

  13. अवधारणा प्रमाण - proof of concept ↩

  14. फ़ाइल - file ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  15. कोड - code ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20 ↩21 ↩22 ↩23 ↩24 ↩25

  16. निर्भरता - dependency ↩ ↩2 ↩3 ↩4

  17. संकुल - package ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  18. भंडार - library ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  19. प्रबंध - manage ↩ ↩2 ↩3 ↩4

  20. स्रोत - source ↩ ↩2

  21. रिपॉजिटरी - repository ↩ ↩2 ↩3 ↩4 ↩5

  22. सार्वभौमिक - universal ↩ ↩2

  23. अनुखंड - module ↩ ↩2 ↩3 ↩4

  24. निर्माण - build ↩ ↩2 ↩3 ↩4

  25. शैली - style ↩ ↩2

  26. लिंट - lint ↩ ↩2

  27. अनुशंसा - recommend ↩ ↩2 ↩3 ↩4

  28. फलन - function ↩

  29. संकलनकर्ता - compiler ↩

  30. अवलोकन - overview ↩

  31. उपकरण - tool ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  32. नेस्टिंग - nesting ↩

  33. पोस्ट - post ↩

  34. अंतर्निहित - built-in ↩

  35. निर्देश - command ↩ ↩2

  36. पूर्व-निर्धारित - default ↩ ↩2 ↩3

  37. सूचक - flag ↩

  38. सुपुर्द - commit ↩

  39. प्रॉक्सी - proxy ↩ ↩2

  40. सर्वर - server ↩ ↩2

  41. विनिर्देश - specification ↩

  42. स्कीमा - schema ↩

  43. प्रोटोकॉल - protocol ↩

  44. वेब - web ↩ ↩2

  45. संपत्ति - asset ↩ ↩2

  46. टेम्पलेट - template ↩ ↩2 ↩3 ↩4 ↩5

  47. कॉन्फ़िग/कॉन्फ़िगर - config/configure ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  48. तंत्र - system ↩ ↩2 ↩3

  49. प्रारंभिकरण - init/initialization ↩

  50. प्रक्रिया - process ↩

  51. स्क्रिप्ट - script ↩ ↩2 ↩3 ↩4 ↩5

  52. क्लाउड - cloud ↩

  53. कंटेनर - container ↩ ↩2

  54. लिंक - link ↩ ↩2 ↩3

  55. ऑर्केस्ट्रेशन - orchestration ↩

  56. परिनियोजन - deployment ↩ ↩2

  57. परीक्षण - testing ↩ ↩2 ↩3

  58. डेटा - data ↩ ↩2 ↩3 ↩4

  59. डिज़ाइन - design ↩

  60. सार्वजनिक - public ↩

  61. फोर्क - fork ↩

  62. हुक - hook ↩

  63. प्रतीक-चिन्ह - logo ↩

  64. वेबसाइट - website ↩

  65. कार्यक्षेत्र - workspace ↩ ↩2 ↩3

  66. चर - variable ↩