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

> अपने सर्वर को GitHub, GitLab, Gitea या Forgejo रिपॉज़िटरी से जोड़ें और हर push, release या tag पर अपने-आप डिप्लॉय करें — protected paths, रीस्टार्ट, CI चेक और एक-क्लिक रोलबैक के साथ।

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 या आपका अपना इंस्टेंस) पर एक रिपॉज़िटरी। सार्वजनिक और निजी, दोनों रिपॉज़िटरी चलती हैं।

> **नोट:** Daki हर सर्वर प्रकार (egg) के आधार पर तय करता है कि टैब दिखे या नहीं। अगर आपको **Git Deploy** नहीं दिखता, तो वह आपके सर्वर प्रकार के लिए सक्रिय नहीं है।

> **जानकारी:** यह गाइड Git Deploy टैब के अंग्रेज़ी लेबल इस्तेमाल करती है। यह टैब 19 भाषाओं में उपलब्ध है और Portal में चुनी गई भाषा का पालन करता है — बटन हर भाषा में एक ही जगह पर होते हैं।

---

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

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

**चरण 1: Git Deploy टैब खोलें**

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

**चरण 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: अपनी रिपॉज़िटरी और ब्रांच चुनें**

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

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

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

**चरण 5: सेव करें**

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

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

> **टिप:** आपको कुछ भी रिन्यू करने की ज़रूरत नहीं होती। हर डिप्लॉय के लिए Portal GitHub से एक ताज़ा, कम अवधि की key लाता है (1 घंटे तक वैध), जो केवल आपके सर्वर की एक रिपॉज़िटरी तक पहुँचती है। यह सब बैकग्राउंड में होता है।

---

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

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

**चरण 1: Git सेवा चुनें**

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

**चरण 2: रिपॉज़िटरी दर्ज करें**

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

**चरण 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 की अनुमतियाँ](#token-permissions)।

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

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

**चरण 5: Webhook जोड़ें**

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

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

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

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

| Provider | Token का प्रकार | डिप्लॉय के लिए अधिकार | रिपॉज़िटरी में स्टेटस के लिए भी ज़रूरी |
| :--- | :--- | :--- | :--- |
| GitHub | Fine-grained token, केवल इस रिपॉज़िटरी के लिए | *Contents: Read-only* (**Wait for CI checks** के लिए *Actions: Read-only* भी) | *Commit statuses* और *Deployments*: *Read and write* |
| GitLab | Personal, project या group access token | `read_api` + `read_repository` | `read_api` की जगह `api`, role Developer |
| Gitea / Forgejo | Settings → Applications | `repository: Read`, `user: Read` | `repository: Read and Write` |

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

### Webhook सेट अप करें

**GitHub**

अपनी रिपॉज़िटरी में **Settings → Webhooks → Add webhook** पर जाएँ:

1. Portal से **Payload URL** और **Secret** paste करें।
2. Content type `application/json` रखें।
3. Events के अंतर्गत **Just the push event** चुनें। Release mode में **Releases** चुनें।

**GitLab**

अपने प्रोजेक्ट में **Settings → Webhooks** पर जाएँ:

1. **Payload URL** को URL के रूप में और **Secret** को **Secret token** के अंतर्गत paste करें।
2. Triggers के अंतर्गत **Push events** चुनें। Tag mode में **Tag push events**; release mode में **Releases events** चुनें।

**Gitea / Forgejo**

अपनी रिपॉज़िटरी में **Settings → Webhooks → Add webhook** पर जाएँ और Gitea या Forgejo चुनें:

1. **Payload URL** paste करें, content type `application/json` रखें और **Secret** दर्ज करें।
2. **Push events** चुनें, या release mode में **Custom events → Release**।

> **टिप:** आपका Git provider Portal तक नहीं पहुँच सकता, जैसे इसलिए कि आपका Gitea इंस्टेंस आपके होम नेटवर्क में चलता है? तो **Also check … for updates** के अंतर्गत एक अंतराल चुनें (जैसे **Also check Gitea for updates**)। पहली जाँच वर्तमान स्थिति को एक बार डिप्लॉय करती है।

---

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

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

| Mode | क्या डिप्लॉय होता है |
| :--- | :--- |
| **Manual** | केवल तब जब कोई **Deploy now** पर क्लिक करे। |
| **Every push** | चुनी हुई ब्रांच पर हर push। |
| **Releases** | केवल तब जब कोई release प्रकाशित हो। release का **source code** या एक **release file** (जैसे `*.jar`) डिप्लॉय करें — चाहें तो किसी तय नाम के साथ सेव करें (जैसे `server.jar`) और अगर वह `.zip` है तो उसे extract भी करें। Pre-releases शामिल किए जा सकते हैं या छोड़े जा सकते हैं। |
| **Tags** | जब कोई tag push हो जो किसी pattern से मेल खाता हो, जैसे `v*`। |

### ट्रिगर

- **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 फ़ेल होता है, तो डिप्लॉय छोड़ दिया जाता है।

---

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

| Section | सेटिंग | वह क्या करती है |
| :--- | :--- | :--- |
| Repository | **Git service** | GitHub, GitLab, Gitea या Forgejo |
| Repository | **Server URL** | केवल self-hosted इंस्टेंस के लिए; इंटरनेट से पहुँच योग्य होना चाहिए |
| Repository | **Repository** | `owner/name` या URL; **Choose from my repositories** सूची दिखाता है |
| Repository | **Branch** | खाली = डिफ़ॉल्ट ब्रांच; **Load branches** सूची दिखाता है |
| When to deploy | **Manual** / **Every push** / **Releases** / **Tags** | देखें [डिप्लॉय कब चलता है](#when-a-deploy-runs) |
| When to deploy | **Wait for CI checks** | केवल **Every push** के साथ |
| When to deploy | **Include pre-releases**, **What to deploy** (**Source code** / **Release file**), **Save as**, **Extract .zip files instead of uploading them** | केवल **Releases** के साथ |
| When to deploy | **Tag pattern** | केवल **Tags** के साथ, जैसे `v*`; खाली = हर tag |
| When to deploy | **Also check … for updates** (आपकी Git service के नाम पर, जैसे **Also check GitHub for updates**) | Polling: **Never (webhook only)**, 5/10/15/30 मिनट, 1/3/6/12/24 घंटे |
| When to deploy | **Automatic deploys active** | बंद करने से webhook और polling रुक जाते हैं; **Deploy now** काम करता रहता है |
| When to deploy | **Show deploys in the repository** | commit पर स्टेटस, देखें [रिपॉज़िटरी में स्टेटस](#status-in-your-repository) |
| Files | **Folder in the repository** | केवल कोई subfolder डिप्लॉय करें, जैसे `dist`; खाली = सब कुछ |
| Files | **Target folder on the server** | फ़ाइलें कहाँ जाएँ; `/` = आपके सर्वर का मुख्य फ़ोल्डर |
| Files | **Protected paths** | हर लाइन में एक नियम, देखें [Protected paths](#protected-paths) |
| Files | **Remove files that were deleted from the repository** | वैकल्पिक clean-up, नीचे देखें |
| Restart | **Restart if running** / **Always start** / **Do not restart** | देखें [रीस्टार्ट का व्यवहार](#restart-behavior) |
| Restart | **If the server does not stop** | तुरंत kill, या 5 s, 10 s (डिफ़ॉल्ट: **Kill after 10 seconds**), 15 s, 30 s, 1 min, 2 min या 5 min |

बदलाव तभी लागू होते हैं जब आप **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` है, किसी भी गहराई पर |
| `/world/` | केवल target folder के भीतर सीधा `world` |
| `*.db` | हर फ़ाइल जिसका अंत `.db` से हो, कहीं भी |
| `.env` | हर फ़ाइल जिसका नाम `.env` है, कहीं भी |
| `/config.yml` | केवल target folder में सीधी `config.yml` |
| `plugins/*/config.yml` | `plugins` के हर सीधे subfolder में `config.yml` |

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

**Minecraft**

```

world/

world_nether/

world_the_end/

plugins/*/config.yml

whitelist.json

ops.json

banned-*.json

```

**Discord बॉट / Node.js**

```

.env

*.db

*.sqlite

node_modules/

data/

```

**Python**

```

.env

*.db

venv/

```

---

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

| विकल्प | क्या होता है |
| :--- | :--- |
| **Restart if running** | फ़ाइलें लिखे जाने से पहले सर्वर रोका जाता है और बाद में फिर से शुरू होता है। जो सर्वर बंद है, वह बंद ही रहता है। |
| **Always start** | ऊपर की तरह, और डिप्लॉय के बाद बंद सर्वर भी शुरू हो जाता है। |
| **Do not restart** | सर्वर चलता रहता है और फ़ाइलें उसी दौरान बदली जाती हैं। |

**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 के साथ दिखाती है। टैब के ऊपरी हिस्से में दिखता है कि सर्वर आखिरी बार कब डिप्लॉय हुआ था।

| स्टेटस | अर्थ |
| :--- | :--- |
| **Waiting** | CI चेक का इंतज़ार |
| **Scheduled** | कतार में, जल्द शुरू होगा |
| **Running** | डिप्लॉय चल रहा है |
| **Deployed** | सफलतापूर्वक पूरा हुआ |
| **Failed** | कुछ गड़बड़ हुई — लॉग में कारण दिखता है |
| **Skipped** | डिप्लॉय नहीं हुआ, जैसे CI फ़ेल होने या commit में `[skip deploy]` होने के कारण |
| **Cancelled** | शुरू होने से पहले रद्द किया गया |

- **लॉग:** हर डिप्लॉय का एक लाइव लॉग होता है, जो डिप्लॉय चलते समय अपडेट होता रहता है। **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 की अनुमतियाँ](#token-permissions))।
- आप इसे हर सर्वर के लिए बंद कर सकते हैं। केवल स्टेटस और लिंक सार्वजनिक होते हैं — कोई लॉग या error विवरण नहीं।

---

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

[Sub-users](https://daki.cc/hi/wiki/guides/subusers) को उनका अपना अनुमति समूह **Git Deploy** मिलता है:

| अनुमति | क्या देती है |
| :--- | :--- |
| **view** (`github.read`) | सेटिंग्स, webhook पता और लॉग के साथ इतिहास देखना |
| **deploy** (`github.deploy`) | **Deploy now**, **Deploy again** और डिप्लॉय रद्द करना |
| **change settings** (`github.update`) | रिपॉज़िटरी, access, webhook और सभी सेटिंग्स |

सब-यूज़र के पास डिफ़ॉल्ट रूप से 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 इस्तेमाल करते हैं।

---

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

**क्या मुझे अपना token नियमित रूप से रिन्यू करना होगा?**

GitHub app के साथ नहीं: Portal हर डिप्लॉय के लिए अपने-आप एक ताज़ा key लाता है। अपना token उतने समय तक वैध रहता है जितना आपने उसे Git provider पर बनाते समय चुना था; जब वह एक्सपायर हो, तो बस एक नया सेव करें।

**मेरी रिपॉज़िटरी सूची में नहीं है (GitHub app)**

**Choose repositories on GitHub** पर क्लिक करें और app को उस रिपॉज़िटरी तक पहुँच की अनुमति दें।

**डिप्लॉय Scheduled पर ही अटका रहता है**

थोड़ा इंतज़ार करें। अगर कुछ मिनटों से ज़्यादा ऐसा ही रहता है, तो कृपया [support से संपर्क करें](https://daki.cc/hi/wiki/guides/support)।

**वेबहुक नहीं पहुँचता, या GitHub में error 401 दिखता है**

Secret मेल नहीं खा रहा। Portal में secret कॉपी करें और उसे webhook में फिर से दर्ज करें। **New secret** एक नया secret बनाता है — तब उसे अपने Git provider पर भी बदलें।

**मेरा डिप्लॉय क्यों छोड़ा गया?**

संभावित कारण: CI चेक फ़ेल हुए, commit message में `[skip deploy]` है, या एक नए ट्रिगर ने इंतज़ार कर रहे डिप्लॉय की जगह ले ली। कारण डिप्लॉय की पंक्ति में दिखाया जाता है।

**मुझे अपने commit पर स्टेटस नहीं दिखता**

**Show deploys in the repository** चालू होना चाहिए। Token के साथ token को write अनुमतियाँ भी चाहिए (देखें [Token की अनुमतियाँ](#token-permissions)) — डिप्लॉय लॉग कारण दिखाता है।

**डिप्लॉय “The node rejected the request” के साथ फ़ेल होता है**

आपके सर्वर प्रकार में कुछ फ़ाइलें अनुमत नहीं हैं, या डिस्क भर चुकी है। विवरण लॉग में दिखते हैं।

**मेरे अपने Gitea इंस्टेंस का URL अस्वीकार हो रहा है**

Self-hosted इंस्टेंस इंटरनेट से पहुँच योग्य होने चाहिए। `192.168.x.x` जैसे होम नेटवर्क के पते काम नहीं करते।

**रोलबैक कैसे करूँ?**

इतिहास में, जिस पुराने डिप्लॉय पर आप लौटना चाहते हैं, उस पर **Deploy again** पर क्लिक करें।

**क्या मेरी गेम world या डेटाबेस ओवरराइट होगी?**

नहीं, अगर वे **Protected paths** में लिखी हैं (जैसे `world/` या `*.db`)।

**मेरी टीम में कौन डिप्लॉय कर सकता है?**

केवल वे लोग जिनके पास सर्वर की सब-यूज़र सेटिंग्स के **Git Deploy** समूह में **deploy** अनुमति है। सर्वर का मालिक हमेशा सब कुछ कर सकता है।

---

## अगले कदम

- [Subusers](https://daki.cc/hi/wiki/guides/subusers) — अपनी टीम को access दें और तय करें कि डिप्लॉय कौन कर सकता है।
- [Environment Variables](https://daki.cc/hi/wiki/guides/environment-variables) — tokens और passwords अपनी रिपॉज़िटरी से बाहर रखें।
- [Startup Settings](https://daki.cc/hi/wiki/guides/startup-settings) — वह startup command सेट करें जिससे आपका डिप्लॉय किया गया कोड चलता है।
- [बैकअप](https://daki.cc/hi/wiki/guides/backups) — अपने सर्वर के अपने-आप बैकअप Google Drive में सेव करें।

---
Source: https://daki.cc/hi/wiki/guides/git-deploy