TypeScript के लिए Git workflow: टाइप किए गए कोड में संतुलन कैसे बनाए रखें

TypeScript के लिए Git workflow: merge conflict से डरना छोड़ें

कभी दो ब्रांच को मर्ज करने की कोशिश की है जहाँ एक ने User इंटरफ़ेस बदला और दूसरे ने उसी मॉड्यूल में नया टाइप जोड़ा? तो आप जानते हैं कि डेवलपर का अस्तित्वगत संकट क्या होता है। TypeScript एक शक्तिशाली टाइप सिस्टम देता है, लेकिन सही Git workflow के बिना यह शक्ति सिरदर्द बन जाती है।

इस लेख में हम TypeScript प्रोजेक्ट्स के लिए सबसे अच्छा Git workflow समझेंगे — ब्रांच सेटअप से लेकर हर कमिट पर ऑटोमैटिक टाइप चेकिंग तक। कोई बकवास नहीं, सिर्फ वही जो वास्तव में काम करता है।

TypeScript को Git के लिए खास दृष्टिकोण की आवश्यकता क्यों है?

TypeScript सिर्फ "JavaScript with types" नहीं है। यह एक ऐसी भाषा है जहाँ हर बदलाव interface, type और जेनेरिक्स के ज़रिए दर्जनों फ़ाइलों को प्रभावित कर सकता है। बेस टाइप में एक गलती — और पूरा प्रोजेक्ट कंपाइल नहीं होगा।

इसलिए एक मानक TypeScript के लिए git workflow में शामिल होना चाहिए:

\n
• कमिट से पहले टाइप चेकिंग अनिवार्य
\n
• लिंटर जो बिना फ़ॉर्मेट किए कोड को कमिट न होने दे
\n
• स्पष्ट ब्रांचिंग रणनीति ताकि merge conflict टाइप न तोड़े
\n
• CI/CD जो सर्वर पर सब कुछ दोबारा जाँचे
\n

आइए हर बिंदु को क्रम से समझते हैं।

1. ब्रांचिंग रणनीति चुनें: Git Flow या Trunk-based?

TypeScript प्रोजेक्ट्स के लिए मैं Trunk-based development की सलाह देता हूँ, जिसमें छोटी उम्र वाली ब्रांच हों। क्यों? क्योंकि TypeScript कोड मूल रूप से "कच्चा" कोड होता है जिसे जल्दी जाँचने और डिप्लॉय करने की ज़रूरत होती है। लंबी ब्रांच से टाइप "बिखर" जाते हैं।

ब्रांच की बुनियादी संरचना

main        — स्थिर वर्जन, हमेशा डिप्लॉय के लिए तैयार\ndevelop     — मुख्य डेवलपमेंट ब्रांच\nfeature/*   — नई सुविधाएँ (1-2 दिन जीवित रहती हैं)\nfix/*       — बग फिक्स\nrelease/*   — रिलीज़ की तैयारी (वैकल्पिक)\n

TypeScript प्रोजेक्ट का उदाहरण:

git checkout -b feature/add-user-validation\n# काम करें...\ngit commit -m "feat: add email validation for User type"\ngit push origin feature/add-user-validation\n# PR बनाएँ → develop में मर्ज करें\n

महत्वपूर्ण: कभी भी main पर rebase न करें अगर प्रोजेक्ट में साझा टाइप हैं। merge का उपयोग करें — यह इतिहास सुरक्षित रखता है और निर्भरता नहीं तोड़ता।

2. Git Hooks: मूर्खों से सुरक्षा (और खुद से)

सबसे आम परिदृश्य: आप tsc चलाना भूल गए, कमिट किया, पुश किया, और CI फेल हो गया। इससे बचने के लिए pre-commit hooks सेट करें।

Husky + lint-staged इंस्टॉल करना

Husky Git hooks मैनेज करने का टूल है। lint-staged केवल बदली गई फ़ाइलों पर कमांड चलाता है।

npm install --save-dev husky lint-staged\nnpx husky init\n

.husky/pre-commit फ़ाइल बनाएँ:

#!/usr/bin/env sh\n. "$(dirname -- "$0")/_/husky.sh"\n\nnpx lint-staged\n

package.json में जोड़ें:

{\n  "lint-staged": {\n    "*.ts": [\n      "eslint --fix",\n      "prettier --write",\n      "tsc --noEmit"\n    ]\n  }\n}\n

अब हर कमिट से पहले:

\n
1. ESLint ऑटोफिक्स के साथ चलता है
\n
2. Prettier से कोड फ़ॉर्मेट होता है
\n
3. TypeScript बिल्ड चेक होता है (tsc --noEmit)
\n

अगर एक भी स्टेप फेल हुआ — कमिट नहीं होगा। कठोर, लेकिन प्रभावी।

3. सही commit message: conventional commits

TypeScript प्रोजेक्ट्स को conventional commits से फ़ायदा होता है, क्योंकि:

\n
• ऑटोमैटिक changelog जनरेट होता है
\n
• आसानी से पता चलता है कि कौन से बदलाव टाइप तोड़ते हैं
\n
• केवल खास कमिट पर CI ट्रिगर किया जा सकता है
\n

उदाहरण:

feat: add UserRole enum and validation\nfix: c