Git से डिप्लॉय करें

Portal में Git Deploy टैब आपके सर्वर को GitHub, GitLab, Gitea या Forgejo पर किसी Git रिपॉज़िटरी से जोड़ता है। उसकी फ़ाइलें आपके सर्वर पर अपने-आप कॉपी होती हैं — हर push पर, जब आप release प्रकाशित करते हैं, जब आप tag push करते हैं, या बटन दबाकर। चाहें तो डिप्लॉय से पहले आपका सर्वर साफ़-सुथरे तरीके से रोका जाता है और बाद में फिर से शुरू होता है।

संक्षेप में: अपना कोड push करें, और कुछ सेकंड बाद वह आपके सर्वर पर चल रहा होता है। अब SFTP से अपलोड नहीं करना, file manager में ZIP फ़ाइलें खोलनी नहीं पड़तीं, और रीस्टार्ट भूलने का डर नहीं।

आप क्या सीखेंगे

• रिपॉज़िटरी कैसे जोड़ें, Daki Git Deploy GitHub app से या access token से
• डिप्लॉय कब चलता है और उसे खुद कैसे ट्रिगर करें
• protected paths से world, डेटाबेस और .env फ़ाइलें सुरक्षित कैसे रखें
• रीस्टार्ट, डिप्लॉय इतिहास, रोलबैक और आपकी रिपॉज़िटरी में स्टेटस कैसे काम करते हैं
• अपनी टीम को सही अनुमतियाँ कैसे दें

किसके लिए

• Discord बॉट और Node.js, Python या Java ऐप के डेवलपर, जिनका कोड पहले से GitHub या GitLab पर है।
• Minecraft नेटवर्क और गेम सर्वर टीमें, जो plugins, configs या datapacks एक रिपॉज़िटरी में रखती हैं और चाहती हैं कि बदलाव ट्रेस हो सकने वाले तरीके से लागू हों।
• टीमें: रिपॉज़िटरी में कई लोग काम करते हैं, सर्वर हमेशा अप-टू-डेट रहता है, और सब-यूज़र की अनुमतियाँ तय करती हैं कि डिप्लॉय कौन कर सकता है।
• Release-आधारित प्रोजेक्ट: केवल प्रकाशित वर्शन (जैसे release से तैयार हुई .jar) सर्वर पर पहुँचते हैं, हर अधूरा काम नहीं।

शुरू करने से पहले

• Portal में एक सर्वर, जिसमें Git Deploy टैब दिखता हो। यह सर्वर नेविगेशन में Essentials के अंतर्गत आता है, डिफ़ॉल्ट रूप से Files के ठीक बाद।
• GitHub (github.com), GitLab (gitlab.com या आपका अपना इंस्टेंस, group/subgroup/project जैसे subgroups सहित), Gitea या Forgejo (जैसे Codeberg या आपका अपना इंस्टेंस) पर एक रिपॉज़िटरी। सार्वजनिक और निजी, दोनों रिपॉज़िटरी चलती हैं।

GitHub से त्वरित शुरुआत (अनुशंसित)

सबसे तेज़ तरीका: Daki Git Deploy से जुड़ें, Daki Hosting की आधिकारिक GitHub app। आप GitHub पर साइन इन करते हैं और अपनी रिपॉज़िटरी चुनते हैं — कोई token और कोई webhook नहीं चाहिए।

1. 1

   Git Deploy टैब खोलें

   Portal में अपना सर्वर खोलें और Git Deploy टैब पर जाएँ। Git service के अंतर्गत GitHub चुनें।

2. 2

   GitHub से कनेक्ट करें

   GitHub access बॉक्स में Connect with GitHub पर क्लिक करें। GitHub पर साइन इन करें और app को अधिकृत करें।

   पहली बार GitHub आपको सीधे यह चुनने के लिए ले जाता है कि app किन रिपॉज़िटरी तक पहुँच सकता है (All repositories या केवल चुनी हुई) — दो के बजाय एक ही चरण में। इसके बाद आप Portal में लौट आते हैं, और GitHub access बॉक्स में Connected via Daki Git Deploy as के बाद आपका GitHub नाम दिखता है। Webhook बॉक्स पुष्टि करता है कि कुछ सेट करने की ज़रूरत नहीं: push और releases ऐप के ज़रिए अपने-आप पहुँचते हैं।

3. 3

   अपनी रिपॉज़िटरी और ब्रांच चुनें

   Choose from my repositories पर क्लिक करें और अपनी रिपॉज़िटरी चुनें — या वेब या clone URL paste करें, या path लिखें। Load branches पर क्लिक करें और वह ब्रांच चुनें जिसे डिप्लॉय करना है। रिपॉज़िटरी की डिफ़ॉल्ट ब्रांच इस्तेमाल करने के लिए इसे खाली छोड़ें।

4. 4

   चुनें कि डिप्लॉय कब और कैसे हो

   When to deploy के अंतर्गत एक mode चुनें (जैसे Every push)। फिर target folder, अपने protected paths और रीस्टार्ट का व्यवहार सेट करें।

5. 5

   सेव करें

   नीचे की पट्टी में Save settings पर क्लिक करें। बस, टैब के ऊपरी हिस्से में Automatic deploys on दिखेगा, और आपका अगला push अपने-आप डिप्लॉय होगा। तुरंत डिप्लॉय करने के लिए ऊपर दाईं ओर Deploy now पर क्लिक करें।

• दूसरी रिपॉज़िटरी जोड़ें: Choose repositories on GitHub GitHub पर रिपॉज़िटरी चयन फिर से खोलता है, जहाँ आप चुनते हैं कि Daki Git Deploy किन रिपॉज़िटरी तक पहुँच सकता है।
• कनेक्शन हटाएँ: Disconnect पर क्लिक करें। इसके बाद सर्वर निजी रिपॉज़िटरी से डिप्लॉय नहीं करता।

Access Token से त्वरित शुरुआत

GitLab, Gitea और Forgejo के लिए — और GitHub के लिए भी, अगर आप चाहें — आप एक personal access token सेव करते हैं। सार्वजनिक रिपॉज़िटरी बिना किसी token के चलती हैं।

1. 1

   Git सेवा चुनें

   अपना सर्वर खोलें → Git Deploy और Git service चुनें। अपने GitLab, Gitea या Forgejo इंस्टेंस के लिए सर्वर URL दर्ज करें (जैसे https://codeberg.org या https://git.example.com)। gitlab.com के लिए इसे खाली छोड़ें।

2. 2

   रिपॉज़िटरी दर्ज करें

   रिपॉज़िटरी को path (owner/name) के रूप में लिखें या उसका वेब या clone URL सीधे paste करें। सार्वजनिक रिपॉज़िटरी के लिए बस इतना काफ़ी है — बिना token के, access box में No token – public repositories only दिखता है।

3. 3

   निजी रिपॉज़िटरी के लिए token सेव करें

   GitHub के साथ, पहले GitHub access box में Use an own access token instead पर क्लिक करें। फिर अपने Git provider पर token बनाएँ — Portal में Create a token on … लिंक आपको सीधे सही पेज पर ले जाता है — और उसे Personal access token के अंतर्गत सेव करें। Portal token को तुरंत जाँचता है। उसे जिन अधिकारों की ज़रूरत है, उनके लिए देखें Token की अनुमतियाँ।

4. 4

   अपनी सेटिंग्स चुनें और सेव करें

   चुनें कि कब डिप्लॉय हो, target folder, protected paths और रीस्टार्ट का व्यवहार, फिर Save settings पर क्लिक करें।

5. 5

   Webhook जोड़ें

   Webhook बॉक्स में Payload URL और Secret दिखते हैं, हर एक के साथ एक copy बटन। इन्हें Webhook सेट अप करें में बताए अनुसार अपनी रिपॉज़िटरी में जोड़ें। बॉक्स के नीचे Last delivery दिखाता है कि webhook पहुँच रहा है या नहीं।

6. 6

   अपने-आप डिप्लॉय चालू करें

   Automatic deploys active चालू करें।

Token की अनुमतियाँ

अगर केवल स्टेटस के लिए write अनुमति गायब है, तब भी आपका सर्वर डिप्लॉय होता है — डिप्लॉय लॉग में एक नोट दिखता है।

Webhook सेट अप करें

डिप्लॉय कब चलता है

When to deploy के अंतर्गत चार mode में से एक चुनें:

ट्रिगर

• Webhook: आपका Git provider बदलाव तुरंत बताता है, और डिप्लॉय कुछ सेकंड में शुरू हो जाता है। GitHub app के साथ यह अपने-आप होता है, आपके अपने webhook के बिना।
• अपडेट जाँच (polling): वैकल्पिक, उन मामलों के लिए जहाँ आपका Git provider Portal तक नहीं पहुँच सकता। अंतराल 5 मिनट से 1 दिन तक।
• Deploy now: कभी भी, बस एक बटन दबाकर। Release mode में आप कोई खास release चुन सकते हैं।
• push छोड़ें: commit message में [skip deploy] लिखें, तो वह push डिप्लॉय नहीं होगा। [deploy skip] और [no deploy] भी काम करते हैं।

CI चेक का इंतज़ार करें

Wait for CI checks चालू होने पर (केवल Every push mode में), कोई commit तभी डिप्लॉय होता है जब उसका CI हरा हो — GitHub Actions, GitLab CI और Gitea/Forgejo Actions समर्थित हैं। अगर CI फ़ेल होता है, तो डिप्लॉय छोड़ दिया जाता है।

सभी सेटिंग्स की व्याख्या

बदलाव तभी लागू होते हैं जब आप Save settings पर क्लिक करें। जब कुछ अनसेव हो, तो नीचे एक पट्टी Discard और Save settings दिखाती है, और Deploy now लॉक रहता है।

Remove files that were deleted from the repository केवल वही फ़ाइलें हटाता है जो किसी पिछले डिप्लॉय ने खुद लिखी थीं — कभी protected paths नहीं, और आपकी बनाई हुई फ़ाइलें भी नहीं। खाली फ़ोल्डर अपनी जगह रहते हैं।

Protected Paths

Protected paths के अंतर्गत आने वाली फ़ाइलें और फ़ोल्डर डिप्लॉय से कभी ओवरराइट या हटाए नहीं जाते। अगर वे अभी मौजूद नहीं हैं, तो एक बार बना दिए जाते हैं। गेम world, डेटाबेस और passwords के लिए आदर्श।

हर लाइन में एक नियम लिखें, जो target folder के सापेक्ष हो। खाली लाइनें और # से शुरू होने वाली लाइनें अनदेखी होती हैं। * कभी / के पार नहीं जाता।

सामान्य उदाहरण:

world/
world_nether/
world_the_end/
plugins/*/config.yml
whitelist.json
ops.json
banned-*.json

.env
*.db
*.sqlite
node_modules/
data/

.env
*.db
venv/

रीस्टार्ट का व्यवहार

If the server does not stop: कुछ प्रोग्राम, खासकर Node.js ऐप, stop सिग्नल को अनदेखा कर देते हैं। ऐसे में आपके चुने समय के बाद सर्वर को बंद करने के लिए kill किया जाता है (तुरंत, 5 सेकंड से 5 मिनट तक; डिफ़ॉल्ट Kill after 10 seconds), ताकि डिप्लॉय अटके नहीं। तुरंत kill करना सबसे तेज़ है, पर सर्वर को सेव करने का समय नहीं मिलता।

डिप्लॉय के दौरान क्या होता है

1. एक ट्रिगर (push, release, tag, अपडेट जाँच या बटन) एक डिप्लॉय बनाता है।
2. अगर Wait for CI checks चालू है, तो वह हरे CI चेक का इंतज़ार करता है (Waiting)।
3. Portal आपके Git provider से archive डाउनलोड करता है। आपके credentials कभी Portal से बाहर नहीं जाते और आपके सर्वर पर नहीं पहुँचते।
4. Archive तैयार होता है: केवल चुना हुआ फ़ोल्डर, protected paths छाँटे जाते हैं, और symbolic links जैसी असुरक्षित सामग्री हटा दी जाती है।
5. आपकी सेटिंग के अनुसार सर्वर रोका जाता है (ज़रूरत हो तो चुने समय के बाद kill किया जाता है)।
6. फ़ाइलें target folder में लिखी जाती हैं; चाहें तो हटाई गई फ़ाइलें भी हटाई जाती हैं।
7. आपकी सेटिंग के अनुसार सर्वर फिर से शुरू होता है।
8. परिणाम और पूरा लॉग इतिहास में दिखता है — और, अगर चालू है, तो commit पर स्टेटस के रूप में।

एक डिप्लॉय आमतौर पर 10–40 सेकंड लेता है, साथ में आपके सर्वर को रुकने में लगने वाला समय।

इतिहास, लॉग और रोलबैक

टैब के नीचे Deployments सूची हर डिप्लॉय को उसके स्टेटस, branch और commit (जैसे main @ 75cd0a1), नंबर, ट्रिगर, शुरू करने वाले व्यक्ति, समय और commit message के साथ दिखाती है। टैब के ऊपरी हिस्से में दिखता है कि सर्वर आखिरी बार कब डिप्लॉय हुआ था।

• लॉग: हर डिप्लॉय का एक लाइव लॉग होता है, जो डिप्लॉय चलते समय अपडेट होता रहता है। Hide log इसे फिर से बंद कर देता है।
• एक क्लिक में रोलबैक: किसी पुराने डिप्लॉय पर Deploy again पर क्लिक करें, ताकि वह स्थिति एक बार फिर लागू हो।
• रद्द करना: इंतज़ार कर रहे या scheduled डिप्लॉय रद्द किए जा सकते हैं।

एक साथ कई सर्वर डिप्लॉय कर सकते हैं, पर हर सर्वर पर एक समय में केवल एक डिप्लॉय चलता है। नया ट्रिगर, इंतज़ार कर रहे पुराने डिप्लॉय की जगह ले लेता है।

आपकी रिपॉज़िटरी में स्टेटस

Show deploys in the repository चालू होने पर आपके commit पर एक स्टेटस Daki Hosting / आपके सर्वर का नाम दिखता है: डिप्लॉय चलते समय पीला, फिर हरा निशान या लाल क्रॉस, और Git Deploy टैब का लिंक।

• GitHub पर डिप्लॉय Deployments में भी दिखता है, environment के रूप में आपके सर्वर के नाम के साथ।
• GitHub app के साथ स्टेटस Daki Git Deploy द्वारा लिखा जाता है और उसका लोगो दिखता है — कुछ और सेट करने की ज़रूरत नहीं। Token के साथ उस token के खाते की तस्वीर दिखती है, और token को write अनुमतियाँ चाहिए (देखें Token की अनुमतियाँ)।
• आप इसे हर सर्वर के लिए बंद कर सकते हैं। केवल स्टेटस और लिंक सार्वजनिक होते हैं — कोई लॉग या error विवरण नहीं।

टीम और सब-यूज़र की अनुमतियाँ

Sub-users को उनका अपना अनुमति समूह Git Deploy मिलता है:

सब-यूज़र के पास डिफ़ॉल्ट रूप से Git Deploy का कोई access नहीं होता — तय आप करते हैं कि किसे कौन सी अनुमति मिले। सर्वर का मालिक हमेशा सब कुछ कर सकता है।

सुरक्षा

• Tokens और secrets एन्क्रिप्टेड रूप में सेव होते हैं और कभी आपके browser को नहीं भेजे जाते।
• GitHub app के साथ आपका कोई लंबे समय वाला token डिप्लॉय के लिए होता ही नहीं: हर डिप्लॉय एक कम अवधि की key (1 घंटा) इस्तेमाल करता है, जो केवल आपके सर्वर की रिपॉज़िटरी तक पहुँचती है।
• आपकी अपनी GitHub पहुँच तय करती है कि आप कौन सी रिपॉज़िटरी जोड़ सकते हैं। कोई किसी दूसरे की रिपॉज़िटरी अपने सर्वर पर नहीं ला सकता।
• Webhooks हर सर्वर के अपने secret से signed होते हैं। गलत secret वाली या किसी दूसरी रिपॉज़िटरी की डिलीवरी अस्वीकार की जाती है।
• केवल वही व्यक्ति रिपॉज़िटरी बदल सकता है जिसने token सेव किया था, इसलिए सब-यूज़र मालिक के token से दूसरी निजी रिपॉज़िटरी नहीं लोड कर सकते।
• अगर आप Git service या सर्वर URL बदलते हैं, तो सेव करते समय पुराना token अपने-आप हट जाता है।
• Protected paths कभी ओवरराइट नहीं होते, और Remove files that were deleted from the repository केवल वही हटाता है जो Git Deploy ने खुद लिखा था।
• रिपॉज़िटरी में सार्वजनिक स्टेटस में कोई लॉग या error विवरण नहीं होता।

ज्ञात सीमाएँ

• हर सर्वर के लिए एक रिपॉज़िटरी और एक access।
• हर सर्वर पर एक समय में केवल एक डिप्लॉय।
• रिपॉज़िटरी में स्टेटस तभी दिखता है जब डिप्लॉय वास्तव में शुरू होता है, CI का इंतज़ार करते समय नहीं।
• Release files केवल .zip हों तो extract होती हैं; .tar.gz को फ़ाइल के रूप में अपलोड किया जाता है।
• Remove files that were deleted from the repository के बाद खाली फ़ोल्डर अपनी जगह रहते हैं।
• रिपॉज़िटरी के symbolic links डिप्लॉय नहीं होते।
• GitLab में pre-releases नहीं होते; भविष्य की तारीख वाली release को pre-release माना जाता है।
• GitLab: प्रोजेक्ट में अपलोड की गई release files (/uploads/…) निजी प्रोजेक्ट से token के साथ डाउनलोड नहीं हो सकतीं; package registry के लिंक काम करते हैं।
• Connect with GitHub केवल GitHub के लिए उपलब्ध है; GitLab, Gitea और Forgejo token इस्तेमाल करते हैं।

अक्सर पूछे जाने वाले सवाल और समस्या-निवारण

अगले कदम

• Subusers — अपनी टीम को access दें और तय करें कि डिप्लॉय कौन कर सकता है।
• Environment Variables — tokens और passwords अपनी रिपॉज़िटरी से बाहर रखें।
• Startup Settings — वह startup command सेट करें जिससे आपका डिप्लॉय किया गया कोड चलता है।
• बैकअप — अपने सर्वर के अपने-आप बैकअप Google Drive में सेव करें।