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

तपाईंले पहिले नै प्रयोग गरिरहनुभएको भण्डारबाट डिप्लोय गर्नुहोस् — यसलाई राख्नका लागि नौ ठाउँहरू

तपाईंले काम गर्ने GitHub वा GitLab खाता जडान गर्नुहोस् र कुनै शाखाबाट सिधै डिप्लोय गर्नुहोस्: Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps वा AWS Amplify मा—वा हाम्रो आफ्नै व्यवस्थित होस्टिङमा, जहाँ भण्डार (repository) र साइटका फाइलहरू दुवै दिशामा सिङ्कमा रहन्छन्। प्रत्येक जडानले आफूलाई चाहिने विशेषाधिकारहरू देखाउँछ, भण्डारण गर्नुअघि प्रदायकको API सँग प्रमाणित गरिन्छ, र Vault मा रहन्छ। तपाईं GitHub वा GitLab मार्फत पनि साइन इन गर्न सक्नुहुन्छ।

निःशुल्क सुरु गर्नुहोस्स्ट्याटिक होस्टिङ

GitHub + GitLabतपाईंसँग पहिले नै भएको खाता जडान गर्नुहोस्
नौ गन्तव्यहरूआठ एज होस्टहरू, साथै हाम्रो आफ्नै फ्लीट
दुई-तर्फी सिंकप्रत्येक साइट, प्रत्येक लाइन
Vault मा भण्डारण गरिएकोप्रविष्टिमा प्रमाणित, लगमा कहिल्यै होइन

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

एक पटक जडान गर्नुहोस्, र तपाईं के कुरामा सहमत हुँदै हुनुहुन्छ हेर्नुहोस्

जडान भनेको तपाईंले अरू कसैलाई हस्तान्तरण गरिरहनुभएको प्रमाण-पत्र हो। हाम्रो सेवाले यसलाई सिर्जना गर्नुअघि यसलाई के चाहिन्छ भनी बताउँछ, भण्डारण गर्नुअघि यसले काम गर्छ भनी प्रमाणित गर्छ, र यसलाई कुनै पनि पक्षबाट फिर्ता लिन सकिन्छ।

विशेषाधिकारहरू, अग्रिम रूपमा उल्लेख गरिएका

तपाईंले टोकन सिर्जना गर्नुअघि हामी तपाईंलाई यसले के गर्न सक्षम हुनुपर्छ र किन भनी बताउँछौं। अनुरोध गर्न सजिलो थियो भन्दैमा कुनै व्यापक दायरा हुँदैन, र कामलाई आवश्यक पर्ने भन्दा बढी हामीले चाहेका थियौं भनी पछि थाहा पाउने अवस्था पनि हुँदैन।

प्रदायकसँग प्रमाणित गरिएको, केवल विश्वासको भरमा स्वीकार नगरिएको

तपाईंको टोकन भण्डारण गर्नुअघि हामी प्रदायकको आफ्नै API लाई यस मार्फत कल गर्छौँ। गलत, म्याद सकिएको वा गलत दायरा भएको टोकन स्वीकार गरिएर, ठीक देखाइने र पहिलो वास्तविक डिप्लोयमा असफल हुने हुनुको सट्टा फाराममै अस्वीकार गरिन्छ।

Vault मा भण्डारण गरिएको, र अरू कतै होइन

हाम्रो कोडमा होइन, कुनै वातावरण फाइलमा होइन, कुनै लगमा होइन र कमाण्ड लाइनमा पनि होइन। यसलाई प्रयोग गर्ने कार्यभारद्वारा, यो प्रयोग हुने क्षणमै समाधान गरिन्छ।

एक भन्दा बढी खाता, प्रत्येक साइट अनुसार छानिएको

व्यक्तिगत खाता र संस्थाको खाता, वा दुई संस्थाहरूका खाताहरू जडान गर्नुहोस्। प्रत्येक साइटले कुनबाट डिप्लोय गर्ने भन्ने छनौट गर्छ, त्यसैले ग्राहकको भण्डार (रिपोजिटरी) र तपाईंको आफ्नैले कहिल्यै प्रमाण-पत्र (क्रेडेंशियल) साझा गर्दैनन्।

एउटा रिपोजिटरी पुग्न सक्ने नौ स्थानहरू

आठ व्यवस्थित एज होस्टहरू र हाम्रो आफ्नै फ्लीट। गन्तव्य साइटको सम्पत्ति हो, जडानको होइन, त्यसैले एउटै रिपोजिटरीले एउटा शाखालाई Pages होस्टमा प्रकाशित गर्न सक्छ र अर्को साइट हाम्रो हार्डवेयरमा चल्न सक्छ।

Cloudflare Pages

असीमित ब्यान्डविथ, व्यावसायिक प्रयोगको अनुमति, र सामान्यतया तपाईंको DNS जोन राख्ने उही प्रदायकमा व्यवस्थापन गरिने एपेक्स डोमेनहरू। यिनै कारणहरूले गर्दा यो हाम्रो पहिलो रोजाइको गन्तव्य हो।

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 डेटा सहित तपाईंको ड्यासबोर्डमा देखा पर्छ।

बाह्य साइट सीमाहरू →

वा यसलाई यहाँ सम्पादन गर्नुहोस्

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

वेब सम्पादक →

दुई-तर्फी सिंक

तपाईंको रिपोजिटरी र तपाईंको प्रत्यक्ष साइट, एकसाथ तालमेलमा

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

कुन डाइरेक्टरी सिंक गर्ने भन्ने कुरा तपाईं आफैँ छनौट गर्नुहुन्छ, किनकि एक WordPress ग्राहक आफ्नो थिम ट्र्याक गर्न चाहन्छन् न कि चालीस हजार कोर फाइलहरू। र तपाईंले यसलाई सक्रिय नगरेसम्म यो बन्द रहन्छ: सिंक सक्षम गर्नु भनेको अरू कसैको भण्डार (repository) बारेको निर्णय हो, र माइग्रेसनले यो निर्णय तपाईंको सट्टा कहिल्यै लिनु हुँदैन।

हाम्रो हार्डवेयरमा गरिएका सम्पादनहरू तपाईंको शाखामा कमिट बन्छन्
तपाईंको शाखाका कमिटहरू साइटमा फिर्ता आउँछन्
सम्पूर्ण कागजात रूट होइन, केवल एउटा निर्देशिका — थिम, प्लगइन — सिंक गर्नुहोस्
पहिले नै अवस्थित प्रत्येक साइट सहित पूर्वनिर्धारित रूपमा बन्द छ

डाइरेक्टरी प्रकाशित गर्नुहोस्, वा तपाईंको आफ्नै CI लाई यो निर्माण गर्न दिनुहोस्

दुई मोडहरू, र भिन्नता भनेको निर्माण कहाँ चल्छ भन्ने हो। दुवै एउटै ठाउँमा समाप्त हुन्छन्: हामीले ल्याउने र प्रकाशित गर्ने एउटा रेफ, जहाँ डिप्लोयको विरुद्ध कमिट रेकर्ड गरिएको हुन्छ।

प्रकाशन मोडले तपाईंको शाखालाई जस्ताको तस्तै लिन्छ र तपाईंले नाम दिनुभएको निर्देशिका प्रकाशित गर्दछ — खाली हुनुको अर्थ भण्डारको मूल हो।
CI मोडले तपाईंको प्रदायकको आफ्नै पाइपलाइनमा तपाईंको निर्माण आदेश चलाउँछ र आउटपुटलाई छुट्टै प्रकाशन शाखामा कमिट गर्छ, जसलाई हामी कुनै पनि अन्य सन्दर्भ जस्तै प्राप्त गर्छौं।
डिप्लोय प्रकाशित हुने शाखाको नाम सधैँ स्पष्ट रूपमा राखिन्छ, कहिल्यै पनि "पूर्वनिर्धारित शाखा" भनिँदैन — तपाईंलाई थाहै नदिई पूर्वनिर्धारित परिवर्तन हुन सक्छ, र कुन शाखा प्रकाशित गर्‍यो भनी खुलाउन नसक्ने इतिहास कुनै इतिहास नै होइन।
स्वतः-डिप्लोय पूर्वनिर्धारित रूपमा सक्रिय हुन्छ र वेबहुक नहर्टाइकनै यसलाई बन्द गर्न सकिन्छ, ताकि तपाईंले तिनीहरूलाई कार्य गर्न अनुमति दिनुअघि डेलिभरीहरू आएको हेर्न सक्नुहुन्छ।
प्रत्येक डिप्लोयले आफ्नो कमिट, आफ्नो परिणाम र आफ्नो समय रेकर्ड गर्दछ, र पृष्ठभूमिमा चल्छ — निर्माण पूरा भएपछि पृष्ठ अद्यावधिक हुन्छ।
विच्छेद गर्दा हामीले सिर्जना गरेको वेबहुक मात्र त्यसको id अनुसार हटाइन्छ, र तपाईंको भण्डारमा अरू केही पनि हटाइँदैन।

भण्डारबाट प्रत्यक्ष साइटमा

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

कुनै गडबडी हुँदा

“जडान भयो तर कहिल्यै डेलिभर भएन” यस्तो अवस्था हो जसको बारेमा हामी तपाईंलाई वास्तवमै जानकारी गराउनेछौं

सञ्चालनमा रहेको जस्तो देखिने तर केही पनि प्राप्त नगर्ने भण्डार (रिपोजिटरी) जडान क्लासिक मौन विफलता हो — गलत दायरा भएको टोकन, प्रदायकमा रोकिएको डेलिभरी, कसैले म्यानुअल रूपमा हटाएको हुक। यो अन्य प्रत्येक स्क्रिनमा अदृश्य हुन्छ, त्यसैले रिपोजिटरी कार्डले यसलाई प्रत्यक्ष रूपमा देखाउँछ: प्रदायकले हामीलाई अन्तिम पटक कहिले डेलिभर गर्यो, र यसले के भन्यो।

हामीले डेलिभरीहरूमा कारबाही गर्नु अघि हस्ताक्षर जाँच गरिन्छ, जसमा सबैमा लागू हुन्छ भनी हामीले मानेको नभई प्रत्येक प्रदायकको आफ्नै योजना प्रयोग गरिन्छ। प्रमाणीकरण नभएको डेलिभरीलाई शान्त रूपमा बेवास्ता नगरी अस्वीकार गरिन्छ र रेकर्ड गरिन्छ।

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

पहिचान

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 मोडमा तपाईंको प्रदायकको आफ्नै पाइपलाइनले तपाईंको बिल्ड कमाण्ड चलाउँछ र आउटपुटलाई छुट्टै पब्लिश शाखामा कमिट गर्छ, जसलाई हामीले कुनै पनि अन्य ref जस्तै फेच गर्छौं। दोस्रोले तपाईंको बिल्डलाई तपाईंको आफ्नै CI मा राख्छ, जहाँ तपाईंको गोप्य कुराहरू र क्यासिङ पहिले नै हुन्छन्।

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

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

दुई-तर्फी सिङ्क भनेको के हो?

हाम्रो हार्डवेयरमा गरिएका सम्पादनहरू तपाईंको ब्रान्चमा कमिटहरू बन्छन्, र तपाईंको ब्रान्चमा भएका कमिटहरू साइटमा फिर्ता आउँछन्। तपाईंले यसलाई अन नगरेसम्म यो अफ रहन्छ, किनकि यसलाई अन गर्नु भनेको अरू कसैको भण्डार (रिपोजिटरी) सम्बन्धी निर्णय हो र हामी तपाईंको लागि त्यो निर्णय लिने छैनौं। कुन डाइरेक्टरी सिङ्क गर्ने भन्ने तपाईंले छनौट गर्नुहुन्छ — सामान्यतया कुनै थिम वा प्लगइन, चालीस हजार WordPress कोर फाइलहरू होइनन्।

यदि दुवै पक्ष परिवर्तन भएमा के हुन्छ?

केही पनि अधिलेखन हुँदैन र केही पनि पुश हुँदैन। सिंक रोकिन्छ, हामीले आधार बनाएको कमिटभन्दा शाखा अगाडि बढेको छ भनी तपाईंलाई बताउँछ, र तपाईं कुन पक्ष चाहनुहुन्छ — भण्डार राख्ने, वा साइट राख्ने भनेर सोध्छ। कहिल्यै सिंक नभएको र पहिले नै कमिटहरू भएको शाखालाई सङ्केत गर्ने साइट पनि यसको आफ्नै स्थिति हो, र यसले कुन सत्य हो भनी अनुमान गर्नुको सट्टा सोध्छ।

मेरो पहुँच टोकन कसरी सुरक्षित गरिन्छ?

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

तपाईंले वास्तवमै मेरा पुशहरू प्राप्त गरिरहनुभएको छ कि छैन भनेर मैले कसरी थाहा पाउने?

भण्डार कार्डले प्रदायकले हामीलाई अन्तिम पटक कहिले डेलिभर गर्‍यो र यसले के भन्यो भनी देखाउँछ। त्यस स्क्रिनमा 'कहिल्यै डेलिभर नगरिएको' सबैभन्दा उपयोगी निदान हो, किनभने "जडान गरिएको तर कहिल्यै डेलिभर नगरिएको" ठ्याक्कै गलत स्कोप भएको टोकन वा अवरुद्ध डेलिभरी जस्तो देखिन्छ — र यो अरू कतै देखिँदैन। हामीले यसमा कारबाही गर्नु अघि प्रत्येक डेलिभरीको हस्ताक्षर जाँच गरिन्छ।

के म Footprint-Free लाइनमा Pages डिप्लोयमेन्ट प्रयोग गर्न सक्छु?

यो प्रस्ताव गरिएको छ र यसलाई फ्ल्याग गरिएको छ। GitHub Pages र GitLab Pages ले प्रदायक पूर्वाधार र सार्वजनिक github.io र gitlab.io होस्टनामहरू साझा गर्छन्, र त्यो एउटा पदचिन्ह (footprint) हो — जुन कुराबाट बच्न यो लाइन अवस्थित छ। शून्य-पदचिन्ह (zero-footprint) नेटवर्कको लागि, यसको सट्टा पृथक होस्टिङमा तैनाथ गर्नुहोस्। अन्य सबै ठाउँमा, Pages प्रथम श्रेणीको छ।

मैले स्पष्ट रूपमा Vercel किन रोज्नुपर्छ?

किनभने यसको नि:शुल्क स्तर गैर-व्यावसायिक प्रयोगका लागि मात्र इजाजतपत्र प्राप्त छ। सुरक्षित भएको अवस्थामा तपाईंले जडान गर्नुभएका खाताहरूबाट हामी गन्तव्य निर्धारण गर्छौं, र Vercel लाई जानाजानी त्यो निर्धारणबाट हटाइएको छ — खाता जडान गर्दा यसको इजाजतपत्रले अनुमति नदिएको ठाउँमा कुनै पनि व्यावसायिक साइट सुटुक्क राखिनु हुँदैन। यसलाई छान्नुहोस् र यसले अरू जस्तै ठ्याक्कै काम गर्छ।

के र कहिले डिप्लोय गरिएको थियो भनेर के म हेर्न सक्छु?

हो। प्रत्येक डिप्लोयले यसले प्रकाशित गरेको कमिट, यो कहिले चल्यो र कसरी समाप्त भयो भन्ने रेकर्ड राख्छ, र साइटको Deploy ट्याबले यसको छेउमा लाइभ URL सहित इतिहास देखाउँछ। डिप्लोयहरू पृष्ठभूमिमा चल्छन्, त्यसैले तपाईंलाई स्पिनर हेरेर बस्न लगाउनुको सट्टा निर्माण पूरा भएपछि पृष्ठ अपडेट हुन्छ।

सम्बन्धित

तपाईंको भण्डारबाट डिप्लोय गर्नुहोस्

कार्ड बिना १४-दिनको परीक्षण सुरु गर्नुहोस्, GitHub वा GitLab जडान गर्नुहोस्, र साइटलाई कुनै शाखामा देखाउनुहोस्। कुनै एज होस्टमा वा दुवै तर्फ फाइलहरू सिङ्क हुने हाम्रो आफ्नै होस्टिङमा प्रकाशित गर्नुहोस्।

निःशुल्क सुरु गर्नुहोस्