PHP डेवलपर के लिए Git Workflow: प्रोडक्शन को कैसे सुरक्षित रखें

PHP डेवलपर के लिए Git Workflow: अराजकता से व्यवस्था की ओर (और वापस)

क्या आपने कभी शुक्रवार शाम को master ब्रांच में कोड push किया है, यह प्रार्थना करते हुए कि सब कुछ ठीक काम करे? या composer.lock के साथ ऐसी गलती की है कि merge के बाद सब कुछ टूट गया? स्वागत है क्लब में। Git सिर्फ एक वर्जन कंट्रोल सिस्टम नहीं है, यह आपका daily driver है। लेकिन सही workflow के बिना, सबसे अच्छा PHP कोड भी बेकार हो जाता है।

इस लेख में हम PHP डेवलपर्स के लिए Git workflow को विस्तार से समझेंगे जो वास्तव में काम करता है: ब्रांचिंग स्ट्रैटेजी चुनने से लेकर डिप्लॉयमेंट तक। कोई बेकार की बात नहीं, सिर्फ कोड, उदाहरण और टिप्स। चलिए शुरू करते हैं!

1. स्ट्रैटेजी चुनें: Git Flow बनाम Trunk-Based

Git flow और trunk-based development के बीच बहस PHP फ्रेमवर्क के इतिहास से भी लंबी है। लेकिन अधिकांश PHP प्रोजेक्ट्स (खासकर Symfony/Laravel पर legacy) के लिए Git Flow सबसे अच्छा विकल्प है। क्यों?

\n
• स्पष्ट अलगाव features, releases और hotfixes का।
\n
• नियंत्रण कि क्या प्रोडक्शन में जा रहा है।
• Composer के साथ काम — हर बार dev-ब्रांच को merge करने की जरूरत नहीं।

लेकिन अगर आपके पास माइक्रो-सर्विसेज और CI/CD का जबरदस्त सेटअप है, तो trunk-based भी एक विकल्प है। हम क्लासिक पर फोकस करेंगे।

2. Feature Branch: आपका सैंडबॉक्स

हर नई फीचर के लिए अलग ब्रांच बनाएं। नाम ऐसा होना चाहिए जो बताए कि क्या हो रहा है: feature/PROJ-123-add-payment-gateway। fix-bug या new-stuff जैसे नाम न दें।

काम शुरू करने का उदाहरण:

git checkout -b feature/PROJ-42-new-cache-system develop\ngit push origin feature/PROJ-42-new-cache-system

जब आप कोड लिख रहे हों, तो composer को न भूलें। अगर कोई नई डिपेंडेंसी जोड़ रहे हैं, तो composer.json और composer.lock को एक साथ commit करें। इससे आपके सहकर्मियों को "यह मेरे पास काम क्यों नहीं कर रहा?" जैसी समस्या से बचाया जा सकेगा।

composer require predis/predis\ngit add composer.json composer.lock\ngit commit -m "PROJ-42: Add predis for caching"

महत्वपूर्ण: vendor/ को कभी commit न करें! इसे तुरंत .gitignore में जोड़ें।

3. Pull Request: बिना दर्द के कोड रिव्यू

जब फीचर तैयार हो जाए, तो develop ब्रांच में PR (या GitLab में MR) बनाएं। यह चेकलिस्ट रिव्यूअर की नसों को बचाएगी:

\n
• ✅ कोड phpcs और phpstan (कम से कम लेवल 6) पास करता है।
• ✅ टेस्ट लिखे गए हैं (PHPUnit, Pest)।
• ✅ composer.lock अपडेट किया गया है।
• ✅ develop के साथ कोई कन्फ्लिक्ट नहीं है।

CI स्क्रिप्ट का उदाहरण (GitHub Actions):

name: PHP CI\n\non:\n  pull_request:\n    branches: [ develop ]\n\njobs:\n  php-tests:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v3\n      - name: Install dependencies\n        run: composer install --no-interaction --prefer-dist\n      - name: Run PHPStan\n        run: vendor/bin/phpstan analyse src --level=6\n      - name: Run tests\n        run: vendor/bin/phpunit

यह PHP डेवलपर्स के लिए workflow कोड की जांच को किसी के PR देखने से पहले ही ऑटोमेट कर देता है। जादू, है ना?

4. रिलीज़ ब्रांच: प्रोडक्शन की तैयारी

जब रिलीज़ के लिए पर्याप्त फीचर जमा हो जाएं, तो develop से release/x.y.z ब्रांच बनाएं। यहां आप बग्स फिक्स करते हैं, changelog अपडेट करते हैं, और composer.json में वर्जन बढ़ाते हैं।

git checkout -b release/1.2.0 develop\n# बग्स फिक्स करें, वर्जन अपडेट करें\nvim composer.json  # "version": "1.2.0" बदलें\ngit commit -am "Bump version to 1.2.0"\n# master और develop में मर्ज करें\ngit checkout master\ngit merge --no-ff release/1.2.0\ngit tag -a v1.2.0 -m "Release version 1.2.0"\ngit push origin master --tags

--no-ff पर ध्यान दें। यह ब्रांचिंग हिस्ट्री को सुरक्षित रखता है, ताकि आप हमेशा जान सकें कि कोड कहां से आया है।