10 ਦਸੰ 2025·7 ਮਿੰਟ

vibe-coding ਪਲੇਟਫਾਰਮ ਤੋਂ ਸੋਰਸ ਕੋਡ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਨਿਰਯਾਤ ਕਰੋ

Q: “Taking ownership” ਦਾ ਅਸਲ ਮਤਲਬ ਐਕਸਪੋਰਟ ਤੋਂ ਬਾਅਦ ਕੀ ਹੈ?

Treat ownership as independence : you can build, run, change, and deploy the app from a normal repo without needing the original platform project, special UI settings, or hidden build steps. A good test is: can a new teammate clone the repo and get it running using only the README?

Q: ਐਕਸਪੋਰਟ ਪੂਰਾ ਹੈ ਜਾਂ ਨਹੀਂ ਇਹ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਚੈੱਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?

Start with a quick completeness check: - Find each app “root” ( , , ). - Confirm there’s a lockfile ( , , , ). - Look for database migrations ( or similar). - Check for a runnable workflow (README, Makefile, scripts, or ). If anything required to run is only described in a UI or chat, write it down and move it into the repo.

Q: ਐਕਸਪੋਰਟ ਕੀਤੀ ਪਰੋਜੈਕਟ ਨੂੰ ਲੋਕਲ ਤੇ ਚਲਾਉਣ ਦਾ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕਾ ਕੀ ਹੈ?

Do it in small, verifiable steps: 1. Initialize Git and commit the raw export (baseline). 2. Set up local config using → . 3. Start the database. 4. Run migrations. 5. Start the backend. 6. Start the frontend. Don’t refactor immediately—first prove it runs as-is, then improve it in separate commits.

Q: ਐਕਸਪੋਰਟ ਤੋਂ ਬਾਅਦ ਡੇਟਾਬੇਸ ਹਿੱਸੇ ਨੂੰ ਕਿਵੇਂ ਪੱਕਾ ਕੀਤਾ ਜਾਵੇ?

A server “starting” isn’t enough—verify real data flow: - Load a page that clearly depends on database reads. - Create a record, refresh, and confirm it persisted. - Do one update and one delete if possible. - Watch logs for migration issues like “relation does not exist.” If you can’t reliably reproduce data changes locally, your setup or migrations are incomplete.

Q: ਮੈਂ Git ਵਿੱਚ API keys ਜਾਂ ਹੋਰ ਸੀਕ੍ਰੇਟ ਸਾਂਝੇ ਨਾ ਕਰਨ ਲਈ ਕਿਵੇਂ ਸੰਭਾਲਾਂ?

Default approach: - Commit with fake values. - Add to . - Store real secrets in a password manager or a secret store. If you find real keys in the repo, assume they’re compromised and rotate them. Prioritize database credentials, OAuth client secrets, and webhook signing secrets.

Q: ਜੇ ਐਪ ਪਹਿਲਾਂ ਹੀ ਚੱਲਦਾ ਹੈ ਤਾਂ ਕੀ ਮੈਨੂੰ README ਅਤੇ bootstrap script ਦੀ ਲੋੜ ਹੈ?

Yes—if you want a predictable handoff. A good default is: - A single top-level with copy-paste commands. - A describing required vs optional variables. - One bootstrap command/script to install deps and prepare the DB. Aim for a new developer being able to run the app in 15–30 minutes without guessing.

Q: ਵੈੱਬ + API + ਡੇਟਾਬੇਸ ਵਾਲੇ ਐਕਸਪੋਰਟ ਰਿਪੋ ਨੂੰ ਕਿਵੇਂ ਠੀਕ ਢੰਗ ਨਾਲ ਸੋਧਿਆ ਜਾਵੇ?

Common structure is: - for frontends (web, mobile). - for APIs and workers. - for shared types/utilities. - for deployment templates and environment examples. The exact names don’t matter as much as making it obvious what runs where, and how the pieces connect.

Q: Koder.ai ਤੋਂ ਐਕਸਪੋਰਟ ਕਰਨ ਤੋਂ ਬਾਅਦ ਅਗਲੇ ਕਦਮ ਕੀ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ?

A practical sequence: 1. Export and commit the baseline. 2. Make it run locally with explicit config, migrations, and a clear README. 3. Add CI to keep builds and tests from silently breaking. 4. Add a simple deploy note (how to set secrets, run migrations, rollback). Once stable, treat Git as the source of truth and any future platform exports as checkpoints, not the primary history.

ਸਿੱਖੋ ਕਿ vibe-coding ਪਲੇਟਫਾਰਮ ਤੋਂ ਸੋਰਸ ਕੋਡ ਕਿਵੇਂ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਨਿਰਯਾਤ ਕਰਨਾ ਹੈ ਅਤੇ ਕਿਵੇਂ ਮਾਲਕੀਅਤ ਲੈਣੀ ਹੈ: ਲੋਕਲ ਤੇ ਚਲਾਉਣਾ, CI ਸੈਟਅਪ, ਸੀਕ੍ਰੇਟਸ ਸੰਭਾਲਣਾ, ਅਤੇ handoff-ਤਿਆਰ ਰਿਪੋ ਤਿਆਰ ਕਰਨਾ।

ਨਿਰਯਾਤ ਤੋਂ ਬਾਅਦ ਮਲਕੀਅਤ ਲੈਣ ਦਾ ਕੀ ਮਤਲਬ ਹੈ

कोਡ ਦਾ ਮਾਲਕ ਹੋਣਾ ਸਿਰਫ਼ ਪਲੇਟਫਾਰਮ ਤੋਂ ਇਕ zip ਫਾਈਲ ਮਿਲਣ ਦਾ ਮਤਲਬ ਨਹੀਂ। ਇਸਦਾ ਅਰਥ ਹੈ ਕਿ ਤੁਸੀਂ ਬਿਨਾਂ ਮੁਢਲੇ ਵਰਕਸਪੇਸ, ਖਾਸ ਬਟਨਾਂ ਜਾਂ ਛੁਪੇ ਸੈਟਿੰਗਾਂ ਦੀ ਲੋੜ ਦੇ, ਐਪ ਨੂੰ ਬਣਾਉਣ, ਚਲਾਉਣ, ਬਦਲਣ ਅਤੇ ਸ਼ਿਪ ਕਰਨ ਯੋਗ ਹੋ। ਇਕ ਪ੍ਰੋਜੈਕਟ ਜੋ ਤੁਸੀਂ ਵਾਸਤਵਿਕ ਤੌਰ 'ਤੇ ਮਾਲਕ ਹੋ, ਉਹ ਕਿਸੇ ਸਧਾਰਣ ਰਿਪੋ ਵਰਗ ਵਰਤਦਾ ਹੈ: ਨਵਾਂ ਟੀਮਮੈਟ ਕਲੋਨ ਕਰ ਸਕਦਾ ਹੈ, ਆਪਣੀ ਮਸ਼ੀਨ 'ਤੇ ਚਾਲੂ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਇੱਕ ਮਿਆਰੀ ਪਾਈਪਲਾਈਨ ਰਾਹੀਂ ਡਿਪਲੌਯ ਕਰ ਸਕਦਾ ਹੈ।

ਜ਼ਿਆਦਾਤਰ lock-in ਦੀ ਚਿੰਤਾ ਉਹਨਾਂ ਥੋੜ੍ਹੀਆਂ ਗੱਲਾਂ ਤੋਂ ਹੁੰਦੀ ਹੈ:

ਸੋਧ ਜਿਹੜੀ ਸਿਰਫ਼ ਪਲੇਟਫਾਰਮ UI ਵਿੱਚ ਮੌਜੂਦ ਹੁੰਦੀ ਹੈ
ਬਨਾਉਣ ਵਾਲੇ ਕਦਮ ਜੋ "ਕਿੱਥੇ ਹੋਰ" ਹੋ ਰਹੇ ਹੁੰਦੇ ਹਨ
ਡਿਪੇਂਡੈਂਸੀਜ਼ ਜੋ ਮੰਨੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਪਰ ਲਿਖੀਆਂ ਨਹੀਂ ਹੁੰਦੀਆਂ

ਹੋਰ ਆਮ ਹੈਰਾਨੀ ਇਹ ਹੁੰਦੀ ਹੈ ਕਿ ਹੋਸਟ ਕੀਤੇ ਵਰਜਨ ਤੇ ਐਪ ਠੀਕ ਚੱਲਦਾ ਹੋਵੇ ਪਰ ਲੋਕਲ ਤੇ ਫੇਲ ਹੋ ਜਾਵੇ ਕਿਉਂਕਿ ਵਾਤਾਵਰਣ ਵੇਰਵਿਆਂ, ਡੇਟਾਬੇਸ ਸੈਟਅਪ ਜਾਂ ਸੀਕ੍ਰੇਟਸ ਨੂੰ ਕਦੇ ਖੁਲਾਸਾ ਨਹੀਂ ਕੀਤਾ ਗਿਆ।

vibe-coding ਪਲੇਟਫਾਰਮ ਤੋਂ ਇੱਕ ਸਾਫ਼ ਐਕਸਪੋਰਟ ਚਾਰ ਨਤੀਜੇ ਦੇਣੇ ਚਾਹੀਦੇ ਹਨ:

ਤੁਸੀਂ ਨਿਰਯਾਤ ਕੀਤਾ ਐਪ ਲੋਕਲ ਤੇ ਪੂਰਨ ਤਰੀਕੇ ਨਾਲ ਚਲਾ ਸਕਦੇ ਹੋ।
ਤੁਸੀਂ ਆਪਣੇ ਰਿਪੋ ਤੋਂ CI ਰਾਹੀਂ ਡਿਪਲੌਯ ਕਰ ਸਕਦੇ ਹੋ, ਨਾ ਕਿ ਮੈਨੂਅਲ ਕਲਿੱਕਸ ਨਾਲ।
ਸੀਕ੍ਰੇਟਸ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲੇ ਜਾਂਦੇ ਹਨ (ਗਿੱਟ ਵਿੱਚ ਕੋਈ ਕੀ ਨਹੀਂ, ਅਨੁਮਾਨ ਨਹੀਂ)।
ਰਿਪੋ ਹandoff-ਤਿਆਰ ਹੈ, ਤਾਂ ਜੋ ਨਵਾਂ ਵਿਅਕਤੀ ਤੇਜ਼ੀ ਨਾਲ onboard ਹੋ ਸਕੇ ਅਤੇ ਜੋ ਉਹ ਵੇਖੇ ਉਸ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕੇ।

ਇਹ ਗੱਲ ਮਹੱਤਵਪੂਰਨ ਹੈ ਭਾਵੇਂ ਤੁਸੀਂ ਕਦੇ ਪਲੇਟਫਾਰਮ ਛੱਡਣ ਦਾ ਸੋਚਦੇ ਹੀ ਨਾ ਹੋਵੋ। ਵਧੀਆ ਮਾਲਕੀਅਤ ਇੱਕ ਬੀਮਾ ਹੈ: ਇਹ ਖ਼ਤਰਾ ਘਟਾਉਂਦੀ ਹੈ, ਆਡਿਟਸ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੀ ਹੈ, ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਏਜੰਸੀ ਨੌਕਰੀ 'ਤੇ ਲੈਓ, ਫੰਡ ਰੇਜ ਕਰਦੇ ਹੋ ਜਾਂ ਟੀਮ ਬਦਲਦੇ ਹੋ ਤਾਂ ਨੇਗੋਸ਼ੀਏਸ਼ਨ ਸਧਾਰਨ ਰਹਿੰਦੇ ਹਨ।

ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤੀ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਐਕਸਪੋਰਟ ਵਿੱਚ ਆਮ ਸਟੈਕ ਮਿਲ ਸਕਦੇ ਹਨ ਜਿਵੇਂ ਕਿ React ਵੈੱਬ ਐਪ, Go ਬੈਕਐਂਡ, PostgreSQL, ਜਾਂ Flutter ਮੋਬਾਈਲ ਐਪ। ਸਟੈਕ ਤੋਂ ਵੱਧ ਲੋੜੀਨੁਮਾ ਗੱਲ ਇਹ ਹੈ: ਚੱਲਾਉਣ ਲਈ ਜ਼ਰੂਰੀ ਹਰ ਚੀਜ਼ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਦਿੱਖਣੀ ਚਾਹੀਦੀ ਹੈ, ਹੋਸਟ ਕੀਤੇ ਵਾਤਾਵਰਣ ਵਿੱਚ ਫੈਸਲਾ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ।

ਇੱਕ ਫਾਊਂਡਰ ਨੂੰ ਸੋਚੋ ਜੋ ਐਪ ਇੱਕ ٹھੇਕੇਦਾਰ ਨੂੰ ਦੇ ਰਿਹਾ ਹੈ। "ਇੱਥੇ ਰਿਪੋ ਹੈ" ਕਹਿਣਾ ਕਾਫ਼ੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ٹھੇਕੇਦਾਰ ਨੂੰ ਮੁਢਲੇ ਪਲੇਟਫਾਰਮ ਪ੍ਰੋਜੈਕਟ ਤੱਕ ਪਹੁੰਚ ਦੀ ਲੋੜ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ ਕਿ API ਬੇਸ URL ਲੱਭਣ, ਡੇਟਾਬੇਸ ਸਕੀਮਾ ਬਣਾਉਣ ਜਾਂ ਫਰੰਟਐਂਡ ਕਿਵੇਂ ਬਣਦਾ ਹੈ ਸਮਝਣ ਲਈ।

ਨਿਰਯਾਤ ਕੀਤੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਤੁਹਾਨੂੰ ਕੀ ਉਮੀਦ ਰੱਖਣੀ ਚਾਹੀਦੀ ਹੈ

ਐਕਸਪੋਰਟ ਤੋਂ ਬਾਅਦ, ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਆਮ ਰਿਪੋ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਐਡੀਟਰ ਵਿੱਚ ਖੋਲ੍ਹ ਸਕੋ, ਆਪਣੀ ਲੈਪਟੌਪ 'ਤੇ ਚਲਾ ਸਕੋ, ਅਤੇ ਮੁੜ-ਹਾਦੀ ਵਿੱਚ ਕਿਸੇ ਹੋਰ ਟੀਮ ਨੂੰ ਦੇ ਸਕੋ ਬਿਨਾਂ ਮੁਢਲੇ ਪਲੇਟਫਾਰਮ ਦੀ ਲੋੜ ਦੇ।

Koder.ai ਪ੍ਰੋਜੈਕਟਾਂ ਨਾਲ, ਐਕਸਪੋਰਟ ਆਮ ਤੌਰ 'ਤੇ ਜਾਣ-ਪਛਾਣ ਵਾਲੇ ਸਰੂਪਾਂ ਵਿੱਚ ਆਉਂਦੇ ਹਨ: ਇੱਕ React ਵੈੱਬ ਐਪ, ਇੱਕ Go ਬੈਕਐਂਡ, ਅਤੇ (ਜੇ ਤੁਸੀਂ ਬਣਾਇਆ) ਇੱਕ Flutter ਮੋਬਾਈਲ ਐਪ। ਫੋਲਡਰਾਂ ਦੇ ਨਾਮ ਵੱਖ-ਵੱਖ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਰਿਪੋ ਨੂੰ ਇਹ ਸਪੱਸ਼ਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਹਰ ਹਿੱਸਾ ਕਿੱਥੇ ਹੈ ਅਤੇ ਉਹ ਕਿਵੇਂ ਜੁੜਦੇ ਹਨ।

ਪ੍ਰੋਜੈਕਟ ਦੀ ਸ਼ਕਲ: ਫੋਲਡਰ, ਐਂਟਰੀ ਪੌਇੰਟ ਅਤੇ ਕੀ ਕਿਹੜਾ ਚਲਾਂਦਾ ਹੈ

ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਐਂਟਰੀ ਪੌਇੰਟ ਅਤੇ ਮਨਜ਼ੂਰ ਕੀਤੀ ਵਰਕਫਲੋ ਲੱਭੋ। ਤੁਹਾਨੂੰ ਹਰ ਐਪ ਫਾਈਲ ਦੀ ਉਹ ਫਾਈਲ ਚਾਹੀਦੀ ਹੈ ਜੋ ਐਪ ਨੂੰ ਬੂਟ ਕਰਦੀ ਹੈ, ਅਤੇ ਉਹ ਸਕ੍ਰਿਪਟਸ ਜਿਹੜੇ ਦੱਸਦੇ ਹਨ ਕਿ ਵਿਕਾਸ ਅਤੇ ਚਲਾਣ ਦਾ ਤਰੀਕਾ ਕੀ ਹੈ।

ਆਮ ਨਿਸ਼ਾਨ:

ਵੈੱਬ: package.json ਨਾਲ ਇੱਕ src/ ਫੋਲਡਰ (ਅਕਸਰ main.tsx ਜਾਂ ਸਮਾਨ)
ਬੈਕਐਂਡ: go.mod ਅਤੇ cmd/ ਫੋਲਡਰ ਜਾਂ main.go
ਮੋਬਾਈਲ: Flutter ਦੀ pubspec.yaml ਅਤੇ lib/main.dart
ਇੱਕ ਟੌਪ-ਲੇਵਲ README ਜਾਂ Makefile ਜੋ ਦੱਸਦਾ ਹੈ ਕਿ ਸਭ ਕੁਝ ਕਿਵੇਂ ਚਲਾਉਣਾ ਹੈ
ਜੇ ਐਕਸਪੋਰਟ ਸੇਵਾਵਾਂ ਦੇ ਸਮੁੱਚੇ ਵਜੋਂ ਚਲਾਉਣ ਲਈ ਹੈ ਤਾਂ docker-compose.yml

ਡਿਪੈਂਡੈਂਸੀਜ਼, ਕਨਫਿਗਰੇਸ਼ਨ ਅਤੇ ਡੇਟਾਬੇਸ ਹਿੱਸੇ

ਡਿਪੈਂਡੈਂਸੀਜ਼ pinned ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। JavaScript ਲਈ, ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕੋਈ lockfile موجود ਹੋਵੇ (package-lock.json, yarn.lock, ਜਾਂ pnpm-lock.yaml)। Go ਲਈ, go.mod ਅਤੇ go.sum ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। pinned ਨਾ ਹੋਣ ਨਾਲ ਪ੍ਰੋਜੈਕਟ ਅਸੰਭਵ ਨਹੀਂ ਬਣਦਾ, ਪਰ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ builds ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦੇ ਹਨ।

ਕਨਫਿਗਰੇਸ਼ਨ ਕੋਡ ਤੋਂ ਅਲੱਗ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। .env.example ਜਾਂ config.example.yaml ਵਰਗੀਆਂ ਉਦਾਹਰਣਾਂ ਲਈ ਤਲਾਸ਼ ਕਰੋ। ਤੁਸੀਂ ਅਸਲੀ ਸੀਕ੍ਰੇਟਸ (API key, ਪ੍ਰੋਡੈਕਸ਼ਨ ਪਾਸਵਰਡ) ਕਦੇ ਵੀ export ਵਿੱਚ commit ਨਹੀਂ ਦੇਖਣਾ ਚਾਹੀਦਾ। ਜੇ ਤੁਸੀਂ ਦੇਖੋ, ਤਾਂ ਉਸਨੂੰ ਲੀਕ ਸਮਝੋ ਅਤੇ ਰੋਟੇਟ ਕਰੋ।

ਡੇਟਾਬੇਸ ਲਈ, migrations ਫੋਲਡਰ ਲੱਭੋ (migrations/, db/migrations/) ਜਾਂ ਟਾਈਮਸਟੈਂਪ ਵਾਲੀਆਂ SQL ਫਾਈਲਾਂ। Go + PostgreSQL ਐਪ ਵਿੱਚ ਤੁਸੀਂ ਇੱਕ ਛੋਟਾ migration runner ਜਾਂ script ਵੀ ਵੇਖ ਸਕਦੇ ਹੋ ਜੋ migrations ਲਗਾਉਂਦਾ ਹੈ।

ਇੱਕ ਤੇਜ਼ sanity ਚੈੱਕ: build ਅਤੇ run commands ਪਹਿਲਾਂ ਲੱਭੋ (npm run dev, go run, make ਆਦਿ)। ਜੇ ਕੋਈ ਸਕ੍ਰਿਪਟ ਪਲੇਟਫਾਰਮ-ਖਾਸ ਕਮਾਂਡ ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਰਿਪੋ ਨੂੰ ਸਵਤੰਤਰ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਉਸਨੂੰ ਸਧਾਰਨ ਟੂਲਿੰਗ ਨਾਲ ਬਦਲੋ।

ਕਦਮ ਦਰ ਕਦਮ: ਨਿਰਯਾਤ, commit ਅਤੇ ਲੋਕਲ ਤੇ ਚਲਾਉਣਾ

ਐਕਸਪੋਰਟ ਨੂੰ ਇੱਕ release artifact ਵਾਂਗ ਸਮਝੋ। ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ ਛੋਟੀ "ਕੀ ਸਭ ਇੱਥੇ ਹੈ?" ਜਾਂਚ ਕਰੋ। ਜਦੋਂ ਤੁਸੀਂ ਬਦਲਾਅ ਕਰਨ ਨੂੰ ਸ਼ੁਰੂ ਕਰੋਗੇ ਤਾਂ ਗੁੰਮ ਹੋਏ ਹਿੱਸੇ ਫੜਨਾ ਮੁਸ਼ਕਲ ਹੋਵੇਗਾ।

ਇੱਕ ਵਿਹਾਰਕ completeness ਚੈੱਕ ਇਹ ਹੈ ਕਿ ਹਰ ਹਿੱਸੇ ਦੇ "root" ਲੱਭੋ: React ਵੈੱਬ ਐਪ ਲਈ package.json, Go ਬੈਕਐਂਡ ਲਈ go.mod, ਅਤੇ PostgreSQL ਲਈ migration/seed ਫਾਈਲਾਂ।

ਇੱਕ ਸਾਫ਼ ਪਹਿਲਾ commit (ਤਾਂ ਜੋ ਇਤਿਹਾਸ ਪੜ੍ਹਨਯੋਗ ਰਹੇ)

Export ਕੀਤੇ ਫੋਲਡਰ ਤੋਂ ਇੱਕ ਨਵਾਂ Git ਰਿਪੋ ਬਣਾਓ, ਫਿਰ ਉਸ ਵਿੱਚ ਜੋ ਕੁਝ ਮਿਲਿਆ ਉਹੀ ਬਿਨਾਂ ਬਦਲਾਅ commit ਕਰੋ। ਇਹ ਤੁਹਾਨੂੰ ਇੱਕ ਸਾਫ਼ ਬੇਸਲਾਈਨ ਦਿੰਦਾ ਹੈ ਅਤੇ ਬਾਅਦ ਵਾਲੇ ਬਦਲਾਅ ਆਸਾਨੀ ਨਾਲ ਰਿਵਿਊ ਹੋ ਸਕਦੇ ਹਨ।

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

ਡੇਟਾਬੇਸ ਨੂੰ ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੋਇਆ ਪੱਕਾ ਕਰੋ (ਸਿਰਫ਼ "server started" ਨਹੀਂ)

ਇੱਕ ਸਰਵਰ ਬੂਟ ਹੋ ਸਕਦਾ ਹੈ ਪਰ ਐਪ ਫ਼ਿਰ ਵੀ ਟੁੱਟੀ ਹੋ ਸਕਦੀ ਹੈ। ਪੱਕਾ ਕਰੋ ਕਿ ਇਹ ਪੜ੍ਹ ਅਤੇ ਲਿਖ ਦੋਹਾਂ ਕਰ ਸਕਦਾ ਹੈ।

ਛੋਟੀਆਂ ਜਾਂਚਾਂ ਚੁਣੋ ਜੋ ਉਤਪਾਦ ਨਾਲ ਮਿਲਦੀਆਂ हों:

ਕਿਸੇ ਪੇਜ ਨੂੰ ਖੋਲ੍ਹੋ ਜੋ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਡੇਟਾ 'ਤੇ ਨਿਰਭਰ ਹੋਵੇ (ਸੂਚੀ, پروਫਾਈਲ, ਡੈਸ਼ਬੋਰਡ)।
ਇੱਕ ਰਿਕਾਰਡ ਬਣਾਓ (ਸਾਈਨਅਪ, ਆਈਟਮ ਬਣਾਉ, ਨੋਟ ਜੋੜੋ), ਰੀਫ੍ਰੈਸ਼ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇਹ ਸੰਭਾਲਿਆ ਗਿਆ।
ਇਕ ਅਪਡੇਟ ਅਤੇ ਇਕ ਡਿਲੀਟ ਟ੍ਰਾਈ ਕਰੋ ਜੇ UI ਸਹਾਇਤਾ ਕਰਦਾ ਹੋਵੇ।
ਲੋਗਜ਼ 'ਚ ਮਾਈਗ੍ਰੇਸ਼ਨ ਐਰਰ ਜਾਂ "relation does not exist" ਦੇਖੋ।

ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਲੋਕਲ ਤੇ ਇੱਕ ਕੰਮ ਕਰਨ ਵਾਲੀ ਰਨ ਹੋਵੇ, ਆਪਣੇ scratch ਨੋਟਸ ਨੂੰ ਇੱਕ ਅਸਲੀ README.md ਵਿੱਚ ਬਦਲ ਦਿਓ: ਕਿੱਥੇ ਕਮਾਂਡ ਦੌੜਾਉਣੀਆਂ ਹਨ, ਸੇਵਾਵਾਂ ਦਰਜ ਕਰਨ ਦਾ ਆਰਡਰ, ਅਤੇ ਕਿਹੜੇ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਲਾਜ਼ਮੀ ਹਨ।

ਨਿਰਯਾਤ ਨੂੰ ਹandoff-ਤਿਆਰ ਰਿਪੋ ਵਿੱਚ ਬਦਲੋ

ਇਕਸਪੋਰਟ ਚੱਲ ਸਕਦੀ ਹੈ, ਪਰ ਫਿਰ ਵੀ "generated" ਜਿਹਾ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ ਨਾ ਕਿ ਮਾਲਕੀਅਤ ਵਾਲਾ। ਇੱਕ handoff-ਤਿਆਰ ਰਿਪੋ ਦੇ ਨਾਲ ਇਹ ਸਪਸ਼ਟ ਹੁੰਦਾ ਹੈ ਕਿ ਚੀਜ਼ਾਂ ਕਿੱਥੇ ਹਨ, ਕਿਵੇਂ ਚਲਾਉਣਾ ਹੈ, ਅਤੇ ਕਿਵੇਂ ਉਹ consistent ਰੱਖਣੀਆਂ ਹਨ।

ਟੌਪ-ਲੇਵਲ ਲੇਆਉਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਨਾਮ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ, ਲਗਾਤਾਰਤਾ ਮਹੱਤਵਪੂਰਨ ਹੈ।

apps/ ਯੂਜ਼ਰ-ਫੇਸਿੰਗ ਫਰੰਟਐਂਡ (web, mobile) ਲਈ
services/ ਬੈਕਐਂਡ APIs, ਵర్కਰز, ਅਤੇ ਜਾਬਜ਼ ਲਈ
shared/ ਸ਼ੇਅਰ ਕੀਤੇ ਟਾਈਪਸ ਅਤੇ ਯੂਟਿਲਿਟੀਜ਼ ਲਈ
infra/ ਡਿਪਲੌయਮੈਂਟ ਟੈਂਪਲੇਟ, ਸਕ੍ਰਿਪਟ ਅਤੇ ਵਾਤਾਵਰਣ ਉਦਾਹਰਣਾਂ ਲਈ
docs/ ਆਰਕੀਟੈਕਚਰ ਨੋਟਸ ਅਤੇ ਰਨਬੁੱਕਸ ਲਈ

ਫਿਰ ਕੁਝ ਛੋਟੀ ਫਾਈਲਾਂ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਅਨਿਸ਼ਚਿਤਤਾ ਘਟਾਉਂਦੀਆਂ ਹਨ:

README.md ਪ੍ਰਿਰਕੀਜੀ ਅਤੇ ਸਹੀ ਕਮਾਂਡਸ ਨਾਲ
CONTRIBUTING.md ਕੁਝ ਨਿਯਮਾਂ ਨਾਲ (ਬ੍ਰਾਂਚ, PRs, ਕੋਈ ਸੀਕ੍ਰੇਟ ਨਹੀ)
.gitignore ਲੋਕਲ env ਫਾਈਲਾਂ ਅਤੇ ਬਿਲਡ ਆਉਟਪੁੱਟ ਗਿੱਟ ਤੋਂ ਬਾਹਰ ਰੱਖਣ ਲਈ

README ਨੂੰ ਵਰਤਣ ਯੋਗ ਰੱਖੋ। ਜੇ ਰਿਪੋ ਵਿੱਚ ਕਈ ਹਿੱਸੇ ਹਨ (React ਫਰੰਟਐਂਡ, Go API, PostgreSQL), ਤਦ ਉਨ੍ਹਾਂ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਦੇ ਆਰਡਰ ਅਤੇ ਕਿੱਥੇ ਕਨਫਿਗ ਰਹਿੰਦੀ ਹੈ (ਉਦਾਹਰਣ ਵਜੋਂ, ".env.example ਨੂੰ .env ਵਿੱਚ ਕਾਪੀ ਕਰੋ") ਸਪਸ਼ਟ ਲਿਖੋ।

ਇੱਕ ਨਵੀਂ ਮਸ਼ੀਨ 'ਤੇ ਕੰਮ ਚੈੱਕ ਕਰੋ: ਨਵਾਂ ਫੋਲਡਰ ਬਣਾਕੇ ਕਲੋਨ ਕਰੋ ਅਤੇ ਆਪਣੀ README ਫੋਲੋ ਕਰੋ। ਜੇ ਤੁਸੀਂ Koder.ai ਤੋਂ export ਕੀਤੀ ਸੀ, ਤਦ export ਨੂੰ ਨਵੀਂ ਸੁਤੰਤਰ ਪ੍ਰੋਜੈਕਟ ਦੇ ਸ਼ੁਰੂਆਤੀ commit ਵਜੋਂ ਲਓ ਅਤੇ ਫਿਰ ਹੀ ਦੂਜਿਆਂ ਨੂੰ ਸ਼ਾਮਿਲ ਕਰੋ।

ਲੋਕਲ ਵਿਕਾਸ ਸੈਟਅਪ ਜੋ ਨਵੇਂ ਲੋਕ ਫੋਲੋ ਕਰ ਸਕਣ

Spin up a familiar stack

Generate a React, Go, and PostgreSQL starter you can run locally on day one.

Create Project

ਛੇਤੀ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਇੱਕ ਚੰਗਾ ਲੋਕਲ ਸੈਟਅਪ ਇਹ ਸਵਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਕੀ ਨਵਾਂ ਵਿਅਕਤੀ 15 ਮਿੰਟ ਵਿੱਚ ਬਿਨਾਂ ਅਨੁਮਾਨ ਲਗਾਉਣ ਦੇ ਐਪ ਚਲਾ ਸਕਦਾ ਹੈ?

ਇੱਕ ਡਿਫਾਲਟ ਲੋਕਲ ਅਪ੍ਰੋਚ ਚੁਣੋ ਅਤੇ ਸਪਸ਼ਟ ਹੋਵੋ। ਨੈਟਿਵ ਇੰਸਟਾਲ ਤੇਜ਼ ਹੁੰਦੇ ਹਨ ਜਿਹੜੇ ਲੋਕ ਪਹਿਲਾਂ ਹੀ ਸੰਦ ਰੱਖਦੇ ਹਨ। ਕੰਟੇਨਰਜ਼ ਹਰੇਕ ਮਸ਼ੀਨ 'ਤੇ ਇੱਕਸਾਰ ਹਨ ਪਰ ਥੋੜ੍ਹਾ ਜ਼ਿਆਦਾ ਓਵਰਹੈਡ ਲਿਆਉਂਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਦੋਹਾਂ ਸਹਿਯੋਗ ਕਰਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਨੂੰ ਡਿਫਾਲਟ ਅਤੇ ਦੂਜੇ ਨੂੰ ਵਿਕਲਪ ਤੌਰ 'ਤੇ ਨਿਸ਼ਾਨ ਲਗਾਓ।

ਇੱਕ ਸਧਾਰਣ ਪੈਟਰਨ ਜੋ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ: ਇੱਕ README ਪੰਨਾ, ਇੱਕ ਨਮੂਨਾ env ਫਾਈਲ, ਅਤੇ ਇੱਕ bootstrap ਕਮਾਂਡ।

ਇੱਕ ਨਿਯੂਨਤਮ, ਸੁਰੱਖਿਅਤ env ਸੈਟਅਪ

ਨਮੂਨੇ ਵਾਲੀ ਫਾਈਲ commit ਕਰੋ ਜਿਸ ਵਿੱਚ ਨਕਲੀਆਂ ਕੁੱਲਮਾਂ ਹਨ ਤਾਂ ਜੋ ਲੋਕ ਜਾਣ ਸਕਣ ਕਿ ਕੀ ਭਰਣਾ ਹੈ ਬਿਨਾਂ ਸੀਕ੍ਰੇਟ ਲੀਕ ਕੀਤੇ।

# .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 ਵਿੱਚ ਕਾਪੀ ਕਰੋ") ਅਤੇ ਕਿਹੜੇ ਵੇਰੀਏਬਲ ਲਾਜ਼ਮੀ ਹਨ ਤੇ ਕਿਹੜੇ ਵਿਕਲਪਿਕ।

ਇੱਕ ਕਮਾਂਡ bootstrap ਕਰਨ ਲਈ

ਇੱਕ ਛੋਟਾ ਸਕ੍ਰਿਪਟ ਜੋ ਸਾਰੀਆਂ ਨਿਰਾਸ਼ਾਜਨਕ ਕਦਮਾਂ ਨੂੰ ਸਹੀ ਆਰਡਰ ਵਿੱਚ ਦੌੜਾਏ ਜੋੜੋ। ਇਸਨੂੰ ਪਾਠਯੋਗ ਰੱਖੋ।

#!/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 ਕਿਵੇਂ ਬਣਦੀ ਹੈ, migrations ਕਿਵੇਂ ਚਲਦੇ ਹਨ, ਅਤੇ realistic ਪਹਿਲੀ ਰਨ ਲਈ seed ਡਾਟਾ ਕਿੱਥੇ ਮਿਲਦਾ ਹੈ।

ਅੰਤੀਮ ਤੌਰ 'ਤੇ, ਇੱਕ ਛੋਟਾ health check ਜੋ ਲੋਕਾਂ ਨੂੰ ਵਿਸ਼ਵਾਸ ਦਿਵਾਏ ਕਿ ਐਪ ਚੱਲ ਰਿਹਾ ਹੈ, ਸ਼ਾਮਲ ਕਰੋ। ਇੱਕ ਛੋਟਾ endpoint ਜਿਵੇਂ GET /health ਜੋ "ok" ਰੀਟਰਨ ਕਰੇ (ਅਤੇ ਡੇਟਾਬੇਸ ਕਨੈਕਟਿਵਿਟੀ ਵੇਰੀਫਾਈ ਕਰੇ) ਆਮ ਤੌਰ 'ਤੇ ਕਾਫ਼ੀ ਹੈ।

ਸੀਕ੍ਰੇਟਸ ਅਤੇ ਕਨਫਿਗਰੇਸ਼ਨ ਬਿਨਾਂ ਕਿਸੇ ਲੀਕ ਦੇ

ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਨਿਰਯਾਤ ਕਰਦੇ ਹੋ, ਕੋਡ ਤੁਹਾਡਾ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਸੀਕ੍ਰੇਟਸ ਨਿੱਜੀ ਰਹਿਣੇ ਚਾਹੀਦੇ ਹਨ। ਸਮਝੋ ਕਿ ਰਿਪੋ ਨਵੇਂ ਟੀਮਮੈਟਸ ਨਾਲ ਸਾਂਝੀ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਲਿਖੋ ਕਿ ਐਪ ਚਲਾਉਣ ਲਈ ਕੀ-ਕੀ ਚੀਜ਼ਾਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਅਨੁਮਾਨ ਨਾ ਲਗਾਓ। ਕੋਡ ਨੂੰ skim ਕਰੋ ਕਿ ਕਿੱਥੋਂ ਕਨਫਿਗ पढ़ੀ ਜਾ ਰਹੀ ਹੈ (environment variables, config files) ਅਤੇ ਉਹ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਚੈਕ ਕਰੋ ਜੋ ਤੁਸੀਂ ਐਨੇਬਲ ਕੀਤੇ ਸਨ।

ਆਮ ਤੌਰ 'ਤੇ ਸੀਕ੍ਰੇਟਸ ਇਨਵੈਂਟਰੀ ਵਿੱਚ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ: ਡੇਟਾਬੇਸ ਕ੍ਰੇਡੈਂਸ਼ੀਅਲ, ਤੀਸਰੇ-ਪਾਸੇ API key, auth ਸੈਟਿੰਗ (OAuth ਜਾਂ JWT), ਸਟੋਰੇਜ ਕ੍ਰੇਡੈਂਸ਼ੀਅਲ, ਅਤੇ ਐਪ-ਖਾਸ ਸੀਕ੍ਰੇਟਸ ਜਿਵੇਂ ਐਨਕ੍ਰਿਪਸ਼ਨ ਕੀਜ਼ ਜਾਂ webhook ਸਾਈਨਿੰਗ ਸੀਕ੍ਰੇਟ।

ਹਰ ਵਾਤਾਵਰਣ ਵਿੱਚ ਹਰ ਸੀਕ੍ਰੇਟ ਕਿੱਥੇ ਰਹੇਗਾ ਇਹ ਫੈਸਲਾ ਕਰੋ। ਇੱਕ ਚੰਗਾ ਡਿਫਾਲਟ ਨਿਯਮ:

ਲੋਕਲ: ਡਿਵੈਲਪਰ-ਮਲਕੀ .env (commit ਨਾ ਕਰੋ)
CI: CI ਪ੍ਰਦਾਤਾ ਦੀ secret store
ਪ੍ਰੋਡੈਕਸ਼ਨ: ਇੱਕ ਡੈਡੀਕੇਟਡ secret manager ਜਾਂ ਹੋਸਟਿੰਗ ਦੇ environment variables

ਜੇ ਤੁਸੀਂ vibe-coding ਜਿਹੇ ਪਲੇਟਫਾਰਮ ਤੋਂ ਨਿਰਯਾਤ ਕੀਤਾ ਹੈ (ਜਿਵੇਂ Koder.ai), ਤਾਂ ਮਨ ਲਵੋ ਕਿ ਚੈਟ, ਲੋਗਜ਼, ਜਾਂ ਸੈਟਿੰਗ ਪੈਨਲ ਵਿੱਚ ਦਿਖਾਈ ਦੇਣ ਵਾਲੀ ਕੋਈ ਵੀ ਚੀਜ਼ ਕਈ ਵਾਰੀ ਨਕਲ ਹੋ ਸਕਦੀ ਹੈ। ਸੀਕ੍ਰੇਟਸ ਨੂੰ ਰਿਪੋ ਤੋਂ ਤੁਰੰਤ ਬਾਹਰ ਲੈ ਜਾਓ।

ਅਮਲ ਦਾ ਇਕ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਇੱਕ ਸੁਰੱਖਿਅਤ ਟੈਮਪਲੇਟ commit ਕਰੋ (ਜਿਵੇਂ .env.example), ਅਸਲੀ ਮੁੱਲ Git ਵਿੱਚ ਨਾ ਰੱਖੋ (.env ਨੂੰ .gitignore ਵਿੱਚ ਜੋੜੋ), ਅਤੇ ਪ੍ਰੋਡੈਕਸ਼ਨ 'ਤੇ deploy ਵੇਲੇ ਸੀਕ੍ਰੇਟਸ inject ਕਰੋ।

ਜੇ ਐਕਸਪੋਰਟ ਦੌਰਾਨ ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ ਸੀਕ੍ਰੇਟਸ ਲੀਕ ਹੋਣ ਦਾ ਸੰਭਾਵਨਾ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਰੋਟੇਟ ਕਰੋ। ਡੇਟਾਬੇਸ ਪਾਸਵਰਡ, OAuth client secrets, ਅਤੇ webhook signing keys ਨੂੰ ਪਹਿਲੇ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿਓ।

ਕੁਝ guardrails ਜੋ ਇਹ ਦੋਹਰਾਉਣ ਤੋਂ ਰੋਕ ਸਕਦੇ ਹਨ: obvious secret patterns ਲਈ pre-commit ਚੈੱਕ, CI ਵਿੱਚ secret scan, ਸਖਤ config loading ਜੋ required variables ਨਹੀਂ ਮਿਲਣ ਤੇ fail ਕਰੇ, ਅਤੇ ਵੱਖ-ਵੱਖ ਵਾਤਾਵਰਣਾਂ ਲਈ ਵੱਖ-ਵੱਖ credentials।

ਇੱਕ ਛੋਟੀ SECRETS.md ਨਾਲ ਹandoff ਆਸਾਨ ਬਣਾਓ। ਸਧਾਰਨ ਰੱਖੋ: ਲਾਜ਼ਮੀ ਵੇਰੀਏਬਲ, ਹਰ ਵਾਤਾਵਰਣ ਵਿੱਚ ਕਿੱਥੇ ਸੰਭਾਲੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਕੌਣ ਰੋਟੇਟ ਕਰ ਸਕਦਾ ਹੈ।

CI ਸੈਟਅਪ ਤਾਂ ਜੋ ਰਿਪੋ ਸਿਹਤਮੰਦ ਰਹੇ

Collaborate, then hand off

Bring teammates in, then export a handoff-ready repo when it’s time to scale.

Invite Team

ਜਦੋਂ ਤੁਸੀਂ ਮਾਲਕੀਅਤ ਲੈ ਲੈਂਦੇ ਹੋ, CI ਤੁਹਾਡੀ safety net ਹੈ। ਪਹਿਲਾ ਵਰਜਨ ਛੋਟਾ ਰੱਖੋ। ਹਰ push ਤੇ ਇਹ ਸਾਬਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਪ੍ਰੋਜੈਕਟ ਅਜੇ ਵੀ build ਹੁੰਦਾ ਹੈ, ਮੂਢਲੇ checks ਪਾਸ ਹੁੰਦੇ ਹਨ, ਅਤੇ tests ਚਲ ਰਹੇ ਹਨ (ਜੇ ਹੋਣ)।

CI ਨੂੰ ਇਕ ਛੇਤੀ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ: "ਕੀ ਇਹ ਬਦਲਾਅ merge ਲਈ ਸੁਰੱਖਿਅਤ ਹੈ?" ਜ਼ਿਆਦਾਤਰ ਰਿਪੋਜ਼ ਲਈ, ਇਸਦਾ ਮਤਲਬ ਹੈ dependencies install, build, lint, ਅਤੇ unit tests ਚਲਾਉਣਾ।

ਜੋਬਜ਼ ਨੂੰ ਐਪ ਦੇ ਹਿੱਸਿਆਂ ਅਨੁਸਾਰ ਵੰਡੋ ਤਾਂ ਜੋ ਫੇਲਯਰ ਸਪੱਸ਼ਟ ਹੋ ਜਾਵੇ:

Web: install, lint/typecheck, build, tests ਚਲਾਉ
Backend: build, unit tests, linters/format checks
Optional mobile (Flutter): analyze, test, build
Optional database check: migrations ephemeral environment ਵਿੱਚ ਲਗਾ ਕੇ ਵੇਖੋ

ਕੈਸ਼ਿੰਗ ਵਰਤੋਂ, ਪਰ ਕੈਸ਼ ਸਮੱਸਿਆਆਂ ਨੂੰ ਲੁਕਾਉਣ ਨਾ ਦਿਓ। ਜਦੋਂ caches miss ਕਰਦੇ ਹਨ, CI ਫਿਰ ਵੀ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਸਿਰਫ਼ ਧੀਮਾ ਹੋਵੇ।

ਹਰ ਇੱਕ ਸਰੁਪ ਲਈ ਇੱਕ single command ਪ੍ਰਿਫਰ ਕਰੋ (make test, npm run test), ਤਾਂ ਕਿ ਉਹੀ command ਲੋਕਲ ਅਤੇ CI ਦੋਹਾਂ ਵਿੱਚ ਕਮ ਕਰੇ। ਇਹ ਗੁੰਝਲਦਾਰੀਆਂ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਲੌਗ ਲੰਬੇ ਨਹੀਂ ਹੁੰਦੇ।

ਉਦਾਹਰਣ ਸਰੂਪ (ਆਪਣੇ ਰਿਪੋ ਦੇ ਨਾਂ ਅਨੁਸਾਰ ਬਦਲੋ):

jobs:
  web:
    steps:
      - run: npm ci
      - run: npm run lint
      - run: npm run build
  api:
    steps:
      - run: go test ./...
      - run: go build ./...

ਬੁਨਿਆਦੀ ਗੱਲਾਂ ਸਥਿਰ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਇੱਕ ਸਧਾਰਣ ਰਿਲੀਜ਼ ਫਲੋ ਜੋੜੋ: ਰਿਲੀਜ਼ ਟੈਗ ਕਰੋ, ਅਰਟੀਫੈਕਟ ਬਣਾਓ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ CI ਆਰਟੀਫੈਕਟ ਵਜੋਂ ਰੱਖੋ। ਭਾਵੇਂ ਤੁਸੀਂ ਅਜੇ ਵੀ ਅੱਜ ਪਲੇਟਫਾਰਮ ਤੋਂ deploy ਕਰ ਰਹੇ ਹੋ, ਪਰ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ artifacts ਹੋਣ ਨਾਲ مستقبل ਵਿੱਚ ਹੋਸਟ ਬਦਲਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।

ਆਮ ਗਲਤੀਆਂ ਅਤੇ ਉਨ੍ਹਾਂ ਤੋਂ ਕਿਵੇਂ ਬਚਣਾ

ਸੋਰਸ ਕੋਡ ਨਿਰਯਾਤ ਕਰਨਾ ਅੱਧਾ ਕੰਮ ਹੈ। ਦੂਜਾ ਅੱਧਾ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਹੈ ਕਿ ਪ੍ਰੋਜੈਕਟ ਬਾਹਰ ਆ ਕੇ ਵੀ ਇੱਕੋ ਜਿਹਾ ਵਰਤਾਵ ਕਰੇ।

ਗਲਤੀ 1: ਸੋਚਣਾ ਕਿ ਬਿਨਾਂ ਕਿਸੇ ਸੈਟਅਪ ਦੇ ਚੱਲੇਗਾ

ਏਕਸਪੋਰਟ ਅਕਸਰ environment variables, migrations, seed data, ਅਤੇ build steps 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ ਜੋ ਤੁਹਾਡੇ ਲਈ ਸੈੱਟ ਕੀਤੇ ਗਏ ਸਨ। ਪਹਿਲੀ ਵਾਰ ਖਾਲੀ ਸਕਰੀਨ ਜਾਂ ਡੇਟਾਬੇਸ ਏਰਰ ਨਾਰਮਲ ਹੈ।

ਇੱਕ ਬੇਸਲਾਈਨ ਰਨ ਕਰੋ ਪਹਿਲਾਂ: deps install, env vars ਸੈੱਟ ਕਰੋ, migrations ਚਲਾਓ, ਸਰਵਿਸਜ਼ ਆਰਡਰ ਵਿੱਚ ਸ਼ੁਰੂ ਕਰੋ। ਕੇਵਲ ਜਰੂਰੀ ਸੋਧ ਕਰੋ ਤਾਂ ਜੋ ਉਮੀਦ ਕੀਤੀ ਸੈਟਅਪ ਮਿਲ ਸਕੇ।

ਗਲਤੀ 2: ਸੀਕ੍ਰੇਟਸ Git ਵਿੱਚ ਲੀਕ ਹੋਣਾ

ਸਭ ਤੋਂ ਆਮ ਹਾਦਸਾ ਅਸਲੀ API keys ਜਾਂ password commit ਹੋ ਜਾਣਾ ਹੈ, ਅਕਸਰ .env ਫਾਈਲ ਦੀ ਨਕਲ ਕਰਦੇ ਸਮੇਂ।

ਸਿਰਫ਼ ਟੈਮਪਲੇਟ commit ਕਰੋ। ਅਸਲੀ ਮੁੱਲਾਂ ਲੋਕਲ environment ਜਾਂ secret store ਵਿੱਚ ਰੱਖੋ।

ਗਲਤੀ 3: ਜ਼ਰੂਰਤ ਤੋਂ ਪਹਿਲਾਂ ਡਿਪੈਂਡੈਂਸੀਜ਼ ਬਦਲਣਾ

ਪੈਕੇਜ ਅੱਪਗਰੇਡ ਕਰਨ ਜਾਂ ਫੋਲਡਰਾਂ ਨੂੰ turhan ਕਰ ਦੇਣ ਨਾਲ ਇਹ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ ਕਿ ਸਮੱਸਿਆਐਂ ਐਕਸਪੋਰਟ ਤੋਂ ਆਈਆਂ ਹਨ ਜਾਂ ਤੁਹਾਡੇ ਬਦਲਾਅ ਤੋਂ।

ਪਹਿਲਾਂ ਇੱਕ ਕੰਮ ਕਰਨ ਵਾਲੀ ਰਨ ਲੱਭੋ, ਫਿਰ ਛੋਟੇ, ਵੱਖ-ਵੱਖ commits ਵਿੱਚ ਸੁਧਾਰ ਕਰੋ।

ਗਲਤੀ 4: ਵਰਜਨ ਪਿਨ ਨਾ ਕਰਨਾ

"ਮੇਰੀ ਮਸ਼ੀਨ ਤੇ ਚੱਲ ਰਿਹਾ ਹੈ" ਅਕਸਰ unpinned tool versions (Node, Go, Flutter, package managers) ਕਾਰਨ ਹੁੰਦਾ ਹੈ।

ਰਨਟਾਈਮ ਵਰਜਨਾਂ ਨੂੰ ਕਿਸੇ ਸਪੱਸ਼ਟ ਥਾਂ 'ਤੇ ਪਿਨ ਕਰੋ (ਫਾਈਲ ਜਾਂ README), lockfiles (package-lock, go.sum, pubspec.lock) ਰੱਖੋ, ਅਤੇ ਸੈਟਅਪ ਨੂੰ ਦੂਜੀ ਮਸ਼ੀਨ ਜਾਂ ਇੱਕ ਤਾਜ਼ਾ ਕੰਟੇਨਰ 'ਤੇ ਵੇਰੀਫਾਈ ਕਰੋ।

ਗਲਤੀ 5: ਡੌਕਸ ਛੱਡ ਦੇਣਾ, ਫਿਰ ਮਹਿੰਗੀ ਭੁਗਤਾਨੀ

Handoffs ਫੇਲ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਕੋਈ ਵੀ ਇੱਕ ਅਜਿਹੇ ਛੋਟੇ ਕਦਮ ਨੂੰ ਯਾਦ ਨਹੀਂ ਰੱਖਦਾ ਜੋ ਐਪ start ਕਰਨ ਲਈ ਲਾਜ਼ਮੀ ਹੁੰਦਾ ਹੈ। ਇਹ ਨੋਟ ਕਰ ਲਓ ਜਦੋਂ ਚੀਜ਼ਾਂ ਤਾਜ਼ਾ ਹਨ: ਲਾਜ਼ਮੀ env vars, migrations ਕਿਵੇਂ ਚਲਾਉਣੇ ਹਨ, ਲੋਗ ਕਿੱਥੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਲੋਕਲ ਸਟੇਟ ਰੀਸੈਟ ਕਿਵੇਂ ਕਰਨਾ ਹੈ।

ਇੱਕ ਹਕੀਕਤੀ ਉਦਾਹਰਣ: ਪਲੇਟਫਾਰਮ ਪ੍ਰੋਜੈਕਟ ਤੋਂ ਸੁਤੰਤਰ ਰਿਪੋ

Ship without platform lock-in

Deploy and host your project, then move it to your own setup whenever you’re ready.

Deploy App

ਇੱਕ ਤਿੰਨ-ਵਿਆਕਤੀ ਟੀਮ Koder.ai ਵਿੱਚ ਇੱਕ customer portal ਬਣਾਉਂਦੀ ਹੈ: React ਵੈੱਬ ਐਪ, Go API, ਅਤੇ PostgreSQL ਡੇਟਾਬੇਸ। ਜਦੋਂ ਉਹ ਬਾਹਰੀ dev ਟੀਮ ਨੂੰ ਸੌਂਪਣਾ ਚਾਹੁੰਦੇ ਹਨ, ਉਹ ਚਾਹੁੰਦੇ ਹਨ ਕਿ ਐਕਸਪੋਰਟ ਇੱਕ ਆਮ ਰਿਪੋ ਵਾਂਗ ਮਹਿਸੂਸ ਹੋਵੇ ਜੋ ਕਿਸੇ ਵੀ ਵਿਅਕਤੀ ਨੂੰ ਦਿਨ ਇੱਕ 'ਤੇ ਚੱਲ ਸਕੇ।

Day 1: ਉਹ export ਕਰਦੇ ਹਨ, ਇੱਕ ਨਵਾਂ Git ਰਿਪੋ ਬਣਾਉਂਦੇ ਹਨ, ਅਤੇ ਲੋਕਲ ਤੇ ਚਲਾਉਂਦੇ ਹਨ। ਫਰੰਟਐਂਡ ਚੱਲ ਜਾਂਦਾ ਹੈ, ਪਰ API fail ਕਰਦੀ ਹੈ ਕਿਉਂਕਿ environment variables ਮੌਜੂਦ ਨਹੀਂ। ਉਹ ਅਨੁਮਾਨ ਨਹੀਂ ਲਗਾਉਂਦੇ। ਉਹ ਕੋਡ ਪੜ੍ਹਦੇ ਹਨ, ਸਹੀ ਕੀ-ਕੀ ਕੁੰਜੀਆਂ ਦੀ ਪਛਾਣ ਕਰਦੇ ਹਨ, ਅਤੇ .env.example ਬਣਾਉਂਦੇ ਹਨ placeholders ਨਾਲ। ਅਸਲੀ ਮੁੱਲ password manager ਅਤੇ ਲੋਕਲ .env ਫਾਈਲਾਂ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ।

ਉਹ ਨੋਟਿਸ ਕਰਦੇ ਹਨ ਕਿ ਪੋਰਟ ਅਤੇ CORS ਸੈਟਿੰਗਾਂ ਪਲੇਟਫਾਰਮ 'ਤੇ ਠੀਕ ਸਨ ਪਰ ਲੋਕਲ ਲਈ defaults ਲੋੜੀਂਦੇ ਹਨ। ਉਹ ਪੇਸ਼ਗੀ defaults ਰੱਖਦੇ ਹਨ (ਉਦਾਹਰਣ ਲਈ, API 8080 'ਤੇ ਅਤੇ web 3000 'ਤੇ) ਤਾਂ ਜੋ ਨਵੀਆਂ ਮਸ਼ੀਨਾਂ ਇੱਕੋ ਤਰੀਕੇ ਨਾਲ ਵਰਤਣ।

Day 2: ਉਹ migrations ਅਤੇ ਇੱਕ ਛੋਟਾ seed script ਜੋ demo user ਅਤੇ ਕੁਝ rows ਬਣਾਉਂਦਾ ਹੈ ਜੋੜਦੇ ਹਨ। ਫਿਰ ਉਹ ਇੱਕ ਛੋਟਾ README ਲਿਖਦੇ ਹਨ ਜੋ prerequisites, ਰਨ ਕਰਨ ਵਾਲੀਆਂ ਕਮਾਂਡ, ਅਤੇ ਕਿਵੇਂ verify ਕਰਨਾ ਹੈ (API ਲਈ health endpoint ਅਤੇ UI ਲਈ sample login) ਕਵਰ ਕਰਦਾ ਹੈ।

Day 3: ਉਹ ਇੱਕ ਬੁਨਿਆਦੀ CI workflow ਜੋ tests, linting, ਅਤੇ builds ਦੋਹਾਂ ਲਈ ਹਰ pull request 'ਤੇ ਚਲਦੀ ਹੈ ਜੋੜਦੇ ਹਨ। staging ਲਈ, ਉਹ ਇੱਕ ਸਧਾਰਣ ਯੋਜਨਾ ਦਸਤਾਵੇਜ਼ ਕਰਦੇ ਹਨ: containers build ਕਰੋ, environment ਵਿੱਚ secrets ਸੈੱਟ ਕਰੋ, deploy 'ਤੇ migrations ਚਲਾਓ, ਅਤੇ rollback ਵਿਕਲਪ ਰੱਖੋ।

Acha handoff ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਐਸਾ ਰਿਪੋ ਹੁੰਦਾ ਹੈ ਜੋ fresh clone ਤੋਂ ਲੋਕਲ ਤੇ ਚੱਲਦਾ ਹੈ, .env.example ਨਾਲ ਨੋਟਸ ਕਿ ਸੀਕ੍ਰੇਟਸ ਕਿੱਥੇ ਰਹਿੰਦੇ ਹਨ, migrations ਅਤੇ seed ਡਾਟਾ, CI checks ਜੋ ਫੈਲ ਹੋ ਕੇ ਤੇਜ਼ੀ ਨਾਲ ਦੱਸਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਛੋਟਾ deploy ਨੋਟ staging ਅਤੇ rollback ਲਈ।

ਤੇਜ਼ ਚੈੱਕ ਸੁਚੀ ਅਤੇ ਅਗਲੇ ਕਦਮ

ਆਪਣੀ ਅਧੀਨਤਾ ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਸਾਬਤ ਕਰੋ ਕਿ ਪ੍ਰੋਜੈਕਟ ਪਲੇਟਫਾਰਮ ਤੋਂ ਬਾਹਰ ਜੀਊਂਦਾ ਰਹਿ ਸਕਦਾ ਹੈ। ਜੇ ਇਕ ਹੋਰ ਡਿਵੈਲਪਰ ਬਿਨਾਂ ਅਨੁਮਾਨ ਦੇ ਚਲਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਚੰਗੀ ਸਥਿਤੀ ਵਿੱਚ ਹੋ।

ਆਖਰੀ ਚੈੱਕਲਿਸਟ ਵਰਤੋ:

ਰਿਪੋ पठਣਯੋਗ ਹੈ: ਸਪਸ਼ਟ README, ਸਮਝਦਾਰ ਫੋਲਡਰ ਨਾਂ, ਅਤੇ ਐਪ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਦਾ ਇੱਕ ਤਰੀਕਾ।
fresh থেকে ਲੋਕਲ ਰਨ ਕੰਮ ਕਰਦੀ ਹੈ: clone, install, configure, run, ਅਤੇ ਐਪ ਵੇਖੋ ਬਿਨਾਂ ਮੈਨੂਅਲ ਸੋਧਾਂ ਦੇ।
Tests ਚਲਦੇ ਹਨ (ਇੱਕ smoke test ਜਾਂ health check ਵੀ ਕੁਝ ਹੋਣਾ ਬਿਹਤਰ ਹੈ)।
ਹਰ push 'ਤੇ CI ਚਲਦਾ ਹੈ: lint, tests, ਅਤੇ build ਜੋ ਤੇਜ਼ੀ ਨਾਲ fail ਹੋ ਜਾਏ।
Secrets ਵੱਖ ਹਨ: ਰਿਪੋ ਵਿੱਚ ਕੋਈ ਕੀਜ਼ ਨਹੀਂ, ਅਤੇ ਨਮੂਨਾ config ਫਾਈਲ ਕਾਂ ਲਾਜ਼ਮੀ ਵੇਰੀਏਬਲ ਦਿਖਾਉਂਦੀ ਹੈ।
ਡੌਕਸ ਬੇਸਿਕ ਕਵਰ ਕਰਦੀਆਂ ਹਨ: ਕਿਵੇਂ ਚਲਾਉਣਾ ਹੈ, ਕਿਵੇਂ ਡਿਪਲੌਯ ਕਰਨਾ ਹੈ, ਅਤੇ ਆਮ ਸੈਟਿੰਗਾਂ ਕਿੱਥੇ ਬਦਲਣੀਆਂ ਹਨ।

ਤਕਨੀਕੀ ਜਾਂਚ ਤੋਂ ਬਾਅਦ, ਮਾਲਕੀਅਤ ਸਪੱਸ਼ਟ ਬਣਾਓ। ਫੈਸਲਾ ਕਰੋ ਕਿ dependency updates, infrastructure ਬਦਲਾਅ (ਡੇਟਾਬੇਸ, queues, DNS), ਅਤੇ releases ਦੀ ਕੋਣ ਮਾਲਕ ਹੈ। ਜੇ ਕੋਈ ਮਾਲਕ ਨਹੀਂ, ਤਾਂ ਰਿਪੋ ਹੌਲੀ-ਹੌਲੀ ਖਰਾਬ ਹੋ ਜਾਏਗੀ ਭਾਵੇਂ ਅੱਜ ਐਪ ਚੱਲ ਰਿਹਾ ਹੋਵੇ।

ਵੱਡੇ ਫੀਚਰ ਕੰਮ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟੀ stabilization window ਯੋਜਨਾ ਬਣਾਓ। 2–5 ਕੰਮਕਾਜੀ ਦਿਨ ਆਮ ਤੌਰ 'ਤੇ ਕਾਫ਼ੀ ਹੁੰਦੇ ਹਨ ਐਕਸਪੋਰਟ ਦੀਆਂ ਖੂਟੀਆਂ ਦੁਰੁਸਤ ਕਰਨ, README ਨੂੰ ਮਜ਼ਬੂਤ ਕਰਨ, ਅਤੇ "ਮੇਰੀ ਮਸ਼ੀਨ ਤੇ ਚੱਲ ਰਿਹਾ ਹੈ" ਸਮੱਸਿਆਵਾਂ ਹਟਾਉਣ ਲਈ।

ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਐਕਸਪੋਰਟਾਂ ਅਤੇ ਵਰਗੇ ਫੀਚਰ snapshots ਅਤੇ rollback ਨਾਲ ਤੁਸੀਂ ਇਟਰੇਟ ਕਰਨ ਦਾ ਕੰਮ ਆਸਾਨ ਕਰ ਸਕਦੇ ਹੋ ਜਦੋਂ ਤੁਸੀਂ ਰਿਪੋ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰ ਰਹੇ ਹੋ। ਇੱਕ ਵਾਰੀ ਰਿਪੋ ਸਥਿਰ ਹੋ ਜਾਵੇ, Git ਨੂੰ truth ਸਰੋਤ ਮੰਨੋ ਅਤੇ ਭਵਿੱਖ ਦੇ ਐਕਸਪੋਰਟਾਂ ਨੂੰ checkpoints ਵਜੋਂ ਵਰਤੋ, ਮੁੱਖ ਇਤਿਹਾਸ ਵਜੋਂ ਨਹੀਂ।

ਅਗਲਾ handoff ਮਿਲਸਟੋਨ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ: "ਕੋਈ ਵੀ ਡਿਵੈਲਪਰ 30 ਮਿੰਟ ਵਿੱਚ ਚਲਾ ਸਕੇ।" ਫਿਰ ਕਿਸੇ ਨਵੇਂ ਵਿਅਕਤੀ ਨੂੰ ਤਾਜ਼ਾ ਮਸ਼ੀਨ 'ਤੇ README ਫੋਲੋ ਕਰਨ ਲਈ ਕਹੋ। ਉਹਦੇ ਸਵਾਲ ਤੁਹਾਡੀ ਆਖਰੀ to-do ਸੂਚੀ ਬਣ ਜਾਣਗੇ।

ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ

“Taking ownership” ਦਾ ਅਸਲ ਮਤਲਬ ਐਕਸਪੋਰਟ ਤੋਂ ਬਾਅਦ ਕੀ ਹੈ?

Treat ownership as independence: you can build, run, change, and deploy the app from a normal repo without needing the original platform project, special UI settings, or hidden build steps.

A good test is: can a new teammate clone the repo and get it running using only the README?

ਐਕਸਪੋਰਟ ਪੂਰਾ ਹੈ ਜਾਂ ਨਹੀਂ ਇਹ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਚੈੱਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?

Start with a quick completeness check:

Find each app “root” (package.json, go.mod, pubspec.yaml).
Confirm there’s a lockfile (package-lock.json, yarn.lock, pnpm-lock.yaml, go.sum).
Look for database migrations (migrations/ or similar).
Check for a runnable workflow (README, Makefile, scripts, or docker-compose.yml).

If anything required to run is only described in a UI or chat, write it down and move it into the repo.

ਐਕਸਪੋਰਟ ਕੀਤੀ ਪਰੋਜੈਕਟ ਨੂੰ ਲੋਕਲ ਤੇ ਚਲਾਉਣ ਦਾ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕਾ ਕੀ ਹੈ?

Do it in small, verifiable steps:

Initialize Git and commit the raw export (baseline).
Set up local config using .env.example → .env.
Start the database.
Run migrations.
Start the backend.
Start the frontend.

Don’t refactor immediately—first prove it runs as-is, then improve it in separate commits.

ਕਿਉਂ ਐਪ ਪਲੇਟਫਾਰਮ 'ਤੇ ਠੀਕ ਚੱਲਦੀ ਹੈ ਪਰ ਮੇਰੇ ਲੈਪਟੌਪ ਤੇ ਫੇਲ ਹੁੰਦੀ ਹੈ?

Because the hosted environment often had things you never made explicit:

Missing environment variables (API base URL, JWT secret, storage keys).
Database not created, migrations not applied, or seed data missing.
Different ports/CORS settings that were preconfigured in hosting.
Implicit build steps that were handled “somewhere else.”

Fix this by making the setup visible: .env.example, migration scripts, and a README with exact commands.

ਐਕਸਪੋਰਟ ਤੋਂ ਬਾਅਦ ਡੇਟਾਬੇਸ ਹਿੱਸੇ ਨੂੰ ਕਿਵੇਂ ਪੱਕਾ ਕੀਤਾ ਜਾਵੇ?

A server “starting” isn’t enough—verify real data flow:

Load a page that clearly depends on database reads.
Create a record, refresh, and confirm it persisted.
Do one update and one delete if possible.
Watch logs for migration issues like “relation does not exist.”

If you can’t reliably reproduce data changes locally, your setup or migrations are incomplete.

ਮੈਂ Git ਵਿੱਚ API keys ਜਾਂ ਹੋਰ ਸੀਕ੍ਰੇਟ ਸਾਂਝੇ ਨਾ ਕਰਨ ਲਈ ਕਿਵੇਂ ਸੰਭਾਲਾਂ?

Default approach:

Commit .env.example with fake values.
Add .env to .gitignore.
Store real secrets in a password manager or a secret store.

If you find real keys in the repo, assume they’re compromised and rotate them. Prioritize database credentials, OAuth client secrets, and webhook signing secrets.

ਰਿਪੋ ਦਾ ਮੁਲ-ਯੋਗ CI ਸੈਟਅਪ ਕੀਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ?

Keep the first CI simple and consistent with local commands:

Build and lint/typecheck the web app.
Run go test ./... and build the backend.
Optionally apply migrations in an ephemeral database.

Make CI call the same scripts you expect developers to run (for example make test or npm run build). That reduces “works locally but not in CI.”

ਜੇ ਐਪ ਪਹਿਲਾਂ ਹੀ ਚੱਲਦਾ ਹੈ ਤਾਂ ਕੀ ਮੈਨੂੰ README ਅਤੇ bootstrap script ਦੀ ਲੋੜ ਹੈ?

Yes—if you want a predictable handoff. A good default is:

A single top-level README.md with copy-paste commands.
A .env.example describing required vs optional variables.
One bootstrap command/script to install deps and prepare the DB.

Aim for a new developer being able to run the app in 15–30 minutes without guessing.

ਵੈੱਬ + API + ਡੇਟਾਬੇਸ ਵਾਲੇ ਐਕਸਪੋਰਟ ਰਿਪੋ ਨੂੰ ਕਿਵੇਂ ਠੀਕ ਢੰਗ ਨਾਲ ਸੋਧਿਆ ਜਾਵੇ?

Common structure is:

apps/ for frontends (web, mobile).
services/ for APIs and workers.
shared/ for shared types/utilities.
infra/ for deployment templates and environment examples.

The exact names don’t matter as much as making it obvious what runs where, and how the pieces connect.

Koder.ai ਤੋਂ ਐਕਸਪੋਰਟ ਕਰਨ ਤੋਂ ਬਾਅਦ ਅਗਲੇ ਕਦਮ ਕੀ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ?

A practical sequence:

Export and commit the baseline.
Make it run locally with explicit config, migrations, and a clear README.
Add CI to keep builds and tests from silently breaking.
Add a simple deploy note (how to set secrets, run migrations, rollback).

Once stable, treat Git as the source of truth and any future platform exports as checkpoints, not the primary history.