स्रोत नियंत्रण

उस रिपॉजिटरी से डिप्लॉय करें जिसका आप पहले से उपयोग करते हैं — इसे रखने के लिए नौ स्थान

उस GitHub या GitLab खाते को कनेक्ट करें जिसमें आप काम करते हैं और सीधे किसी ब्रांच से डिप्लॉय करें: Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps या AWS Amplify पर — या हमारी अपनी प्रबंधित होस्टिंग पर, जहाँ रिपॉजिटरी और साइट की फ़ाइलें दोनों दिशाओं में सिंक रहती हैं। प्रत्येक कनेक्शन उन विशेषाधिकारों को प्रदर्शित करता है जिनकी उसे आवश्यकता होती है, संग्रहीत होने से पहले प्रदाता के API के साथ जांचा जाता है, और Vault में रहता है। आप GitHub या GitLab से भी साइन इन कर सकते हैं।

एक कमिट जो रिपॉजिटरी से पाइपलाइन के माध्यम से लाइव साइट पर जा रहा है।
  • GitHub + GitLabउस खाते को कनेक्ट करें जो आपके पास पहले से है
  • नौ गंतव्यआठ एज होस्ट, साथ ही हमारा अपना बेड़ा
  • द्वि-मार्गी सिंकप्रत्येक साइट, प्रत्येक पंक्ति
  • Vault में संग्रहीतप्रविष्टि पर मान्य किया गया, लॉग में कभी नहीं
  • संग्रहीत करने से पहले टोकन की जाँच की गईअत्यधिक दायरे वाला टोकन कभी लागू नहीं होता
  • तैनात करने के लिए पुश करेंहस्ताक्षर-सत्यापित और वैकल्पिक
  • आपकी शाखा, आपका बिल्डएक निर्देशिका प्रकाशित करें या अपना स्वयं का CI चलाएं
  • सावधानीपूर्वक डिस्कनेक्ट करेंहम ठीक उसी हुक को हटाते हैं जिसे हमने बनाया था

एक बार कनेक्ट करें, और देखें कि आप क्या स्वीकार कर रहे हैं

कनेक्शन एक क्रेडेंशियल है जिसे आप किसी अन्य को सौंप रहे हैं। हमारा कनेक्शन इसे बनाने से पहले बताता है कि इसे क्या चाहिए, इसे संग्रहीत करने से पहले साबित करता है कि यह काम करता है, और इसे दोनों में से किसी भी तरफ से वापस लिया जा सकता है।

विशेषाधिकार, पहले से स्पष्ट रूप से बताए गए

टोकन बनाने से पहले हम आपको बताते हैं कि इसे क्या करने में सक्षम होना चाहिए और क्यों। केवल इसलिए कोई व्यापक दायरा नहीं क्योंकि उसका अनुरोध करना आसान था, और काम के बाद यह पता चलने की कोई गुंजाइश नहीं कि हमें काम की ज़रूरत से ज़्यादा चाहिए था।

प्रदाता के साथ सत्यापित किया गया, केवल भरोसे पर स्वीकार नहीं किया गया

हम आपके टोकन को संग्रहीत करने से पहले प्रदाता के अपने API को इसके साथ कॉल करते हैं। एक गलत, समाप्त हो चुका या गलत स्कोप वाला टोकन स्वीकार किए जाने, सही दिखने और पहले वास्तविक परिनियोजन पर विफल होने के बजाय फॉर्म पर ही अस्वीकार कर दिया जाता है।

Vault में संग्रहीत, और कहीं नहीं

न हमारे कोड में, न किसी परिवेश फ़ाइल में, न किसी लॉग में और न ही कमांड लाइन पर। इसका समाधान उसी क्षण किया जाता है जब इसका उपयोग किया जाता है, उस कार्यभार द्वारा जो इसका उपयोग करता है।

एक से अधिक खाते, प्रत्येक साइट के लिए चुने गए

एक व्यक्तिगत खाता और किसी संगठन का खाता, या दो संगठनों के खाते कनेक्ट करें। प्रत्येक साइट चुनती है कि वह किससे डिप्लॉय करे, ताकि किसी क्लाइंट का रिपॉजिटरी और आपका अपना कभी भी क्रेडेंशियल साझा न करें।

नौ स्थान जहाँ कोई रिपॉजिटरी जा सकती है

आठ प्रबंधित एज होस्ट और हमारा अपना बेड़ा। गंतव्य साइट का एक गुण है, कनेक्शन का नहीं, इसलिए वही रिपॉजिटरी एक शाखा को Pages होस्ट पर प्रकाशित कर सकती है और दूसरी साइट हमारे हार्डवेयर पर चल सकती है।

Cloudflare Pages

असीमित बैंडविड्थ, व्यावसायिक उपयोग की अनुमति, और आमतौर पर आपके डीएनएस ज़ोन को प्रबंधित करने वाले प्रदाता पर ही एपेक्स डोमेन का प्रबंधन। इन्हीं कारणों से यह हमारा पहला पसंदीदा विकल्प है।

Cloudflare Pages होस्टिंग →

GitHub Pages

सीधे उसी रिपॉजिटरी से प्रकाशित करें जिसमें कोड पहले से मौजूद है। Footprint-Free पंक्ति पर चिह्नित किया गया है, क्योंकि साझा किया गया github.io इंफ्रास्ट्रक्चर स्वयं एक फुटप्रिंट है।

GitHub Pages होस्टिंग →

GitLab Pages, Netlify, Vercel और बाकी

GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps और AWS Amplify वे सभी गंतव्य हैं जिनकी ओर आप उसी कनेक्शन और उसी डिप्लॉय इतिहास के साथ किसी साइट को इंगित कर सकते हैं।

स्टैटिक साइट होस्टिंग →

हमारी अपनी प्रबंधित होस्टिंग

एक निर्मित बंडल के बजाय एक संपूर्ण एप्लिकेशन — WordPress, PHP, Node। यह वह गंतव्य है जिसे दो-तरफ़ा सिंक प्राप्त होता है, ताकि बॉक्स और ब्रांच की फ़ाइलें एक साथ तालमेल में रहें।

प्रबंधित होस्टिंग →

किसी अन्य के एज पर स्थित साइटें

हमारे स्वामित्व में न होने वाले होस्ट पर प्रकाशित की गई साइट भी कोटा का उपयोग करती है और आपके द्वारा चलाए जा रहे अन्य सभी चीज़ों के साथ-साथ अपने डिप्लॉयमेंट, अपने अपटाइम और अपने SEO डेटा के साथ आपके डैशबोर्ड में दिखाई देती है।

बाहरी साइट भत्ते →

या इसे यहाँ संपादित करें

इन-ब्राउज़र एडिटर उन्हीं फ़ाइलों पर काम करता है जिन्हें टू-वे सिंक वापस पुश करता है, ताकि डैशबोर्ड से किया गया एक त्वरित सुधार बाद में किसी के द्वारा न खोजे जा सकने वाले बदलाव के बजाय आपकी ब्रांच पर एक कमिट बन जाए।

वेब संपादक →

द्वि-मार्गी सिंक

आपकी रिपॉजिटरी और आपकी लाइव साइट, एक साथ कदम से कदम मिलाकर

इसे चालू करें और साइट की अपनी फ़ाइलें आपकी शाखा में वापस कमिट हो जाएँगी, जबकि उस शाखा के कमिट वापस साइट पर आ जाएँगे। यह हमारे द्वारा होस्ट की जाने वाली प्रत्येक साइट पर, प्रत्येक पंक्ति पर काम करता है — एकमात्र आवश्यकता यह है कि अंतर्निहित मशीन अपनी फ़ाइलों के विरुद्ध Git चला सके, जिसे योजना से मान लेने के बजाय सर्वर से पूछा जाता है।

आप चुनते हैं कि कौन सी डायरेक्टरी सिंक होगी, क्योंकि एक WordPress ग्राहक अपनी थीम को ट्रैक करना चाहता है, न कि चालीस हज़ार कोर फ़ाइलों को। और जब तक आप इसे चालू नहीं करते, यह बंद रहता है: सिंक सक्षम करना किसी अन्य व्यक्ति के रिपॉजिटरी के बारे में लिया गया निर्णय है, और माइग्रेशन को आपके लिए यह निर्णय कभी नहीं लेना चाहिए।

  • हमारे हार्डवेयर पर किए गए संपादन आपकी शाखा पर कमिट बन जाते हैं
  • आपकी शाखा (ब्रांच) के कमिट वापस साइट पर आ जाते हैं
  • केवल एक डायरेक्टरी सिंक करें — कोई थीम, कोई प्लगइन — न कि पूरा डॉक्यूमेंट रूट
  • डिफ़ॉल्ट रूप से बंद, उन सभी साइटों पर भी जो पहले से मौजूद हैं
संपादक में खुली हुई एक फ़ाइल, जिसमें वही फ़ाइल किसी रिपॉजिटरी में कमिट के रूप में दिखाई गई है।

कोई डायरेक्टरी प्रकाशित करें, या अपने स्वयं के CI को इसे बनाने दें

दो मोड, और अंतर यह है कि बिल्ड कहाँ चलता है। दोनों एक ही जगह समाप्त होते हैं: एक संदर्भ जिसे हम लाते हैं और प्रकाशित करते हैं, जिसमें परिनियोजन के सापेक्ष कमिट दर्ज होता है।

  • प्रकाशन मोड आपकी शाखा को वैसे ही लेता है जैसी वह है और आपके द्वारा निर्दिष्ट निर्देशिका को प्रकाशित करता है — खाली का अर्थ रिपॉजिटरी रूट है।
  • CI मोड आपके प्रदाता की अपनी पाइपलाइन में आपका बिल्ड कमांड चलाता है और आउटपुट को एक अलग प्रकाशन शाखा में कमिट करता है, जिसे हम किसी अन्य संदर्भ की तरह प्राप्त करते हैं।
  • डिप्लॉय जिस शाखा से प्रकाशित होता है उसका नाम हमेशा स्पष्ट रूप से दिया जाता है, कभी भी "डिफ़ॉल्ट शाखा" नहीं — एक डिफ़ॉल्ट आपके अनजाने में बदल सकता है, और ऐसा इतिहास जो यह न बता सके कि उसने किस शाखा को प्रकाशित किया है, वह कोई इतिहास नहीं है।
  • ऑटो-डिप्लॉय डिफ़ॉल्ट रूप से चालू रहता है और वेबहुक को हटाए बिना इसे बंद किया जा सकता है, ताकि आप डिलीवरी को सक्रिय होने की अनुमति देने से पहले उनके आगमन पर नज़र रख सकें।
  • प्रत्येक डिप्लॉय अपने कमिट, अपने परिणाम और अपने समय को रिकॉर्ड करता है, और बैकग्राउंड में चलता है — बिल्ड पूरा होने पर पेज अपडेट हो जाता है।
  • डिस्कनेक्ट करने से केवल हमारे द्वारा बनाया गया वेबहुक ही उसकी id के माध्यम से हटाया जाता है, और आपकी रिपॉजिटरी में कुछ भी अन्य नहीं हटाया जाता।

रिपॉजिटरी से लाइव साइट तक

  1. खाता कनेक्ट करें

    GitHub या GitLab, कनेक्शंस के अंतर्गत। टोकन बनाने से पहले विशेषाधिकार सूचीबद्ध होते हैं और संग्रहीत किए जाने से पहले प्रदाता से इसकी जांच की जाती है।

  2. किसी साइट को रिपॉजिटरी पर इंगित करें

    मालिक, रिपॉजिटरी, शाखा, और क्या हम कोई डायरेक्टरी प्रकाशित करते हैं या आपके CI द्वारा निर्मित सामग्री लाते हैं। हम इसके हिस्से के रूप में पुश वेबहुक पंजीकृत करते हैं।

  3. धकेलें, या बटन दबाएं

    नामित शाखा में पुश करने से डिप्लॉय शुरू हो जाता है, या आप साइट के डिप्लॉय टैब से मांग पर डिप्लॉय कर सकते हैं। बिल्ड पृष्ठभूमि में चलते हैं।

  4. इसे देखें, और यदि आप चाहें तो वापस सिंक करें

    डिप्लॉय इतिहास दिखाता है कि क्या और कब प्रकाशित किया गया था। दो-तरफ़ा सिंक चालू करें और यहाँ आपके द्वारा किए गए संपादन आपकी शाखा पर कमिट के रूप में वापस आ जाएँगे।

जब कुछ गड़बड़ हो

“कनेक्ट हुआ लेकिन कभी डिलीवर नहीं हुआ” एक ऐसी स्थिति है जिसके बारे में हम आपको वास्तव में सूचित करेंगे

एक रिपॉजिटरी कनेक्शन जो सामान्य दिखता है और कुछ भी प्राप्त नहीं करता है, वह क्लासिक साइलेंट विफलता है — गलत स्कोप वाला टोकन, प्रदाता पर अवरुद्ध डिलीवरी, किसी व्यक्ति द्वारा मैन्युअल रूप से हटाया गया हुक। यह अन्य हर स्क्रीन पर अदृश्य होता है, इसलिए रिपॉजिटरी कार्ड इसे सीधे दर्शाता है: प्रदाता ने अंतिम बार हमें कब डिलीवरी की, और उसने क्या कहा।

हम डिलीवरी पर कार्रवाई करने से पहले उनके हस्ताक्षर की पुष्टि करते हैं, जिसमें प्रत्येक प्रदाता की अपनी योजना का उपयोग किया जाता है, न कि ऐसी योजना जिसे हमने सभी के लिए लागू मान लिया हो। जिस डिलीवरी का सत्यापन नहीं होता है, उसे चुपचाप अनदेखा करने के बजाय अस्वीकार कर दर्ज किया जाता है।

  • अंतिम डिलीवरी का समय और संदेश, कार्ड पर
  • "कभी डिलीवर नहीं किया गया" दर्शाया गया है, खाली नहीं छोड़ा गया है
  • कुछ भी चलने से पहले प्रत्येक प्रदाता के अनुसार हस्ताक्षर सत्यापित किए गए
  • जब आप डिस्कनेक्ट करते हैं तो हमारे द्वारा बनाया गया हुक आईडी द्वारा हटा दिया जाता है
किसी भी चीज़ को ट्रिगर करने से पहले वेबहुक डिलीवरी का आना और उसकी जांच होना।

पहचान

GitHub या GitLab के साथ साइन इन करें — या Google, या Microsoft

ईमेल पते और पासवर्ड के अलावा, आप GitHub, GitLab, Google या Microsoft के साथ अपने Zinn Digital® खाते में साइन इन कर सकते हैं। पहचान स्तर (आइडेंटिटी लेयर) हैंडशेक को निष्पादित करता है; हम आपका प्रदाता पासवर्ड कभी नहीं देखते हैं, और किसी मौजूदा Zinn® खाते से सोशल खाते को लिंक करने की पुष्टि अभी भी ईमेल द्वारा की जानी आवश्यक है।

GitHub के साथ साइन इन करना और डिप्लॉय के लिए GitHub को कनेक्ट करना अलग-अलग निर्णय और अलग-अलग क्रेडेंशियल हैं। एक को करने से दूसरा नहीं होता है, और एक को हटाने से दूसरा नहीं हटता है।

  • GitHub, GitLab, Google और Microsoft साइन-इन
  • एक ही खाते पर पासकी और दो-चरणीय प्रमाणीकरण
  • साइन-इन और डिप्लॉय क्रेडेंशियल अलग रहते हैं
आपकी टीम के लिए प्रत्यायोजित पहुंच
विभिन्न प्रदाताओं के माध्यम से एक ही खाते में साइन इन करने वाले कई लोग।

अक्सर पूछे जाने वाले प्रश्न

मैं कौन से स्रोत-नियंत्रण प्रदाताओं को कनेक्ट कर सकता हूँ?

GitHub और GitLab। उस खाते को कनेक्ट करें जिसमें आप पहले से काम करते हैं और हम उसके रिपॉजिटरी से डिप्लॉय कर सकते हैं, उन पर एक पुश वेबहुक रजिस्टर कर सकते हैं, और — यदि आप चाहें — तो अपनी साइट की फ़ाइलों को दूसरी दिशा में वापस सिंक कर सकते हैं। दोनों एक ही कनेक्टेड-अकाउंट तंत्र से होकर गुजरते हैं, इसलिए नीचे दी गई हर बात दोनों पर लागू होती है।

क्या मैं GitHub या GitLab से साइन इन कर सकता हूँ?

हाँ, और Google या Microsoft के साथ भी। ईमेल पते और पासवर्ड के अलावा, आप इन चारों में से किसी के भी साथ अपने Zinn Digital® खाते में साइन इन कर सकते हैं। पहचान परत हैंडशेक को संभालती है और हम आपके प्रदाता का पासवर्ड कभी नहीं देखते हैं। GitHub से साइन इन करना डिप्लॉय के लिए GitHub को कनेक्ट करने से अलग प्रक्रिया है — आप कोई एक, दोनों, या कुछ भी नहीं चुन सकते हैं।

मैं रिपॉजिटरी कहाँ डिप्लॉय कर सकता हूँ?

किसी स्थिर या निर्मित साइट के लिए Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps या AWS Amplify पर — या हमारे अपने प्रबंधित होस्टिंग पर, जहाँ रिपॉजिटरी और साइट की फ़ाइलें दोनों दिशाओं में समन्वयित रहती हैं। आप साइट के लिए गंतव्य चुनते हैं; रिपॉजिटरी कनेक्शन दोनों ही तरह से समान रहता है।

क्या आप मेरी साइट बना सकते हैं, या इसे पहले से बना हुआ होना चाहिए?

दोनों में से कोई भी। पब्लिश मोड में हम शाखा को वैसे ही लेते हैं जैसी वह है और आपके द्वारा निर्दिष्ट निर्देशिका को प्रकाशित करते हैं। CI मोड में आपके प्रदाता की अपनी पाइपलाइन आपके बिल्ड कमांड को चलाती है और आउटपुट को एक अलग पब्लिश शाखा में कमिट करती है, जिसे हम किसी भी अन्य संदर्भ की तरह प्राप्त करते हैं। दूसरा विकल्प आपके बिल्ड को आपके अपने CI में रखता है, जहाँ आपके सीक्रेट्स और आपकी कैशिंग पहले से मौजूद हैं।

क्या पुश स्वचालित रूप से डिप्लॉय होता है?

डिफ़ॉल्ट रूप से, हाँ — हम रिपॉजिटरी पर एक वेबहुक पंजीकृत करते हैं और आपके द्वारा नामित शाखा में पुश करने से डिप्लॉय शुरू हो जाता है। आप इसे बंद कर सकते हैं और वेबहुक रख सकते हैं, जो सुनने में जितना लगता है उससे कहीं अधिक उपयोगी है: डिलीवरी अभी भी रिकॉर्ड की जाती है, ताकि आप हमें उन पर कार्रवाई करने की अनुमति देने से पहले अपने पुश आते हुए देख सकें।

टू-वे सिंक क्या है?

हमारे हार्डवेयर पर किए गए संपादन आपकी ब्रांच पर कमिट बन जाते हैं, और आपकी ब्रांच के कमिट वापस साइट पर आ जाते हैं। यह तब तक बंद रहता है जब तक आप इसे चालू नहीं करते, क्योंकि इसे चालू करना किसी अन्य व्यक्ति के रिपॉजिटरी से जुड़ा निर्णय है और हम यह निर्णय आपके लिए नहीं लेंगे। आप चुनते हैं कि कौन सी डायरेक्टरी सिंक होगी — आमतौर पर कोई थीम या प्लगइन, न कि चालीस हज़ार WordPress कोर फ़ाइलें।

यदि दोनों पक्ष बदल गए तो क्या होगा?

कुछ भी ओवरराइट नहीं किया जाता है और कुछ भी पुश नहीं किया जाता है। सिंक रुक जाता है, आपको बताता है कि शाखा उस कमिट से आगे निकल गई है जिस पर हम आधारित थे, और पूछता है कि आप कौन सा पक्ष चाहते हैं — रिपॉजिटरी रखें, या साइट रखें। ऐसी साइट जो कभी सिंक नहीं हुई है और ऐसी शाखा की ओर इंगित करती है जिसमें पहले से ही कमिट हैं, वह भी अपनी एक स्थिति है, और यह अनुमान लगाने के बजाय पूछती है कि कौन सा सही है।

मेरा एक्सेस टोकन कैसे सुरक्षित है?

हम आपको कनेक्शन बनाने से पहले उसकी आवश्यक अनुमतियां दिखाते हैं, दर्ज करते समय प्रदाता के अपने API से टोकन की जांच करते हैं — ताकि अमान्य या गलत दायरे वाला टोकन कभी भी संग्रहीत न हो — और उसके बाद ही इसे Vault में लिखते हैं। यह कभी भी हमारे कोड, लॉग, पर्यावरण फ़ाइल या कमांड लाइन को स्पर्श नहीं करता है। जब भी आप चाहें इसे प्रदाता के पास रद्द करें या यहां से कनेक्शन हटाएं।

मुझे कैसे पता चलेगा कि क्या आप वास्तव में मेरे पुश प्राप्त कर रहे हैं?

रिपॉजिटरी कार्ड दिखाता है कि प्रदाता ने पिछली बार हमें कब डिलीवरी की थी और उसमें क्या कहा गया था। उस स्क्रीन पर "कभी डिलीवर नहीं हुआ" सबसे उपयोगी डायग्नोस्टिक है, क्योंकि "कनेक्टेड लेकिन कभी डिलीवर नहीं हुआ" बिल्कुल गलत-स्कोप वाले टोकन या ब्लॉक की गई डिलीवरी जैसा दिखता है — और यह कहीं और दिखाई नहीं देता है। हम उस पर कार्रवाई करने से पहले प्रत्येक डिलीवरी के हस्ताक्षर की जांच करते हैं।

क्या मैं Footprint-Free लाइन पर Pages डिप्लॉयमेंट का उपयोग कर सकता हूँ?

यह उपलब्ध कराया गया है और चिह्नित किया गया है। GitHub Pages और GitLab Pages प्रदाता के बुनियादी ढांचे और सार्वजनिक github.io तथा gitlab.io होस्टनाम साझा करते हैं, और यह सर्च इंजन के लिए एक फुटप्रिंट है — ठीक वही चीज़ जिससे बचने के लिए यह व्यवस्था बनाई गई है। बिना किसी फुटप्रिंट वाले नेटवर्क के लिए, इसके बजाय अलग होस्टिंग पर डिप्लॉय करें। बाकी सभी जगहों पर, Pages सर्वोत्तम है।

मुझे स्पष्ट रूप से Vercel को क्यों चुनना होगा?

क्योंकि इसका निःशुल्क स्तर केवल गैर-व्यावसायिक उपयोग के लिए लाइसेंस प्राप्त है। जहां सुरक्षित हो, हम आपके द्वारा कनेक्ट किए गए खातों से गंतव्य का अनुमान लगाते हैं, और Vercel को जानबूझकर उस अनुमान से बाहर रखा गया है — खाता कनेक्ट करने से कभी भी किसी व्यावसायिक साइट को चुपचाप ऐसी जगह नहीं रखा जाना चाहिए जहां उसका लाइसेंस अनुमति नहीं देता हो। इसे चुनें और यह बिल्कुल दूसरों की तरह काम करता है।

क्या मैं देख सकता हूँ कि क्या और कब परिनियोजित किया गया था?

हाँ। प्रत्येक डिप्लॉय यह रिकॉर्ड करता है कि उसने कौन-सा कमिट प्रकाशित किया, यह कब चला और यह कैसे समाप्त हुआ, और साइट का डिप्लॉय टैब इसके बगल में लाइव URL के साथ इतिहास दिखाता है। डिप्लॉय पृष्ठभूमि में चलते हैं, इसलिए आपको स्पिनर के सामने प्रतीक्षा कराने के बजाय बिल्ड पूरा होते ही पृष्ठ अपडेट हो जाता है।

अपने रिपॉजिटरी से डिप्लॉय करें

बिना कार्ड के 14-दिवसीय परीक्षण शुरू करें, GitHub या GitLab कनेक्ट करें, और किसी साइट को एक ब्रांच पर इंगित करें। फ़ाइलों के दोनों तरफ सिंक होने के साथ किसी एज होस्ट पर, या हमारी अपनी होस्टिंग पर प्रकाशित करें।

मुफ़्त शुरू करें