ขอแนะนำให้พนักงานสร้างบัญชี GitHub 'ทำงาน' หรือไม่

ฉันย้ายที่เก็บ Git ของ บริษัท ทั้งหมดไปที่ GitHub และตอนนี้ฉันต้องการเพิ่มพนักงานให้กับโครงการ เนื่องจากพนักงานส่วนใหญ่มีบัญชี GitHub ส่วนบุคคลอยู่แล้วฉันจึงสงสัยว่าฉันควรขอให้พวกเขาสร้างบัญชี GitHub ที่ทำงานหรือไม่ เหตุผลที่ฉันคิดว่าการทำเช่นนี้คือการลดโอกาสในการเข้าถึงฐานรหัสของเราโดยไม่ได้รับอนุญาตเนื่องจากบัญชีส่วนบุคคลของพวกเขาอาจได้รับการเผยแพร่ผ่านกิจกรรมส่วนตัวของพวกเขาในเว็บไซต์ซึ่งเป็นการเพิ่มโอกาสในการโจมตีเป้าหมาย นอกจากนี้หากบัญชีส่วนบุคคลของพวกเขาถูกบุกรุกมันจะไม่หมายความว่านักจี้สามารถเข้าถึงรหัส บริษัท ทั้งหมดได้ ตั้งแต่นี้จะนำภาระในการรักษาบัญชีสองบัญชีสำหรับพนักงานฉันสงสัยว่ามันเป็นวิธีการที่ถูกต้องและไม่ว่ามันจะทำให้รู้สึก

อัปเดต ขอบคุณสำหรับข้อมูลเชิงลึกที่มีประโยชน์ทั้งหมด ฉันจะไม่ตั้งคำตอบให้เป็นที่ยอมรับเนื่องจากธรรมชาติของคำถาม / คำตอบและเนื่องจากฉันได้รับคะแนนที่ดีที่สุดจากคำตอบที่แตกต่างกัน

ฉันตัดสินใจที่จะก้าวไปข้างหน้าด้วยวิธีนี้: ฉันจะเตือนพนักงานว่าการแจ้งเตือนทางอีเมลที่เกี่ยวข้องกับงาน GitHub นั้นจะต้องถูกส่งไปยังบัญชีอีเมลการทำงานของพวกเขาด้วยเหตุผลจริง ดังนั้นจึงเหมาะสมกว่าที่จะสร้างบัญชี GitHub ที่ทำงาน หากพวกเขายินดีที่จะใช้บัญชี GitHub ส่วนตัวของพวกเขาและเชื่อมต่อกับบัญชีอีเมลที่ทำงานของพวกเขานั่นก็ดี ไม่ว่าในกรณีใดพนักงานจะต้องตกลงในรูปแบบเป็นลายลักษณ์อักษรกับเงื่อนไขจำนวนหนึ่งที่เกี่ยวข้องกับการใช้ GitHub สิ่งเหล่านี้เกี่ยวข้องกับความปลอดภัยของบัญชี: เลือกรหัสผ่านที่ปลอดภัยโดยใช้เครื่องสร้างรหัสผ่านแบบสุ่มที่ปลอดภัยซึ่งไม่ได้ใช้กับบัญชีอื่นไม่เข้าถึง GitHub ผ่านคอมพิวเตอร์ที่ไม่ได้เป็นเจ้าของหรือเป็นผู้บริหารเป็นต้นเมื่อสิ้นสุดวันพนักงานจะต้อง ตัดสินใจด้วยตัวเองว่าบัญชีงานนั้นเหมาะสมกับพวกเขาหรือไม่

หากมีประโยชน์ก็แค่เจ็บปวดเท่านั้น แต่ไม่มีอะไรแย่ไปกว่าความเจ็บปวดและไร้จุดหมาย เพียงแค่มีบัญชีส่วนบุคคลเดียว เหตุผลสองประการ:

• Github มีการควบคุมการเข้าถึงที่ดีอย่างไม่น่าเชื่อในองค์กรของพวกเขา หากพนักงานลาออกคุณสามารถลบการเข้าถึงได้ทันที หากพวกเขามีบัญชี บริษัท คุณจะต้องเรียกคืนบัญชีเพื่อรับสิทธิประโยชน์ที่ระบุ ในทางปฏิบัติคุณอาจเพิ่งลบการเข้าถึงบัญชีเหมือนกับว่าพวกเขามีบัญชีส่วนตัว

• การมีมากกว่าหนึ่งบัญชีเป็นเรื่องเจ็บปวด เข้าสู่ระบบและออกจากระบบระหว่างบัญชีเจ็บและเพิ่มความคิดเห็นต่อไปนี้และทุกสิ่งทางสังคมเมื่อคุณใช้บัญชีที่แตกต่างกัน

ข้อมูลอ้างอิง:ฉันสร้างเซิร์ฟเวอร์ CI ที่มีการรวม GitHubดังนั้นฉันจึงมีบัญชีทดสอบจำนวนมากและฉันได้พูดคุยกับลูกค้าด้วยการกำหนดค่าแปลก ๆ ทุกประเภทรวมถึงบัญชีงานแยกต่างหากและบัญชีส่วนตัว มันมักจะนำไปสู่ปัญหา

รหัส บริษัท ของคุณอยู่ในที่สาธารณะหรือที่เก็บส่วนตัว? หากพวกเขา (หรืออย่างน้อยบางคน) เป็นสาธารณะและคุณอนุญาตให้พนักงานของคุณใช้บัญชี GitHub ของพวกเขาเองมันจะเป็นแรงจูงใจให้พวกเขาเขียนรหัสที่ดี ชื่อของพวกเขาจะตามตัวอักษรจะแนบมากับมันต่อสาธารณชน อย่างไรก็ตามฉันจะสมมติว่าที่เก็บข้อมูลทั้งหมดของคุณเป็นแบบส่วนตัว

โดยรวมดูเหมือนว่าคุณต้องการให้บัญชีพนักงานของคุณไม่ปรากฏต่อสาธารณะทั่ว GitHub น่าเสียดายที่พวกเขาสร้างรายได้จากการขายGitHub Enterpriseดังนั้นฉันคิดว่านั่นเป็นเหตุผลหนึ่งว่าทำไมพวกเขาไม่อนุญาตให้คุณสร้างบัญชีส่วนตัวสำหรับองค์กร ไม่ว่าในกรณีใดการมีบัญชีงานที่ถูกล็อค (โดยหลัก) จะเป็นเรื่องที่เข้าใจง่ายจริงๆหลังจากเลือกเว็บไซต์โซเชียลเพื่อโฮสต์ที่เก็บของคุณ

ลองจินตนาการดูว่าคุณได้ตั้งค่าบัญชีงานสำหรับพนักงานของคุณแล้ว คุณจะบังคับใช้ข้อ จำกัด ใด ๆ เกี่ยวกับวิธีที่พวกเขาสามารถใช้บัญชีเหล่านั้นได้หรือไม่? คุณช่วยให้พวกเขามีส่วนร่วมกับรหัสในโครงการที่ไม่ทำงานเพื่อวัตถุประสงค์ในการทำงานได้หรือไม่? หากเป็นเช่นนั้นบัญชีของพวกเขาจะปรากฏต่อสาธารณะและนำคุณกลับไปยังข้อกังวลเริ่มต้นของคุณ คุณสามารถอนุญาตให้พวกเขามีส่วนร่วมกับบัญชีส่วนตัวของพวกเขา แต่จากนั้นคุณกำลังสร้างจุดปวดจิสติกส์สำหรับพวกเขา โดยส่วนตัวแล้วฉันจะสนับสนุนให้พนักงานของฉันมีส่วนร่วมในการสร้างรหัสให้กับโครงการอื่น ๆ ด้วยตนเอง สิ่งนี้ไม่เพียง แต่ช่วยเพิ่มความมั่นใจเท่านั้น แต่ยังช่วยให้พวกเขาได้รับประสบการณ์ที่มีค่าและสร้างความน่าเชื่อถือ

ไม่ว่าในกรณีใดฉันไม่คิดว่ามันคุ้มค่ากับความพยายามที่จะมีบัญชีทำงาน อินเทอร์เฟซ GitHub ช่วยให้คุณสามารถควบคุมผู้ที่สามารถเข้าถึงสิ่งใดได้อย่างง่ายดายดังนั้นการลบการเข้าถึงจึงเป็นวิธีที่ง่าย ฉันยังไม่คิดว่าการมีบัญชีแยกกันจริงๆ "วาดเส้น" ระหว่างโครงการส่วนตัวและโครงการทำงานอีกต่อไปกว่าอินเทอร์เฟซ GitHub แล้ว

นอกจากนี้โปรดจำไว้ว่าคุณวางแผนรับมือกับเรื่องนี้อย่างไรเมื่อ บริษัท ของคุณเติบโต นโยบายที่คุณตั้งไว้นั้นจะสามารถปรับขนาดได้จากจุดยืนการจัดการหรือไม่? การจัดการ 5 บัญชีในตอนนี้อาจใช้ได้ แต่จะเกิดอะไรขึ้นเมื่อคุณเติบโตเป็น 20 หรือ 50 แต่เมื่อคุณไปถึงจุดนั้น GitHub Enterprise อาจเป็นวิธีแก้ปัญหาที่เข้าถึงได้ ในกรณีนั้นฉันจะพิจารณาหากบัญชีโยกย้าย GitHub สามารถติดตั้ง GitHub Enterprise ถ้าเป็นเช่นนั้นฉันจะเห็นว่าเป็นเหตุผลหนึ่งที่ดีที่มีบัญชีงาน

ไม่ใช่คำถามและเป็นความคิดที่ดีทีเดียว

น่าเสียดายที่คุณอาจต้องวางแผนพนักงานของคุณให้ออกจากองค์กรไปในบางจุดในชีวิตของ บริษัท คุณจะแยกแยะบัญชีส่วนบุคคลของพวกเขาออกจากที่เก็บของ บริษัท ณ เวลานั้นได้อย่างไร

คุณจะทำอย่างไรถ้าพนักงานลาออกจากตำแหน่งที่ไม่ดี? ในโลกอุดมคติทุกสิ่งจะยังคงเป็นมืออาชีพและจะไม่มีความเป็นปฏิปักษ์ระหว่าง บริษัท และอดีตพนักงาน คุณจะรอบคอบในการวางแผนสำหรับสถานการณ์ที่ไม่เหมาะ

ในขณะที่รักษาบัญชีสองบัญชีเป็นความเจ็บปวดพนักงานของคุณควรยินดีต้อนรับโอกาส มันให้เส้นสะอาดระหว่างสิ่งที่พวกเขาและสิ่งที่เป็นของ บริษัท

แก้ไข: ความกังวลที่นี่คือการแยกที่ชัดเจนระหว่างการมีส่วนร่วมของพนักงานกับโครงการ X, Y, Z, ฯลฯ ... และงานที่ต้องชำระในผลิตภัณฑ์ของ บริษัท การใช้บัญชีงานแยกต่างหากช่วยจัดเตรียมการวิเคราะห์ที่จำเป็นเพื่อระบุว่าใครเป็นเจ้าของทรัพย์สินทางปัญญาและลิขสิทธิ์ที่เกี่ยวข้อง

ตัวอย่างเช่นหากพนักงานใช้บัญชีส่วนตัวของพวกเขาและมีส่วนร่วมกับทั้ง บริษัท และโครงการ X คุณจะระบุบทบาทของพนักงานในจุดเหล่านั้นได้อย่างไร การบริจาคให้กับ X ในนามของ บริษัท ของคุณหรือดุลยพินิจส่วนตัวของพวกเขาคืออะไร? พนักงานหรือ บริษัท เป็นเจ้าของลิขสิทธิ์งานที่มอบให้แก่ X หรือไม่ สำหรับเรื่องนั้นถ้าคุณอนุญาตการมีส่วนร่วมภายนอกให้กับงานของ บริษัท คุณจะแยกความแตกต่างได้อย่างไรว่าพนักงานเป็นพนักงานหรือหากเป็นการบริจาคโดยสมัครใจ

ในมุมมองที่กว้างขึ้นกล่าวว่าคุณมีพนักงานที่สร้างชื่อเสียงที่ทำหน้าที่แทน บริษัท โดยมีส่วนร่วมในโครงการอื่น ๆ เมื่อพนักงานคนนั้นออกไปคุณจะระบุได้อย่างไรว่าบัญชีผู้ใช้ส่วนบุคคลนั้นไม่เกี่ยวข้องกับ บริษัท ของคุณอีกต่อไป ปัญหาของแบรนด์ที่ร้ายแรงสามารถเกิดขึ้นได้โดยไม่มีการวิเคราะห์อย่างชัดเจนว่าบัญชีใดมีไว้สำหรับ

มันค่อนข้างง่ายที่จะล้มลงในเส้นทางของความเป็นเจ้าของตราสินค้าและข้อกังวลเกี่ยวกับลิขสิทธิ์เมื่อคุณเริ่มคิดถึงสถานการณ์ที่อาจเกิดขึ้น การใช้บัญชีงานแยกต่างหากช่วยลบความกำกวมบางส่วนนี้ บริษัท ต้องสามารถเรียกร้องค่าชดเชยจากการบริจาคในนามของ บริษัท ได้

มันไม่ได้เกี่ยวกับประเด็นทางเทคนิคในการแยกบัญชีผู้ใช้ออกเป็นคำถามทางกฎหมายที่จะพาคุณไป

โปรดทราบว่านี่อาจเป็นจุดที่สงสัยหากผลิตภัณฑ์ของ บริษัท ของคุณได้รับการเผยแพร่ในรูปแบบโอเพ่นซอร์สภายใต้ลิขสิทธิ์ที่อนุญาตและ / หรือคุณไม่กังวลเกี่ยวกับปัญหาการสร้างแบรนด์
(นำหมวกไปที่ Paul Biggar เพื่อขอแก้ไขนี้)

เนื่องจากทุกคนดูเหมือนจะเห็นด้วยกับการขาดความต้องการของนายจ้างในการแยกทั้งสองอย่างนี่คือประสบการณ์สั้น ๆ ของฉันที่ได้ลองใช้บัญชีส่วนบุคคลของฉันในโครงการมืออาชีพและการมีส่วนร่วมโอเพนซอร์สในบริบทของการทำงาน

เพียงเพื่อทำให้บริบทเสร็จสมบูรณ์: ฉันไม่ได้ถามอะไรเกี่ยวกับบัญชีจริงๆแล้ว GitHub ไม่เป็นที่รู้จักของคนส่วนใหญ่ในที่ทำงานของฉัน ฉันสามารถรับแสงสีเขียวไปยังโอเพ่นซอร์สโครงการที่ฉันกำลังทำงานอยู่และทำงานน้อยที่สุดเช่นใช้บัญชีส่วนตัวของฉัน

จากมุมมองของพนักงานสิ่งหนึ่งที่ฉันเกลียดจริงๆ: รับการแจ้งเตือนในอีเมลส่วนตัวของฉันเพื่อหางาน

จากการสังเกตนั้นฉันก็รู้ว่ามันเป็นการทำลายกำแพงมืออาชีพ / ส่วนบุคคลอย่างโจ่งแจ้ง: ถ้าฉันต้องการมีส่วนร่วมในโครงการในช่วงนอกเวลาทำงานฉันก็ยังได้รับการอัปเดตทั้งหมดจากโครงการทำงานของฉัน ... และมันอาจทำให้เกิดความสับสน ที่อาจติดต่อคุณโดยไม่ทราบว่าคุณกำลังออกว่าโครงการ

แน่นอนว่ามีความสมดุลในการค้นหาความจริงที่ว่าชื่อเสียงส่วนบุคคลของคุณสามารถได้รับจากการทำงานของคุณ แต่อีกครั้งมันอาจตรงกันข้ามถ้าชื่อของคุณเชื่อมโยงกับโครงการที่ไม่ดี ...

ในท้ายที่สุดเป็นคำถามที่ถามจากนายจ้างจุดของมุมมองและพิจารณาคำตอบอื่น ๆ ทั้งหมด: ผมจะบอกว่าอาจมีจุดมากในการบังคับใช้บัญชีทำงานทุ่มเท แต่คุณไม่ควรห้ามมันเพื่อให้พนักงานที่ต้องการเพิ่มอุปสรรคส่วนบุคคลอาจทำเช่นนั้นและอาจบอกใบ้ถึงความเสี่ยงเหล่านั้น ... ?

ในฐานะที่เป็นข้อความด้านข้างเกี่ยวกับความปลอดภัยเนื่องจากดูเหมือนว่าจะมีการเลิกจ้างง่ายในคำตอบอื่น ๆ :

แน่นอนว่าบัญชี "ที่ทำงาน" จะไม่มีความปลอดภัยมากไปกว่าบัญชี "ส่วนตัว" ที่เกี่ยวข้องกับรหัสผ่าน แต่เมื่อคุณใช้ GitHub คุณจะได้รับอนุญาตให้กดคีย์ SSH และคีย์นั้นมักจะอยู่ในเซสชั่นหนึ่งของ…ดังนั้นบัญชีส่วนบุคคลสามารถประนีประนอมที่เก็บงานทั้งหมดด้วยการขโมยคอมพิวเตอร์ส่วนบุคคลที่เรียบง่าย ปลอดภัยยิ่งขึ้น (หวังว่า)

ฉันต้องการลงคะแนน "ไม่" มันค่อนข้างยุ่งยากสำหรับนักพัฒนาของคุณและให้ความปลอดภัยผ่านความสับสน: หากมีคนกำหนดเป้าหมายนักพัฒนาของคุณอย่างแข็งขันมีการโจมตีเวกเตอร์อื่น ๆ มากมายสำหรับคนที่จะได้รับรหัสของคุณ

นอกจากนี้เมื่อคุณเริ่มทำงานนอกเสียจากว่าคุณมีอัลกอริธึมแบบลับๆซอสจำนวนมากที่เล่นใครบางคนที่ได้รับรหัสของคุณจะน่าอายและน่ากลัวและน่าสะพรึงกลัว แต่ไม่ควรทำให้เกิดข้อได้เปรียบทางการแข่งขันที่สำคัญ รหัส?) หรือทำให้คุณเลิกกิจการ

โอกาสในการสั่งซื้อต่ำเทียบกับความสามารถในการพัฒนาของนักพัฒนา? ฉันจะพัฒนาประสิทธิภาพของนักพัฒนา แต่นั่นคือแคลคูลัสของฉัน :)

ฉันจะบอกว่าควรจะเป็นทางเลือกที่เหลือให้กับพนักงาน สิ่งหนึ่งที่ฉันจะบอกคือไม่บังคับให้พวกเขาใช้บัญชี GitHub ส่วนตัวของพวกเขาหากพวกเขาไม่ต้องการ ฉันอยู่ที่ บริษัท ที่ใช้ GitHub และแม้ว่ามันจะไม่ใช่ข้อกำหนดฉันก็ต้องการสร้างบัญชีแยกต่างหาก เหตุผลหลักคือเพื่อปกป้องโครงการส่วนบุคคลของฉัน ฉันไม่ต้องการให้ บริษัท พยายามที่จะบอกว่าหนึ่งในโครงการส่วนบุคคลของฉันเป็นของพวกเขาเพราะมันอยู่ภายใต้บัญชี Github เดียวกันที่ใช้สำหรับโครงการ comapny ของพวกเขา (ไม่แน่ใจว่าจะมีขึ้นในศาล แต่ฉันไม่มีศรัทธามาก ในระบบกฎหมายเมื่อมันมาถึงสิ่งต่าง ๆ เช่นนี้) ฉันคิดว่าการแยกที่สะอาดนั้นเป็นสิ่งที่ดี

เรากำลังทำใน บริษัท ของเรา ฉันไม่ต้องการเริ่มการสนทนา "สิ่งที่ปลอดภัยกว่า github หรือเซิร์ฟเวอร์ภายใต้ตารางของคุณที่ทุกคนมีสิทธิ์เข้าถึงรูทไม่แน่ใจว่าการสำรองข้อมูลทำงานอยู่หรือไม่" แนวทางของเราคือ:

• นักพัฒนาทุกคนจะต้องสร้างบัญชีใหม่โดยไม่เกี่ยวข้องกับบัญชี GitHub ส่วนตัว
• ควรใช้อีเมล บริษัท
• ควรสอดคล้องกับกฎความปลอดภัยของเรา (ชื่อล็อกอินและข้อกำหนดรหัสผ่าน)
• พวกเขาไม่สามารถแสดง / มีกิจกรรมสาธารณะใด ๆ
• เป็นทรัพย์สินของ บริษัท ไม่ใช่บัญชีของเขา / เธอ
• บัญชีทั้งหมดเชื่อมต่อกับ บริษัท ชื่อสุ่มเช่นกัน ไม่มีกิจกรรมสาธารณะเช่นกัน

ฉันทราบว่าคำถาม & คำตอบนี้มีอายุไม่กี่ปีดังนั้นอาจไม่ได้มีให้บริการก่อนหน้านี้ แต่พวกเขาระบุไว้เป็นพิเศษในความแตกต่างระหว่างบัญชีผู้ใช้และองค์กรที่:

อาจเป็นการดึงดูดให้มีบัญชีผู้ใช้มากกว่าหนึ่งบัญชีเช่นของใช้ส่วนตัวและใช้งานทางธุรกิจ แต่คุณต้องการเพียงหนึ่งบัญชีเท่านั้น

GitHub ได้สร้างเครื่องมือที่ดีในการเปิด / ปิดการแจ้งเตือนตามที่เก็บข้อมูลและอื่น ๆ ดังนั้นดูเหมือนว่าการรวมส่วนบุคคล / งานเข้าด้วยกันจะเป็นสิ่งที่เหมาะสมที่สุด

ผู้คนยังเชื่อในเซิร์ฟเวอร์ต้นทางบนคลาวด์ Github ภูมิใจนำเสนอ บริษัท เว็บยุคใหม่จำนวนมากที่ลงทะเบียนกับพวกเขา แต่ความจริงก็คือว่าคนส่วนใหญ่มีเซิร์ฟเวอร์ของตัวเองสำหรับการบำรุงรักษาซอร์สโค้ด จากประสบการณ์ของฉันส่วนใหญ่ใช้ Clear-case หรือ SVN Git นั้นยังไม่ได้ถูกดัดแปลงในสภาพแวดล้อมขององค์กร แม้แต่เซิร์ฟเวอร์อีเมลขององค์กรก็ไม่ได้รับการชื่นชมนอกสถานที่ของ บริษัท