क्या कर्मचारियों से 'काम' गिटहब खाते बनाने के लिए पूछना उचित है?

Question

मैंने अपनी सभी कंपनी Git रिपॉजिटरी को GitHub में स्थानांतरित कर दिया है और अब मैं कर्मचारियों को परियोजनाओं में जोड़ना चाहता हूं। ज्यादातर कर्मचारियों को पहले से ही व्यक्तिगत GitHub खाते हैं के बाद से, मैं सोच रहा हूँ कि क्या मैं एक बनाने के लिए उन्हें पूछना चाहिए काम GitHub खाते। कारण यह है कि मैं ऐसा करने के बारे में सोच रहा हूं, हमारे कोड आधार पर अनधिकृत पहुंच की संभावना को कम करना है क्योंकि साइट पर उनकी व्यक्तिगत गतिविधियों के माध्यम से अच्छी तरह से प्रचारित किया जा सकता है, लक्षित हमलों की संभावना बढ़ सकती है। इसके अलावा, यदि उनके व्यक्तिगत खाते से कभी समझौता किया जाता है तो इसका मतलब यह नहीं होगा कि पूरी कंपनी का कोड अपहरणकर्ता के लिए सुलभ है। चूंकि यह कर्मचारियों के लिए दो खातों को बनाए रखने का बोझ लाएगा, मैं सोच रहा हूं कि क्या यह सही दृष्टिकोण है और क्या यह भी समझ में आता है।

सभी उपयोगी जानकारियों के लिए धन्यवाद का अद्यतन करें । मैं प्रश्न / उत्तर की व्यक्तिपरक प्रकृति के कारण स्वीकार किए गए उत्तर को सेट नहीं करूंगा और चूंकि मैंने कई अलग-अलग उत्तरों से सर्वश्रेष्ठ अंक लिए हैं।

मैंने इस तरह से आगे बढ़ने का फैसला किया है: मैं कर्मचारियों को याद दिलाऊंगा कि काम से संबंधित GitHub ई-मेल सूचनाओं को व्यावहारिक कारणों से अपने काम के ई-मेल खातों में भेजना होगा। इसलिए यह काम GitHub खातों बनाने के लिए और अधिक समझ में आता है। यदि वे अपने व्यक्तिगत GitHub खातों का उपयोग करने और अपने कार्य ई-मेल खातों से कनेक्ट करने के लिए तैयार हैं तो यह ठीक है। किसी भी स्थिति मेंकर्मचारियों को गीथहब का उपयोग करने के लिए बंधे हुए कई शर्तों के लिए लिखित रूप में सहमत होना होगा। ये खाता सुरक्षा से संबंधित हैं: एक सुरक्षित यादृच्छिक पासवर्ड जनरेटर का उपयोग करके एक सुरक्षित पासवर्ड चुनना जो किसी अन्य खाते के साथ उपयोग नहीं किया जाता है, कंप्यूटर के माध्यम से गिटहब तक पहुंच नहीं है, जिनके पास स्वामित्व या प्रशासित नहीं है, आदि। दिन के अंत में कर्मचारियों को करना होगा। खुद तय करें कि कोई काम खाता उनके लिए ज्यादा मायने रखता है या नहीं।

Comments

कार्य खाता समझौता करना उतना ही आसान होगा, है ना?

— बोरिस यांकोव

GitHub ने अगस्त, 2012 में प्रति-संगठन ईमेल रूटिंग को जोड़ा। github.com/blog/1204-notifications-stars

— Paul Schreiber

@BorisYankov कार्य खाते से समझौता करना कठिन हो सकता है, अगर आपके पास कोई सार्वजनिक गतिविधि नहीं है और लॉगिन का आपके नाम से कोई संबंध नहीं है। यह अस्पष्टता से सुरक्षा है, लेकिन यह सुनिश्चित करने में मदद करता है। आप एक वर्कफ़्लो बना सकते हैं कि गिथब द्वारा भेजे गए सभी ईमेल विकास टीम के नेता, आदि को भेजे गए हैं। एक अन्य बिंदु: कार्य खाते के रूप में आप तय कर सकते हैं और यहां तक ​​कि उचित परिश्रम, लेखा परीक्षा भी कर सकते हैं और देख सकते हैं कि क्या वे सहमत थे कि क्या अनुपालन किया गया था। कंपनी और कर्मचारी के बीच। एक तीसरा महत्वपूर्ण बिंदु: जैसे ही उपयोगकर्ता अपनी नौकरी छोड़ देता है, आप उसका खाता संभाल सकते हैं।

— वी.पी.

यह एक से अधिक खाते बनाए रखने के लिए व्यक्तियों के लिए GitHub सेवा की शर्तों के खिलाफ है। "एक व्यक्ति या कानूनी इकाई एक से अधिक मुक्त खाते का रखरखाव नहीं कर सकती है।" help.github.com/articles/github-terms-of-service

— रिले मेजर

इस अंतिम टिप्पणी के बारे में। शर्तों की जाँच की, बिंदु A.7। तो क्या होता है यदि आपके पास आपका व्यक्तिगत खाता है और आपकी कंपनी आपकी ओर से एक और खाता बनाती है और क्या आपने इसका उपयोग किया है? क्या आपके व्यक्तिगत खाते को समाप्त कर दिया जाएगा भले ही आपने कोई गलत न किया हो?

— माटेयो मोस्का

Answer 1

यदि कोई लाभ होता, तो यह केवल दर्दनाक होता। लेकिन दर्दनाक और व्यर्थ से बदतर कुछ भी नहीं चूसता है। बस एक ही व्यक्तिगत खाता है। दो कारण:

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

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

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

Answer 2

क्या आपकी कंपनी का कोड सार्वजनिक या निजी रिपॉजिटरी में है? यदि वे (या कम से कम कुछ) सार्वजनिक हैं, और आपने अपने कर्मचारियों को अपने GitHub खातों का उपयोग करने की अनुमति दी है, तो यह उनके लिए अच्छा कोड लिखने के लिए एक प्रोत्साहन होगा। उनका नाम वस्तुतः सार्वजनिक रूप से इससे जुड़ा होगा । हालाँकि, मैं मानूंगा कि आपके सभी रिपॉजिटरी निजी हैं।

कुल मिलाकर, ऐसा लगता है कि आप यह पसंद करेंगे कि आपके कर्मचारी के खाते पूरे गीथहब में सार्वजनिक रूप से दिखाई न दें। दुर्भाग्य से, वे GitHub Enterprise को बेचकर पैसा कमाते हैं इसलिए मुझे लगता है कि एक कारण है कि वे आपको संगठनों के लिए निजी खाते बनाने की अनुमति नहीं देते हैं। या तो मामले में, (अनिवार्य रूप से) लॉक-डाउन कार्य खाते आपके रिपॉजिटरी की मेजबानी के लिए एक बहुत ही सामाजिक साइट चुनने के बाद वास्तव में काउंटर-सहज होंगे।

आइए कल्पना करें कि आपने अपने कर्मचारियों के लिए कार्य खाते की स्थापना की है। क्या आप इस बात पर कोई प्रतिबंध लागू करेंगे कि वे उन खातों का उपयोग कैसे कर सकते हैं? क्या आप उन्हें कार्य उद्देश्यों के लिए गैर-कार्य परियोजनाओं में कोड का योगदान करने की अनुमति देंगे? यदि ऐसा है, तो उनके खाते सार्वजनिक रूप से दृश्यमान हो जाएंगे, जो आपको आपकी प्रारंभिक चिंता में वापस लाएंगे। आप उन्हें अपने व्यक्तिगत खातों के साथ योगदान करने की अनुमति दे सकते हैं, लेकिन फिर आप उनके लिए एक लॉजिकल दर्द बिंदु बना रहे हैं। व्यक्तिगत रूप से, मैं अपने कर्मचारियों को स्वयं के रूप में अन्य परियोजनाओं में कोड योगदान करने के लिए प्रोत्साहित करूंगा। यह न केवल उन्हें एक आत्मविश्वास को बढ़ावा देता है, इससे उन्हें मूल्यवान अनुभव प्राप्त करने और अपनी विश्वसनीयता बनाने की अनुमति मिलती है।

किसी भी मामले में, मुझे नहीं लगता कि यह काम के खातों के प्रयास के लायक है। GitHub इंटरफ़ेस आपको आसानी से नियंत्रित करने की अनुमति देता है कि किसके पास पहुंच है, इसलिए पहुंच को हटाना या तो सरल है। मैं यह भी नहीं सोचता कि अलग-अलग खाते होने से व्यक्तिगत और कार्य परियोजनाओं के बीच वास्तव में "रेखा खींचता है" जो पहले से ही GitHub इंटरफ़ेस से है।

इसके अलावा, ध्यान रखें कि आप अपनी कंपनी के बढ़ते ही इससे निपटने की योजना कैसे बनाते हैं। क्या आपके द्वारा तय की गई नीतियां अब प्रबंधन के दृष्टिकोण से मापनीय होने जा रही हैं? 5 खातों का प्रबंधन करना अब ठीक हो सकता है, लेकिन जब आप 20 या 50 के हो जाते हैं तो क्या होता है? लेकिन एक बार जब आप उस बिंदु पर पहुंच जाते हैं, तो शायद गिटहब एंटरप्राइज एक स्वीकार्य समाधान होगा। उस स्थिति में मैं समझ सकता हूं कि क्या GitHub खातों को GitHub एंटरप्राइज़ इंस्टॉल में माइग्रेट किया जा सकता है। यदि हां, तो मैं देख सकता हूं कि कार्य खाते होने का एक सकारात्मक कारण है।

Comments

महान अंक, धन्यवाद। हां रिपॉजिटरी निजी हैं। काम पर गैर-कार्य परियोजनाओं पर काम करने के बारे में, मुझे इस बारे में बिल्कुल चिंता नहीं है। यह सिर्फ खाता सुरक्षा है।

— फियोरेंती

मैंने उस विशेष टिप्पणी को संपादित कर दिया है क्योंकि यह प्रासंगिक नहीं था।

— जेरेमी हीलर

Answer 3

सवाल से बाहर नहीं, और वास्तव में एक बहुत अच्छा विचार है।

अफसोस की बात है कि ऐसा हो सकता है, आपको अपने कर्मचारियों को कंपनी के जीवन के किसी बिंदु पर संगठन छोड़ने की योजना बनाने की आवश्यकता है। आप उस समय कंपनी के भंडार से अपने व्यक्तिगत खातों को कैसे निकालने जा रहे हैं?

यदि कर्मचारी खराब शर्तों पर निकलता है तो आप क्या करने जा रहे हैं? एक आदर्श दुनिया में, सब कुछ पेशेवर रहेगा और फर्म और पूर्व कर्मचारी के बीच कोई दुश्मनी नहीं होगी। आप कम-से-आदर्श परिस्थितियों की योजना के लिए विवेकपूर्ण होंगे।

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

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

उदाहरण के लिए, यदि कोई कर्मचारी अपने व्यक्तिगत खाते का उपयोग करता है और कंपनी और प्रोजेक्ट एक्स दोनों में योगदान देता है, तो आप कैसे पहचानते हैं कि उस समय कर्मचारी की क्या भूमिका थी? क्या आपकी कंपनी की ओर से X का योगदान था या उनका अपना निजी विवेक था? क्या कर्मचारी या कंपनी एक्स को दिए गए उस काम के कॉपीराइट का मालिक है? उस मामले के लिए, यदि आप अपनी कंपनी के काम में बाहरी योगदान की अनुमति देते हैं, तो आप कैसे अंतर करते हैं कि कर्मचारी कर्मचारी था या यदि यह एक स्वैच्छिक योगदान था?

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

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

यह उपयोगकर्ता खाते को अलग करने के तकनीकी पहलुओं के बारे में नहीं है, यह कानूनी सवाल है जो आपको यात्रा कर सकते हैं।

ध्यान दें कि यह एक म्यूट बिंदु हो सकता है यदि आपकी कंपनी के उत्पाद सभी को लाइसेंसिंग लाइसेंस के तहत खुले स्रोत के रूप में जारी किए जाते हैं और / या आप संभावित ब्रांडिंग मुद्दों के बारे में बिल्कुल भी चिंतित नहीं हैं।
(इस संपादन के अनुरोध के लिए पॉल बिगगर को हैट टिप)

Comments

धन्यवाद, मैं इस नीति का भी स्वागत करूंगा यदि मैं उल्लिखित कारणों की वजह से एक कर्मचारी था। GitHub का इंटरफ़ेस आपको निजी रिपॉजिटरी से उपयोगकर्ताओं की पहुंच को आसानी से हटाने की अनुमति देता है। मेरा यह भी मानना ​​है कि एक कर्मचारी को बहुत बुरी शर्तों पर छोड़ देना चाहिए, ज्यादातर मामलों में उसके पास नुकसान के लिए पर्याप्त समय होगा यदि वह चाहता है।

— फियोरेंती

मैं इस जवाब को नहीं समझता। GitHub में बढ़िया अनाज पहुंच नियंत्रण है। जब एक कर्मचारी निकलता है, तो आप अपने संगठन से उनकी पहुंच हटा देते हैं। इसमें मुश्किल क्या है? वास्तव में, उनके व्यक्तिगत खाते को निकालना आसान है, क्योंकि यह उनके कार्य खाते को "पुनः प्राप्त" करना होगा।

— पॉल बिगगर

@fiorenti: संभवतः, उपयोगकर्ता के पास कोड का पूरा चेकआउट होगा, जो कोड होस्ट किए जाने के बावजूद होता है!

— पॉल बिगगर

@PaulBiggar - मैंने कुछ व्यापक मुद्दों को शामिल करने के लिए अपनी प्रतिक्रिया को अद्यतन किया। यह मुख्य रूप से एक कानूनी अटेंशन मुद्दा है जो मुझे अलग-अलग खातों की सिफारिश करने की ओर ले जाता है। मैंने कई मामलों को देखा है, जिसमें बाद में गंभीर सिरदर्द के लिए किए गए कार्य खातों से व्यक्तिगत को अलग नहीं किया गया है। कंपनी के लोकाचार के आधार पर सभी की MMV और प्रत्येक स्थिति की जांच की जानी चाहिए।

संभावित कानूनी मुद्दे के लिए संकेत देने के लिए धन्यवाद कि आप क्षेत्र में दौड़ सकते हैं

— RidiculousRichard

Answer 4

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

केवल संदर्भ को पूरा करने के लिए: मुझे खातों के संबंध में कुछ भी नहीं पूछा गया था, वास्तव में GitHub मेरे कार्यस्थल पर अधिकांश लोगों के लिए अज्ञात है। मैं जिस प्रोजेक्ट पर काम कर रहा हूं, उसे ओपन-सोर्स करने के लिए मुझे बस हरी बत्तियां मिल रही थीं, और अपने निजी खाते का उपयोग करते हुए, कम से कम काम के साथ चला गया।

एक कर्मचारी के दृष्टिकोण से, एक चीज जो मुझे वास्तव में नफरत है: काम के सामान के लिए मेरे व्यक्तिगत ईमेल पर सूचनाएं प्राप्त करना।

उस अवलोकन से, मुझे एहसास हुआ कि यह पेशेवर / व्यक्तिगत अवरोधक का एक ज़बरदस्त तोड़ है: अगर मैं अपने ऑफ़ टाइम के दौरान किसी प्रोजेक्ट में योगदान करना चाहता हूं, तो मुझे अभी भी अपने काम के प्रोजेक्ट्स से सभी अपडेट मिलते हैं ... और यह बाहरी योगदानकर्ताओं के लिए भ्रम ला सकता है। , जो आपको उस परियोजना से दूर जाने के बिना आपसे संपर्क कर सकते हैं ।

फिर, इस तथ्य के साथ खोजने के लिए एक संतुलन है कि आपकी व्यक्तिगत प्रतिष्ठा आपके काम के योगदान से प्राप्त कर सकती है। लेकिन फिर, यह विपरीत हो सकता है यदि आपका नाम एक खराब परियोजना से जुड़ा हो ...

अंत में, जैसा कि नियोक्ता के दृष्टिकोण से प्रश्न पूछा गया है , और अन्य सभी उत्तरों पर विचार करते हुए: मैं कहूंगा कि कार्य-समर्पित खातों का उपयोग करने में संभवतः बहुत अधिक बिंदु नहीं है । लेकिन आपको इसे मना नहीं करना चाहिए, ताकि जो कर्मचारी व्यक्तिगत बाधा को उठाना पसंद करते हैं वे ऐसा कर सकें, और शायद उन जोखिमों के बारे में संकेत दें ...?

---

साइड नोट के रूप में, सुरक्षा के संबंध में, क्योंकि अन्य उत्तरों में कुछ आसान खारिज होना प्रतीत होता है:

बेशक, एक "काम" खाता पासवर्ड के बारे में एक "व्यक्तिगत" खाते से अधिक या कम सुरक्षित नहीं होगा। लेकिन जब आप GitHub का उपयोग कर रहे हैं, तो आपको SSH कुंजी के साथ पुश करने की अनुमति है। और वह कुंजी आम तौर पर किसी के सत्र में निहित होती है ... इसलिए, व्यक्तिगत खाता एक साधारण व्यक्तिगत कंप्यूटर चोरी (बिना पासवर्ड ज्ञान के) के साथ सभी काम रिपॉजिटरी से समझौता कर सकता है, जबकि एक समर्पित कार्य खाते में संभवतः काम मशीन पर इसका महत्वपूर्ण झूठ होगा, जिससे यह बना होगा अधिक शारीरिक रूप से सुरक्षित (उम्मीद है)।

Comments

+1: दो बिंदु जिनके बारे में मैंने नहीं सोचा था: ईमेल और SSH कुंजियाँ। GitHub पर अलग-अलग ईमेल होना एक समस्या है, आप अपने खाते के लिए कई SSH कुंजी सेट कर सकते हैं।

— जेरेमी हीलर

@JeremyHeiler क्या आप से बिल्कुल मतलब है "GitHub पर अलग ईमेल होने एक मुद्दा है?" । मैं तीन अलग-अलग ईमेल (पुराना वाला, वर्तमान व्यक्तिगत एक, काम एक) का उपयोग कर रहा हूं, एक बार जब आप उन्हें अपनी प्रोफ़ाइल में जोड़ लेते हैं तो GitHub उन्हें आपके खाते में समस्या के बिना मेल खाता है :)

— MattiSG

मैं इस जिद का जिक्र कर रहा था । क्या आप यह कह रहे हैं कि यदि आप अपने वर्क कंप्यूटर पर अपना काम ईमेल git.config में डालते हैं और इसे अपने खाते में जोड़ते हैं, तो कार्य संबंधी सभी सूचनाएं आपके कार्य ईमेल पर भेजी जाएंगी? यदि हां, तो यह बहुत अच्छा है!

— जेरेमी हीलर

@JeremyHeiler ओह नो ओके, हमें ईमेल के साथ "मुद्दा" है की एक छोटी सी गलतफहमी थी :) नहीं, वास्तव में, जैसा कि मैंने अपने जवाब में कहा था, आपको हमेशा अपने "मुख्य" (आमतौर पर व्यक्तिगत) खाते में सूचनाएं मिलती हैं। लेकिन यह एक "मुद्दा" नहीं है क्योंकि आपको प्रत्येक कमिटिंग पते के लिए एक खाते की आवश्यकता होगी: आप अपने खाते से जितने चाहें उतने ईमेल जोड़ सकते हैं, लेकिन केवल एक ईमेल से आपके खाते से सूचनाएं प्राप्त होती हैं।

— मटिसी

क्षमा करें, हाँ, मुझे अपनी प्रारंभिक टिप्पणी में अधिक विशिष्ट होना चाहिए था :-P

— जेरेमी हीलर

Answer 5

मुझे "नहीं" वोट चाहिए। यह आपके डेवलपर्स के लिए काफी परेशानी भरा है और आपको अस्पष्टता के माध्यम से सुरक्षा प्रदान करता है: यदि कोई आपके डेवलपर्स को सक्रिय रूप से लक्षित कर रहा है तो आपके कोड को प्राप्त करने के लिए किसी अन्य पर हमला करने वाले वैक्टर बहुत हैं।

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

इतने कम क्रम की संभावना बनाम डेवलपर उत्पादकता? मैं डेवलपर उत्पादकता ले लूँगा, लेकिन यह मेरी पथरी है। :)

Answer 6

मैं कहूंगा कि कर्मचारी के लिए एक विकल्प होना चाहिए। एक बात मैं कहूंगा कि अगर वे नहीं चाहते हैं तो उन्हें अपने व्यक्तिगत जीथब खाते का उपयोग करने के लिए मजबूर न करें। मैं एक ऐसी कंपनी में था जिसने GitHub का उपयोग किया था और जबकि यह कोई आवश्यकता नहीं थी, मैं व्यक्तिगत रूप से एक अलग खाता बनाना चाहता था। मुख्य कारण मेरी व्यक्ति परियोजनाओं की रक्षा करना था। मैं नहीं चाहता था कि कंपनी मेरी व्यक्तिगत परियोजनाओं में से एक को कहने की कोशिश करे, क्योंकि यह उसी जीथब खाते के तहत थी जिसका उपयोग उनकी कॉमपनी परियोजनाओं के लिए किया जाता था (यह सुनिश्चित नहीं था कि अगर कभी भी अदालत में पकड़ होगी, लेकिन मुझे बहुत विश्वास नहीं है कानूनी प्रणाली में जब यह इस तरह की चीजों की बात आती है)। मुझे लगता है कि साफ अलग होना एक अच्छी बात हो सकती है।

Answer 7

हम इसे अपनी कंपनी में कर रहे हैं। मैं इस बात पर चर्चा शुरू नहीं करना चाहता कि "क्या सुरक्षित है, जीथब या आपके टेबल के नीचे एक सर्वर जो सभी के पास रूट एक्सेस है, सुनिश्चित नहीं है कि बैकअप काम कर रहा है, आदि"। हमारा दृष्टिकोण था:

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

Comments

आप पासवर्ड जटिलता आवश्यकता को लागू नहीं कर सकते क्योंकि आपके पास GitHub पासवर्ड को मान्य करने का कोई तरीका नहीं है, तो भी क्यों है?

— रामहाउंड

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

— वी.पी.

मैं कह रहा हूं कि आपके पास कुछ जानने का कोई तरीका नहीं है, क्योंकि आपके पास किसी कर्मचारी द्वारा बनाए गए GitHub खाते के पासवर्ड को सत्यापित करने का कोई तरीका नहीं है।

— रामहाउंड

ठीक है, अगर उदाहरण के लिए, एक खाते से छेड़छाड़ की जाती है, और हम, कुछ इस बात का पता लगाते हैं कि पासवर्ड abc123 था, तो हम कर्मचारी को "जिम्मेदार" बना सकते हैं। मुझे यहाँ कोई समस्या नहीं दिख रही है। एक और बिंदु: जहां लिखा है कि मैं इसे लागू करता हूं? मैंने इसे लिखा था (अब मुझे अपडेट होना चाहिए) ...

— वी.पी.

इस दृष्टिकोण को एक समझौते के साथ सम्‍मिलित होना चाहिए कि यह नाम भी उनका है और आप उनके नाम पर कोई कार्रवाई नहीं करेंगे ।

— माइकल

Answer 8

मैं मानता हूं कि यह Q & A कुछ वर्ष पुराना है, इसलिए शायद यह पहले उपलब्ध नहीं था, लेकिन वे विशेष रूप से उपयोगकर्ता और संगठन खातों के बीच अंतर में राज्य करते हैं:

व्यक्तिगत उपयोग और व्यावसायिक उपयोग के लिए एक से अधिक उपयोगकर्ता खाते का होना आपको लुभा सकता है, लेकिन आपको केवल एक खाते की आवश्यकता है।

GitHub ने रिपॉजिटरी द्वारा सूचनाओं को चालू / बंद करने के लिए अच्छे उपकरण बनाए हैं और इसलिए ऐसा लगता है कि व्यक्तिगत / काम का संयोजन सबसे अधिक समझ में आता है।

Comments

क्या था कि नीचे के बारे में, एह? मुझे लगता है कि यह एक अच्छा जवाब है।

— जॉन मैकगी

Answer 9

लोगों को क्लाउड आधारित स्रोत सर्वर पर भरोसा करना बाकी है। गितुब ने कई नई वेब कंपनियों को अपने साथ अनुबंधित किया, लेकिन वास्तविक तथ्य यह है कि ज्यादातर लोगों के पास स्रोत कोड बनाए रखने के लिए अपने स्वयं के सर्वर हैं। मेरे अनुभव में, उनमें से ज्यादातर क्लियर-केस या एसवीएन का उपयोग करते हैं। गिट को अभी तक एक उद्यम वातावरण में अनुकूलित नहीं किया गया है। यहां तक ​​कि कॉर्पोरेट मेल सर्वर वास्तव में कंपनी के परिसर के बाहर की सराहना नहीं कर रहे हैं।

Comments

मैं वर्तमान में एक सेवा कंपनी में काम करता हूं, उन्हें गिट के साथ प्रशिक्षित किया है, और उनके अधिकांश ग्राहक (जैसे, बड़ी कंपनियां)

— क्लियरकेस