जानें कि vibe-coding प्लेटफ़ॉर्म से स्रोत कोड कैसे क्लीनली एक्सपोर्ट करें और ownership कैसा लें: लोकली रन करें, CI सेटअप करें, सीक्रेट्स प्रबंधित करें, और हेंडऑफ-रेडी रिपो तैयार करें।
कोड का मालिक होना सिर्फ प्लेटफ़ॉर्म से एक zip फ़ाइल मिलना नहीं है। इसका अर्थ है कि आप बिना मूल वर्कस्पेस, खास बटनों, या छिपी सेटिंग्स के ऐप को बिल्ड, रन, बदल और रिलीज़ कर सकें। असली तौर पर आपका प्रोजेक्ट किसी भी सामान्य रिपो की तरह व्यवहार करता है: नया साथी इसे क्लोन करे, अपने लैपटॉप पर चलाए, और सामान्य पाइपलाइन से डिप्लॉय कर दे।
अधिकांश लॉक-इन की चिंता वही कुछ गैप से आती है:
एक और आम आश्चर्य तब आता है जब होस्टेड वर्शन पर ऐप ठीक चलता है, पर लोकली फेल हो जाता है क्योंकि environment variables, डेटाबेस सेटअप, या सीक्रेट्स को स्पष्ट नहीं किया गया था।
vibe-coding प्लेटफ़ॉर्म से एक साफ़ एक्सपोर्ट से चार नतीजे होने चाहिए:
यह महत्व रखता है भले ही आप कभी प्लेटफ़ॉर्म छोड़ने का इरादा न रखते हों। ठोस स्वामित्व एक बीमा है: यह रिस्क घटाता है, ऑडिट आसान बनाता है, और एजेंसी हायर करने, फंड जुटाने, या टीम बदलने पर बातचीत को सरल बनाता है।
यदि आप Koder.ai का उपयोग कर रहे थे, तो आपका एक्सपोर्ट आमतौर पर परिचित स्टैक्स शामिल कर सकता है जैसे React वेब ऐप, Go बैकएंड, PostgreSQL, या Flutter मोबाइल ऐप। स्टैक से ज्यादा मायने सिद्धांत का है: चलाने के लिए सब कुछ रिपॉज़िटरी में दिखना चाहिए, होस्टेड एनवायरनमेंट में नहीं फंसा होना चाहिए।
एक संस्थापक को कंत्राटी को ऐप सौंपते हुए कल्पना करें। "यह रहा रिपो" पर्याप्त होना चाहिए। कंत्राटी को मूल प्लेटफ़ॉर्म प्रोजेक्ट का एक्सेस नहीं चाहिए कि वह API बेस URL ढूँढे, डेटाबेस स्कीमा बनाए, या फ्रंटेंड बिल्ड कैसे करना है यह जाने।
एक्सपोर्ट के बाद आपके पास एक सामान्य रिपॉज़िटरी होनी चाहिए जिसे आप एडिटर में खोल सकें, अपने लैपटॉप पर चला सकें, और बिना मूल प्लेटफ़ॉर्म के किसी टीम को दे सकें।
Koder.ai प्रोजेक्ट्स के साथ, एक्सपोर्ट अक्सर परिचित संरचनाओं से मेल खाते हैं: एक React वेब ऐप, एक Go बैकएंड, और (यदि आपने बनाया था) एक Flutter मोबाइल ऐप। फ़ोल्डर के नाम अलग हो सकते हैं, पर रिपो को स्पष्ट होना चाहिए कि हर भाग कहाँ रहता है और वे कैसे जुड़ते हैं।
एंट्री पॉइंट और इरादे में वर्कफ़्लो का पता लगाना शुरू करें। आप हर ऐप की पहली फ़ाइल ढूँढना चाहेंगे जो उसे बूट करती है, साथ ही वे स्क्रिप्ट्स जो दिखाती हैं कि आपको डेवलप और रन कैसे करना है।
आम संकेत:
package.json और एक src/ फ़ोल्डर (अक्सर main.tsx या समान)go.mod और एक cmd/ फ़ोल्डर या main.gopubspec.yaml और lib/main.dartREADME या Makefile जो बताता है कि सब कुछ कैसे चलाएँdocker-compose.ymlनिर्भरताएँ पिन की हुई होनी चाहिए। JavaScript के लिए इसका मतलब है एक लॉकफ़ाइल (package-lock.json, yarn.lock, या pnpm-lock.yaml)। Go के लिए go.mod और go.sum। लॉक मिस होने से प्रोजेक्ट असंभव नहीं बनता, पर रिपीटेबल बिल्ड्स कठिन हो जाते हैं।
कॉन्फ़िगरेशन को कोड से अलग होना चाहिए। .env.example या config.example.yaml जैसे उदाहरण खोजें। आपको वास्तविक सीक्रेट्स (API कीज़, प्रोडक्शन पासवर्ड) एक्सपोर्ट में कमिट नहीं दिखने चाहिए। अगर दिखें तो इसे लीक समझें और रोटेट करें।
डेटाबेस के लिए, माइग्रेशन्स फ़ोल्डर (migrations/, db/migrations/) या टाइमस्टैम्प वाले SQL फ़ाइलें खोजें। Go + PostgreSQL ऐप में आप एक छोटा माइग्रेशन रनर या माइग्रेशन्स लागू करने वाला स्क्रिप्ट भी देख सकते हैं।
एक तेज़ सैनीटी चेक: पहले बिल्ड और रन कमांड्स खोजें (npm run dev, go run, make, और ऐसे ही)। अगर कोई स्क्रिप्ट प्लेटफ़ॉर्म-ओनली कमांड पर निर्भर है, तो उससे रिप्लेस करें ताकि रिपो स्वतंत्र बन सके।
एक्सपोर्ट को एक रिलीज़ आर्टिफैक्ट की तरह ट्रीट करें। कुछ भी चलाने से पहले एक त्वरित "सब यहाँ है?" पास करें। कमी को पकड़ना शुरू के समय आसान है बजाय बाद में जब आप बदल रहे हों।
एक व्यावहारिक पूर्णता चेक यह है कि हर हिस्से की "जड़ें" देखें: React वेब ऐप के लिए package.json, Go बैकएंड के लिए go.mod, और PostgreSQL के लिए माइग्रेशन/सीड फ़ाइलें।
एक्सपोर्टेड फ़ोल्डर से एक नया Git रिपोज़िटरी बनाएं, फिर ठीक वैसा ही कमिट करें जैसा आपको मिला, बिना कुछ ठीक किए। यह आपको एक साफ़ बेसलाइन देता है और बाद की बदलाओं की समीक्षा आसान बनाता है।
git init
# Optional: set default branch name
# git branch -M main
git add -A
git commit -m "Initial export"
अब छोटे, सत्यापनीय स्टेप्स में लोकली चलाएँ। निर्भरताएँ इंस्टॉल करें, लोकल कॉन्फ़िग बनाएं, पहले डेटाबेस शुरू करें, फिर बैकएंड, फिर फ्रंटएंड। करते समय हर कमांड नोट करिए—वो नोट्स आपका README बन जाते हैं।
यहाँ एक सरल कमांड सीक्वेंस है जिसे आप अपने एक्सपोर्टेड स्ट्रक्चर के अनुसार अनुकूलित कर सकते हैं:
# Frontend
cd web
npm install
npm run dev
# Backend
cd ../server
go mod download
go run ./cmd/server
एक सर्वर बूट तो हो सकता है जबकि ऐप फिर भी टूटा हुआ हो। पुष्टि करें कि यह डेटा पढ़ और लिख सकता है।
उत्पाद के अनुरूप तेज़ चेक चुनें:
एक बार लोकल रन काम करने लगे, अपने स्क्रैच नोट को एक वास्तविक README.md में बदल दें: कहां से कमांड चलानी है, सर्विसेज़ को किस क्रम में स्टार्ट करना है, और कौन से environment variables आवश्यक हैं।
एक्सपोर्ट चल सकता है, पर फिर भी "जनरेटेड" जैसा महसूस करवा सकता है बजाय मालिकाना महसूस कराने के। एक हेंडऑफ-रेडी रिपो यह स्पष्ट कर देता है कि चीज़ें कहाँ रहती हैं, कैसे चलती हैं, और इसे कैसे स्थिर रखा जाए।
एक स्पष्ट शीर्ष-स्तरीय लेआउट से शुरू करें। नाम से ज़्यादा निरंतरता मायने रखती है।
apps/ उपयोगकर्ता-समक्ष फ्रंटएंड्स के लिए (web, mobile)services/ बैकएंड APIs, workers, और jobs के लिएshared/ साझा प्रकार और यूटिलिटीज़ के लिएinfra/ डिप्लॉयमेंट टेम्प्लेट, स्क्रिप्ट्स, और पर्यावरण उदाहरणों के लिएdocs/ आर्किटेक्चर नोट्स और रनबुक्स के लिएफिर कुछ छोटी फ़ाइलें जोड़ें जो अनुमान घटाएँ:
README.md जिसमें प्रीरेक्विज़िट्स और सटीक कमांड होंCONTRIBUTING.md में कुछ नियम (ब्रांच, PR, कोई सीक्रेट्स नहीं).gitignore ताकि लोकल env फ़ाइलें और बिल्ड आउटपुट Git में न जाएँREADME को व्यावहारिक रखें। यदि रिपो में कई हिस्से हैं (React frontend, Go API, PostgreSQL), तो उन्हें स्टार्ट करने का क्रम और कॉन्फ़िग कहाँ रहती है यह स्पष्ट करें (उदाहरण: ".env.example को .env में कॉपी करें")।
एक फ्रेश-मशीन चेक करें: नई फ़ोल्डर में क्लोन करें और अपने README को फॉलो करें। यदि आप Koder.ai से एक्सपोर्ट कर रहे हैं, तो एक्सपोर्ट को नए स्वतंत्र प्रोजेक्ट की पहली कमिट मानें, और उसी के बाद दूसरों को आमंत्रित करें।
एक अच्छा लोकल सेटअप एक सवाल का तेज़ जवाब देता है: क्या नया व्यक्ति बिना अनुमान के 15 मिनट से कम में ऐप चला सकता है?
एक डिफ़ॉल्ट लोकल अप्रोच चुनें और स्पष्ट रहें। नेटिव इंस्टॉल तेज़ होते हैं उन लोगों के लिए जिनके पास सही टूल्स हैं। कंटेनर मशीनों में अधिक सुसंगत होते हैं पर ओवरहेड जोड़ते हैं। यदि आप दोनों सपोर्ट करते हैं, तो एक को डिफ़ॉल्ट बताएं और दूसरे को वैकल्पिक कहें।
एक सरल पैटर्न जो अच्छा काम करता है: एक README पेज, एक सैंपल env फ़ाइल, और एक बूटस्ट्रैप कमांड।
फेक वैल्यूज़ के साथ एक उदाहरण फ़ाइल कमिट करें ताकि लोग जानें क्या सेट करना है बिना सीक्रेट लीक किए।
# .env.example (example values only)
APP_ENV=local
PORT=8080
DATABASE_URL=postgres://app_user:app_pass@localhost:5432/app_db?sslmode=disable
JWT_SECRET=change-me
API_BASE_URL=http://localhost:8080
README में बताएं असली फ़ाइल कहाँ रहती है (उदाहरण के लिए, ".env.example को .env में कॉपी करें") और कौन से वेरिएबल्स आवश्यक बनाम वैकल्पिक हैं।
एक छोटा स्क्रिप्ट जोड़ें जो सही क्रम में उबाऊ स्टेप्स चलाए। इसे पठनीय रखें।
#!/usr/bin/env bash
set -euo pipefail
cp -n .env.example .env || true
# Backend deps
cd backend
go mod download
# Database: create, migrate, seed
./scripts/db_create.sh
./scripts/db_migrate.sh
./scripts/db_seed.sh
# Frontend deps
cd ../web
npm install
डेटाबेस योजना के लिए, तीन चीज़ें दस्तावेज़ करें: DB कैसे बनती है, माइग्रेशन्स कैसे चलते हैं, और वास्तविक पहले रन के लिए seed डेटा कैसे मिलता है।
अंत में, एक त्वरित हेल्थ चेक जोड़ें ताकि लोग क्लिक करने से पहले पुष्टि कर सकें कि ऐप काम कर रहा है। GET /health जैसा छोटा endpoint जो "ok" रिटर्न करे (और डेटाबेस कनेक्टिविटी भी वेरिफाई करे) अक्सर काफी होता है।
जब आप प्रोजेक्ट एक्सपोर्ट करते हैं, कोड आपका हो सकता है, पर सीक्रेट्स प्राइवेट रहने चाहिए। मान लें कि रिपो नए teammates के साथ साझा किया जाएगा।
शुरू करें ये सूची बनाकर कि ऐप को रन करने के लिए क्या चाहिए। अंदाज़ा न लगाएं। कोड में कॉन्फ़िग रीड्स (environment variables, config files) स्किम करें और किसी भी इंटीग्रेशन को चेक करें जो आपने सक्षम किए थे।
एक बेसिक सीक्रेट्स इन्वेंटरी में आमतौर पर डेटाबेस क्रेडेंशियल्स, थर्ड-पार्टी API कीज़, ऑथ सेटिंग्स (OAuth या JWT), स्टोरेज क्रेडेंशियल्स, और ऐप-विशेष सीक्रेट्स जैसे एन्क्रिप्शन कीज़ या webhook साइनिंग सीक्रेट्स शामिल होते हैं।
निर्धारित करें कि हर एनवायरनमेंट में हर सीक्रेट कहाँ रखा जाएगा। एक अच्छा डिफ़ॉल्ट नियम:
.env (कमिट न करें)यदि आपने Koder.ai जैसे vibe-coding प्लेटफ़ॉर्म से एक्सपोर्ट किया है, तो मान लें कि चैट, लॉग्स, या सेटिंग पैनल में दिखे किसी भी चीज़ की कॉपी कहीं न कहीं जा सकती है। सीक्रेट्स को रिपो से तुरंत निकाल दें।
एक व्यावहारिक अप्रोच यह है कि एक सुरक्षित टेम्पलेट (.env.example) कमिट करें, असली वैल्यूज़ Git में न रखें (.env को .gitignore करें), और प्रोडक्शन सीक्रेट्स डिप्लॉय के समय इंजेक्ट करें।
अगर एक्सपोर्ट के दौरान किसी भी तरह का रिस्क रहा कि सीक्रेट्स एक्सपोज़ हुए, तो उन्हें रोटेट करें। प्राथमिकता दें: डेटाबेस पासवर्ड, OAuth क्लाइंट सीक्रेट्स, और webhook साइनिंग कीज़।
कुछ गार्डरेल्स जोड़ें ताकि यह फिर न हो: obvious सीक्रेट पैटर्न के लिए pre-commit चेक, CI में सीक्रेट स्कैन, तेज़ फेल करने वाला कड़ा कॉन्फ़िग लोडिंग, और अलग-अलग एनवायरनमेंट के लिए अलग क्रेडेंशियल्स।
एक छोटा SECRETS.md हेंडऑफ के लिए मददगार होगा। सरल रखें: आवश्यक वेरिएबल्स, प्रत्येक एनवायरनमेंट में वे कहाँ स्टोर हैं, और कौन उन्हें रोटेट कर सकता है।
एक बार आप स्वामित्व ले लें, CI आपका सुरक्षा नेट बनता है। पहली बार के लिए सरल रखें। हर पुश पर प्रोजेक्ट का बिल्ड, बेसिक चेक्स पास होना, और (यदि हैं) टेस्ट रन होना चाहिए।
CI को एक सवाल का तेज़ जवाब देना चाहिए: "क्या यह परिवर्तन मर्ज करने के लिए सुरक्षित है?" अधिकांश रिपो के लिए इसका मतलब है निर्भरताएँ इंस्टॉल करें, बिल्ड करें, lint चलाएँ, और यूनिट टेस्ट चलाएँ।
ऐप पार्ट के हिसाब से जॉब्स को अलग करें ताकि फेलियर स्पष्ट हों:
कैशिंग का उपयोग करें, पर कैश समस्याएँ छुपाने न दे। जब कैश मिस हो, CI अभी भी काम करना चाहिए, बस धीमा होगा।
हर स्टेप के लिए एक सिंगल कमांड पसंद करें (make test, npm run test, आदि) ताकि वही कमांड लोकल और CI दोनों जगह काम करे। इससे भ्रम कम होता है और लॉग छोटे रहते हैं।
नमूना संरचना (अपने रिपो के अनुसार नाम समायोजित करें):
jobs:
web:
steps:
- run: npm ci
- run: npm run lint
- run: npm run build
api:
steps:
- run: go test ./...
- run: go build ./...
बेसिक्स स्थिर होने के बाद, एक साधारण रिलीज़ फ्लो जोड़ें: रिलीज़ टैग करें, आर्टिफैक्ट बनाएं, और उन्हें CI आर्टिफैक्ट्स के रूप में स्टोर करें। भले ही आप आज भी किसी प्लेटफ़ॉर्म से डिप्लॉय करते हों, रिपीटेबल आर्टिफैक्ट्स होस्ट बदलने में मदद करते हैं।
कोड एक्सपोर्ट करना आधा काम है। दूसरा आधा यह सुनिश्चित करना है कि प्रोजेक्ट प्लेटफ़ॉर्म के बाहर उसी तरह व्यवहार करे।
एक्सपोर्ट अक्सर environment variables, माइग्रेशन्स, seed डेटा, और बिल्ड स्टेप्स पर निर्भर होते हैं जो आपके लिए संभाले गए थे। पहले रन पर खाली स्क्रीन या डेटाबेस एरर सामान्य है।
बेसलाइन रन करें पहले: निर्भरताएँ इंस्टॉल करें, env vars सेट करें, माइग्रेशन्स चलाएँ, और सेवाओं को क्रम से स्टार्ट करें। केवल आवश्यक बदलाव करें ताकि प्रत्याशित सेटअप मैच करे।
सबसे आम दुर्घटना असली API कीज़ या पासवर्ड कमिट करना है, अक्सर .env कॉपी करने या टूल-जनरेटेड कॉन्फ़िग के कारण।
केवल टेम्पलेट कमिट करें। असली वैल्यूज़ लोकल एनवायरनमेंट या सीक्रेट स्टोर में रखें।
पैकेजेस अपडेट करना या फ़ोल्डर तुरंत पुनर्गठित करना यह बताने में मुश्किल बनाता है कि समस्या एक्सपोर्ट की वजह से है या आपकी बदलावों की वजह से।
पहले एक काम करने वाला रन पाएं, फिर छोटे, अलग कमिट्स में सुधार करें।
"मेरी मशीन पर चलता है" अक्सर अनपिन्ड टूल वर्ज़न्स (Node, Go, Flutter, यहां तक कि पैकेज मैनेजर्स) की वजह से होता है।
रनटाइम वर्ज़न्स किसी स्पष्ट जगह पर पिन करें (एक फ़ाइल या README), लॉकफ़ाइल्स रखें (package-lock, go.sum, pubspec.lock), और किसी दूसरी मशीन या फ्रेश कंटेनर पर सेटअप वेरिफाई करें।
हैंडऑफ इसलिए फेल होते हैं क्योंकि कोई भी उस एक अजीब स्टेप को याद नहीं रखता जो ऐप स्टार्ट करने के लिए चाहिए। इसे ताज़ा रहते हुए लिख दें: आवश्यक env vars, माइग्रेशन्स कैसे चलते हैं, लॉग्स कहाँ जाते हैं, और लोकल स्टेट कैसे रीसेट करें।
एक तीन-व्यक्ति की टीम Koder.ai में एक कस्टमर पोर्टल बनाती है: एक React वेब ऐप, एक Go API, और एक PostgreSQL डेटाबेस। जब इसे बाहरी डेवलपर टीम को सौंपने का समय आता है, तो वे चाहते हैं कि एक्सपोर्ट एक सामान्य रिपो जैसा लगे जिसे कोई व्यक्ति पहले दिन चला सके।
Day 1: वे एक्सपोर्ट करते हैं, एक नया Git रिपो बनाते हैं, और लोकली चलाते हैं। फ्रंटेंड चलता है, पर API फेल करता है क्योंकि environment variables गायब हैं। वे अनुमान नहीं लगाते—कोड पढ़ते हैं, उपयोग किए गए सटीक कीज़ पहचानते हैं, और प्लेसहोल्डर्स के साथ .env.example बनाते हैं। असली वैल्यूज़ पासवर्ड मैनेजर और लोकल .env फ़ाइलों में रहती हैं।
वे यह भी नोट करते हैं कि प्लेटफ़ॉर्म पर पोर्ट्स और CORS सेटिंग्स ठीक थीं पर लोकल में डिफ़ॉल्ट चाहिए। वे पूर्वानुमेय डिफ़ॉल्ट्स सेट करते हैं (उदाहरण के लिए, API 8080 पर और वेब 3000 पर) ताकि नई मशीनें समान व्यवहार करें।
Day 2: वे माइग्रेशन्स और एक छोटा सीड स्क्रिप्ट जोड़ते हैं जो एक डेमो यूज़र और कुछ रो बनाती है। फिर वे एक छोटा README लिखते हैं जो प्रीरेक्विज़िट्स, चलाने के कमांड, और यह कैसे वेरिफाई करें बताता है (API के लिए एक हेल्थ endpoint और UI के लिए सैंपल लॉगिन)।
Day 3: वे एक बेसिक CI वर्कफ़्लो जोड़ते हैं जो हर पुल रिक्वेस्ट पर दोनों सर्विसेज के लिए टेस्ट, लिंटिंग, और बिल्ड चलाता है। स्टेजिंग के लिए वे एक सरल योजना डॉक्युमेंट करते हैं: कंटेनर बनाएं, एनवायरनमेंट में सीक्रेट्स सेट करें, डिप्लॉय पर माइग्रेशन्स चलाएँ, और रोलबैक ऑप्शन रखें।
एक अच्छा हेंडऑफ अक्सर ऐसा रिपो शामिल करता है जो फ्रेश क्लोन से लोकली चलता है, .env.example और नोट्स कि सीक्रेट्स कहाँ रहते हैं, माइग्रेशन्स और सीड डेटा, CI चेक्स जो तेज़ी से फेल हों, और स्टेजिंग व रोलबैक के लिए एक छोटा डिप्लॉय नोट।
"डन" कहने से पहले यह साबित करें कि प्रोजेक्ट प्लेटफ़ॉर्म के बाहर भी रह सकता है। अगर कोई और डेवलपर अनुमान लगाए बिना इसे चला सकता है, तो आप अच्छी स्थिति में हैं।
अंतिम चेकलिस्ट:
तकनीकी चेक के बाद, स्वामित्व को स्पष्ट बनाएं। तय करें कि किसका जिम्मा है: निर्भरता अपडेट्स, इन्फ्रास्ट्रक्चर बदलाव (डेटाबेस, कतारें, DNS), और रिलीज़। यदि कोई इनका मालिक नहीं है, तो रिपो धीरे-धीरे खराब होगा भले ही आज ऐप चले।
मुख्य फीचर वर्क से पहले एक छोटा stabilization विंडो योजना बनाएं। आम तौर पर दो से पांच कामकाजी दिन पर्याप्त होते हैं ताकि एक्सपोर्ट की खामियाँ ठीक हो सकें, README कड़ा हो, और "मेरी मशीन पर चलता है" समस्याएँ दूर हो सकें।
यदि आप Koder.ai (Koder.ai) का उपयोग कर रहे हैं, तो एक्सपोर्ट्स के साथ snapshots और rollback जैसी विशेषताएँ यह आसान बनाती हैं कि आप रिपो कड़ाई से तैयार करते हुए भी इटरेट करें। एक बार रिपो स्टेबल हो जाए, Git को स्रोत माने और भविष्य के एक्सपोर्ट्स को मुख्य इतिहास न बल्कि चेकपॉइंट ही मानें।
सादा भाषा में अगला हेंडऑफ माइलस्टोन परिभाषित करें: "कोई भी डेवलपर इसे 30 मिनट में चला सके।" फिर किसी नए व्यक्ति से इसे ताज़ा मशीन पर README फॉलो कर के करवाएँ। उनके सवाल आपकी अंतिम टु-डू सूची बन जाएंगे।
स्वामित्व को स्वतंत्रता के रूप में मानें: आप सामान्य रिपो से ऐप को build, run, change, और deploy कर सकते हैं बिना मूल प्लेटफ़ॉर्म प्रोजेक्ट, विशेष UI सेटिंग्स, या छिपे हुए बिल्ड स्टेप्स की ज़रूरत के।
एक अच्छा टेस्ट है: क्या कोई नया teammate सिर्फ README देखकर रिपो क्लोन करके इसे रन कर सकता है?
एक त्वरित पूर्णता चेक से शुरू करें:
package.json, go.mod, pubspec.yaml).package-lock.json, yarn.lock, pnpm-lock.yaml, go.sum).migrations/ या समान)।docker-compose.yml).यदि कोई जरूरी चीज़ केवल UI या चैट में बताई गई है, तो उसे लिखें और रिपो में ले आएँ।
छोटे, सत्यापनीय स्टेप्स में करें:
.env.example → .env करके लोकल कॉन्फ़िग सेट करें।तुरंत रीफैक्टर न करें—पहले यह साबित करें कि यह ज्यों का त्यों चलता है, फिर अलग कमिट्स में सुधार करें।
क्योंकि होस्टेड वातावरण में अक्सर ऐसी चीज़ें पहले से सेट होती हैं जो आपने स्पष्ट नहीं कीं:
इन्हें ठीक करने के लिए सेटअप को स्पष्ट बनाइए: .env.example, माइग्रेशन स्क्रिप्ट, और README में सटीक कमांड।
सर्वर का स्टार्ट होना ही काफी नहीं—वास्तविक डेटा फ्लो की पुष्टि करें:
यदि आप लोकल पर डेटा बदलाव भरोसेमंद तरीके से दोहरा नहीं पाते, तो आपका सेटअप या माइग्रेशन्स अधूरे हैं।
डिफ़ॉल्ट तरीका:
.env.example में फेक वैल्यूज़ कमिट करें।.env को .gitignore में डालें।यदि आपको रिपो में असली कीज़ मिलें, तो मान लें वे एक्सपोज़ हो चुके हैं और उन्हें रोटेट करें। प्राथमिकता दें: डेटाबेस क्रेडेंशियल्स, OAuth क्लाइंट सीक्रेट्स, और webhook साइनिंग कीज़।
पहली CI बहुत छोटी और स्थानीय कमांड्स से मेल खानी चाहिए:
go test ./... और build।CI वही स्क्रिप्ट कॉल करे जो डेवलपर्स लोकल में चलाएँगे (जैसे make test या npm run build)—इससे “लोकल पर चलता है पर CI में नहीं” जैसी समस्याएँ कम होंगी।
हाँ—भले ही ऐप चल रहा हो, predictable handoff के लिए दस्तावेज़ ज़रूरी है। एक अच्छा डिफ़ॉल्ट सेट:
README.md जिसमें copy-paste कमांड हों।.env.example जो आवश्यक बनाम वैकल्पिक वेरिएबल्स बताए।लक्ष्य रखें कि नया डेवलपर 15–30 मिनट में बिना अंदाज़े के ऐप चला सके।
सामान्य संरचना:
apps/ फ्रंटएंड्स के लिए (web, mobile)।services/ APIs और workers के लिए।shared/ साझा प्रकार/यूटिलिटीज के लिए।infra/ डिप्लॉयमेंट टेम्प्लेट और पर्यावरण उदाहरणों के लिए।नाम उतने महत्वपूर्ण नहीं जितना यह स्पष्ट करना कि क्या कहाँ चलता है और हिस्से कैसे जुड़ते हैं।
एक व्यवहारिक क्रम:
स्थिर होने पर Git को स्रोत माना जाए और भविष्य के प्लेटफ़ॉर्म एक्सपोर्ट्स को केवल चेकपॉइंट की तरह रखें, मुख्य इतिहास नहीं।