Basic Gitea Information

Reading time: 6 minutes

Basic Structure

बुनियादी Gitea वातावरण संरचना संस्थान(ओं) द्वारा रिपोजिटरी को समूहित करने के लिए है, जिनमें से प्रत्येक में कई रिपोजिटरी और कई टीमें हो सकती हैं। हालाँकि, ध्यान दें कि github की तरह उपयोगकर्ताओं के पास संगठन के बाहर रिपोजिटरी हो सकती हैं।

इसके अलावा, एक उपयोगकर्ता विभिन्न संगठनों का सदस्य हो सकता है। संगठन के भीतर, उपयोगकर्ता के पास प्रत्येक रिपोजिटरी पर विभिन्न अनुमतियाँ हो सकती हैं।

एक उपयोगकर्ता विभिन्न टीमों का भी भाग हो सकता है जिनके पास विभिन्न रिपोजिटरी पर विभिन्न अनुमतियाँ होती हैं।

और अंत में, रिपोजिटरी में विशेष सुरक्षा तंत्र हो सकते हैं।

Permissions

Organizations

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

Org admins (owners) संगठन की दृश्यता का चयन कर सकते हैं:

• सार्वजनिक
• सीमित (लॉग इन उपयोगकर्ताओं के लिए केवल)
• निजी (सदस्यों के लिए केवल)

Org admins यह भी संकेत कर सकते हैं कि क्या repo admins टीमों के लिए पहुंच जोड़ या हटा सकते हैं। वे अधिकतम रिपोजिटरी की संख्या भी संकेत कर सकते हैं।

नई टीम बनाते समय, कई महत्वपूर्ण सेटिंग्स चुनी जाती हैं:

• यह संकेत दिया गया है कि टीम के सदस्य किस संगठन के रिपोजिटरी तक पहुंच प्राप्त कर सकेंगे: विशिष्ट रिपोजिटरी (रिपोजिटरी जहां टीम जोड़ी गई है) या सभी।
• यह भी संकेत दिया गया है क्या सदस्य नए रिपोजिटरी बना सकते हैं (निर्माता को इसके लिए व्यवस्थापक पहुंच प्राप्त होगी)
• **रिपोजिटरी के सदस्यों के पास अनुमतियाँ होंगी:
• व्यवस्थापक पहुंच
• विशिष्ट पहुंच:

Teams & Users

एक रिपोजिटरी में, org admin और repo admins (यदि संगठन द्वारा अनुमति दी गई हो) सहयोगियों (अन्य उपयोगकर्ताओं) और टीमों को दिए गए भूमिकाओं का प्रबंधन कर सकते हैं। संभावित भूमिकाएँ 3 हैं:

• व्यवस्थापक
• लिखें
• पढ़ें

Gitea Authentication

Web Access

उपयोगकर्ता नाम + पासवर्ड का उपयोग करना और संभावित रूप से (और अनुशंसित) 2FA।

SSH Keys

आप अपने खाते को एक या एक से अधिक सार्वजनिक कुंजियों के साथ कॉन्फ़िगर कर सकते हैं जो संबंधित निजी कुंजी को आपके पक्ष में कार्य करने की अनुमति देती हैं। http://localhost:3000/user/settings/keys

GPG Keys

आप इन कुंजियों के साथ उपयोगकर्ता का प्रतिनिधित्व नहीं कर सकते लेकिन यदि आप इसका उपयोग नहीं करते हैं तो यह संभव हो सकता है कि आप बिना हस्ताक्षर के कमिट भेजने के लिए खोजे जाएं।

Personal Access Tokens

आप व्यक्तिगत पहुंच टोकन उत्पन्न कर सकते हैं ताकि एक एप्लिकेशन को आपके खाते तक पहुंच प्रदान की जा सके। एक व्यक्तिगत पहुंच टोकन आपके खाते पर पूर्ण पहुंच प्रदान करता है: http://localhost:3000/user/settings/applications

Oauth Applications

व्यक्तिगत पहुंच टोकनों की तरह Oauth applications आपके खाते और उन स्थानों पर पूर्ण पहुंच प्राप्त करेंगे जहां आपके खाते को पहुंच प्राप्त है क्योंकि, जैसा कि docs में संकेत दिया गया है, स्कोप अभी तक समर्थित नहीं हैं:

Deploy keys

Deploy keys को रिपोजिटरी के लिए केवल पढ़ने या लिखने की पहुंच हो सकती है, इसलिए वे विशिष्ट रिपोजिटरी को समझौता करने के लिए दिलचस्प हो सकते हैं।

Branch Protections

Branch protections का उद्देश्य उपयोगकर्ताओं को एक रिपोजिटरी का पूर्ण नियंत्रण नहीं देना है। लक्ष्य यह है कि कुछ शाखा के अंदर कोड लिखने में सक्षम होने से पहले कई सुरक्षा विधियाँ लगाई जाएं।

एक रिपोजिटरी की शाखा सुरक्षा https://localhost:3000/<orgname>/<reponame>/settings/branches में पाई जा सकती है।

एक शाखा पर विभिन्न सुरक्षा लागू की जा सकती हैं (जैसे कि मास्टर पर):

• Push निष्क्रिय करें: कोई भी इस शाखा पर पुश नहीं कर सकता
• Push सक्षम करें: कोई भी जिसे पहुंच प्राप्त है वह पुश कर सकता है, लेकिन बल पुश नहीं कर सकता।
• Whitelist Restricted Push: केवल चयनित उपयोगकर्ता/टीम इस शाखा पर पुश कर सकते हैं (लेकिन कोई बल पुश नहीं)
• Enable Merge Whitelist: केवल व्हाइटलिस्टेड उपयोगकर्ता/टीम PRs को मर्ज कर सकते हैं।
• Enable Status checks: मर्ज करने से पहले स्थिति जांच पास करने की आवश्यकता है।
• Require approvals: एक PR को मर्ज करने से पहले आवश्यक अनुमतियों की संख्या को इंगित करें।
• Restrict approvals to whitelisted: उन उपयोगकर्ताओं/टीमों को इंगित करें जो PRs को अनुमोदित कर सकते हैं।
• Block merge on rejected reviews: यदि परिवर्तन अनुरोध किए जाते हैं, तो इसे मर्ज नहीं किया जा सकता (भले ही अन्य जांच पास हों)
• Block merge on official review requests: यदि आधिकारिक समीक्षा अनुरोध हैं तो इसे मर्ज नहीं किया जा सकता
• Dismiss stale approvals: जब नए कमिट होते हैं, तो पुराने अनुमोदन को खारिज कर दिया जाएगा।
• Require Signed Commits: कमिट को हस्ताक्षरित होना चाहिए।
• Block merge if pull request is outdated
• Protected/Unprotected file patterns: परिवर्तनों के खिलाफ सुरक्षा/असुरक्षित करने के लिए फ़ाइलों के पैटर्न को इंगित करें