ควรย้ายออกจาก GitHub หรือไม่? กรอบการตัดสินใจสำหรับนักพัฒนาและทีมขนาดเล็ก

เมื่อวันที่ 24 เมษายน 2026 นโยบายการฝึกโมเดลของ GitHub เปลี่ยนไปสำหรับแพ็กเกจ Copilot แบบรายบุคคล ตอนนี้ GitHub อาจใช้การโต้ตอบจาก Copilot Free, Pro, Pro+ และ Max รวมถึงอินพุต เอาต์พุต ชิ้นส่วนโค้ด และบริบทที่เกี่ยวข้อง เพื่อฝึกและปรับปรุงโมเดล AI เว้นแต่ผู้ใช้จะปฏิเสธ ข้อมูลของ Copilot Business และ Enterprise ยังคงได้รับความคุ้มครองภายใต้ข้อตกลงคุ้มครองข้อมูลของ GitHub ที่สำคัญคือ เรื่องนี้เกี่ยวกับข้อมูลการโต้ตอบกับ Copilot ไม่ใช่ที่เก็บโค้ดส่วนตัวที่เพียงวางไว้เฉย ๆ บน GitHub

ในเวลาเดียวกัน ข้อถกเถียงเรื่องการย้ายกลับมาอีกครั้งด้วยเหตุผลอื่น นั่นคืออินสแตนซ์ Git แบบโฮสต์เองที่เปิดสาธารณะกำลังรับทราฟฟิกอัตโนมัติหนักหน่วง การสนทนาบน Hacker News ได้รวบรวมรายงานจากผู้ดูแลระบบที่เป็นประโยชน์เกี่ยวกับปัญหานั้นไว้: จุดจบของยุคสมัยสำหรับผม: เลิกโฮสต์ git เองแล้ว.

จึงเหลือคำถามที่มีประโยชน์กว่า "GitHub หรือโฮสต์เอง?" นั่นคือ คุณกำลังพยายามแก้ปัญหาอะไรกันแน่?

เวอร์ชันสั้น

มีสามคำตอบ เลือกข้อที่ตรงกับสถานการณ์ของคุณ

• A: ปฏิเสธแล้วอยู่ต่อ ใช้แนวทางนี้เมื่อการเปลี่ยนแปลงเรื่องการฝึกของ Copilot เป็นข้อกังวลเดียวของคุณ และ GitHub ยังตอบโจทย์การทำงานของทีม ปิดการตั้งค่าระดับบัญชีแล้วทำงานต่อ
• B: ใช้แบบไฮบริด เก็บโครงการโอเพนซอร์สสาธารณะไว้บน GitHub เพื่อผลจากเครือข่าย ย้ายโค้ดส่วนตัวไปยังอินสแตนซ์ Forgejo, Gitea หรือ GitLab CE ที่โฮสต์เองหลัง VPN หรือรายการ IP ที่อนุญาต ใช้แนวทางนี้เมื่อการเข้าถึงแบบสาธารณะและการควบคุมแบบส่วนตัวสำคัญพร้อมกัน
• C: ย้ายทั้งหมด ย้ายทุกอย่างออกจาก GitHub ใช้แนวทางนี้เมื่อกฎระเบียบ ถิ่นที่อยู่ของข้อมูล ธรรมาภิบาล หรือนโยบายใช้ซอฟต์แวร์เสรีเท่านั้น ตัด GitHub ออกไป และทีมรับต้นทุนการดูแลได้

ผู้อ่านส่วนใหญ่อยู่ในจุดยืน A หรือ B ส่วนจุดยืน C มีเหตุผลรองรับจากข้อกำหนดด้านธรรมาภิบาล อธิปไตย หรือค่านิยมที่เข้มงวดกว่า ไม่ใช่จากการตั้งค่า Copilot เพียงอย่างเดียว

อะไรที่เปลี่ยนไปจริง ๆ ในเดือนเมษายน 2026

การเปลี่ยนแปลงเชิงเทคนิคนั้นเล็กน้อย ในการตั้งค่า Copilot ผู้สมัครสมาชิกรายบุคคลสามารถตั้ง "Allow GitHub to use my data for AI model training" เป็น Disabled ได้ GitHub อธิบายสิ่งที่ครอบคลุมว่าเป็นการโต้ตอบกับฟีเจอร์และบริการของตน รวมถึงอินพุต เอาต์พุต ชิ้นส่วนโค้ด และบริบทที่เกี่ยวข้อง ไม่ใช่เนื้อหาของที่เก็บโค้ดส่วนตัวที่ไม่เคยผ่าน Copilot เลย

Copilot Business และ Enterprise ไม่แสดงสวิตช์นี้ เพราะข้อมูลของทั้งสองได้รับความคุ้มครองภายใต้ข้อตกลงคุ้มครองข้อมูลของ GitHub สำหรับแพ็กเกจรายบุคคล การปิดการตั้งค่านี้ตอบโจทย์ข้อกังวลเรื่องนโยบายการฝึกโมเดล แต่ไม่ได้แก้ข้อโต้แย้งที่กว้างกว่านั้น คือการต้องพึ่งพานโยบายที่ผู้ให้บริการเป็นผู้กำหนด

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

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

อธิบายจุดยืนทั้งสาม

สรุปการตัดสินใจไว้ในสามแถว รายละเอียดอยู่ด้านล่าง

จุดยืน A: ปฏิเสธแล้วอยู่ต่อ

ถ้าคุณเป็นนักพัฒนาคนเดียวหรือทีมเล็กที่มีที่เก็บโค้ดส่วนตัว และข้อติเดียวของคุณคือค่าเริ่มต้นเรื่องการฝึกโมเดล นี่คือคำตอบของคุณ การสลับการตั้งค่าใช้เวลาหนึ่งนาที ครั้งเดียวจบ ส่วนการโฮสต์เองคือ ค่า VPS ก้อนเล็ก ๆ กลยุทธ์สำรองข้อมูลที่คุณทดสอบจริง การเชื่อมต่อที่ต้องสร้างใหม่เพราะมันตั้งอยู่บนการยืนยันตัวตนของ GitHub และงานอัปเกรดหรือกู้คืนเป็นครั้งคราวที่มักมาในจังหวะที่แย่ที่สุด

การโฮสต์เองยังคุ้มค่าได้อยู่ แต่ต่อเมื่องานที่ต้องทำซ้ำ ๆ นั้นซื้อสิ่งที่คุณต้องการจริง ๆ ให้คุณ

ข้อโต้แย้งที่หนักแน่นที่สุดคือ สวิตช์นั้นก็เป็นการตัดสินใจของผู้ให้บริการเช่นกัน ในปี 2026 GitHub เปลี่ยนจากการไม่ใช้ข้อมูลการโต้ตอบนี้ฝึกโมเดลโดยค่าเริ่มต้น มาเป็นใช้โดยค่าเริ่มต้น และก็เปลี่ยนนโยบายได้อีก

ถ้าความกังวลลึก ๆ ของคุณคือ "ผมไม่อยากให้ผู้ให้บริการสหรัฐมาตัดสินใจฝ่ายเดียวเกี่ยวกับโค้ดของผมเลย" ก็ไม่มีช่องติ๊กไหนแก้ได้ และจุดยืน A คือคำตอบที่ผิดสำหรับคุณ ข้ามไปที่จุดยืน C ได้เลย

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

จุดยืน B: ใช้โมเดลไฮบริด

การโฮสต์แบบไฮบริดแยกการเข้าถึงแบบสาธารณะออกจากการควบคุมแบบส่วนตัว

การแบ่งนั้นตรงไปตรงมา โครงการโอเพนซอร์สสาธารณะอยู่บน GitHub ต่อไป เพราะผลจากเครือข่าย สายป้อนผู้ร่วมพัฒนา Dependabot และระบบนิเวศ Actions คือคุณค่าที่จับต้องได้ ส่วนโค้ดส่วนตัวย้ายไปยังอินสแตนซ์ที่โฮสต์เองหลัง VPN หรือรายการ IP ที่อนุญาต ซึ่งเข้าถึงจากอินเทอร์เน็ตสาธารณะไม่ได้เลย

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

สำหรับทีมส่วนตัวขนาด 2 ถึง 10 คน 2 vCPU และ RAM 4 GB เป็นจุดเริ่มต้นที่ปลอดภัยกว่าสำหรับ Forgejo หรือ Gitea และควรเผื่อมากกว่านี้ถ้าการทำดัชนีค้นหา แพ็กเกจ หรือ CI ใช้เครื่องเดียวกัน ให้ถือว่านี่คือการกำหนดขนาดของ Forgejo/Gitea ไม่ใช่ของ GitLab CE: บทแนะนำการติดตั้งแบบโหนดเดียวของ GitLab เริ่มต้นที่ 8 vCPU และหน่วยความจำ 7.2 GB ก่อนจะรวมภาระงาน CI เข้าไป

อย่าเปิดหน้าเว็บทิ้งไว้บนพอร์ต 80 หรือ 443 ให้จำกัดการเข้าถึงที่ไฟร์วอลล์ พร็อกซี VPN หรือชั้นเครือข่ายแบบเมช ส่วนตัวรัน CI สามารถให้บริการได้ทั้งสองฝั่ง

การเลือกแพลตฟอร์มเปลี่ยนชุดฟีเจอร์มากกว่าตัวโมเดลไฮบริดเสียอีก Forgejo และ Gitea เหมาะกับฟอร์จส่วนตัวที่เบากว่า ส่วน GitLab CE สมเหตุสมผลกว่าเมื่อคุณต้องการชุด CI/CD และรีจิสทรีในตัวด้วย

อ่าน

Gitea vs Forgejo vs OneDev: การเลือกแพลตฟอร์ม Git แบบ Self-Hosted

การสำรองข้อมูลจัดการได้ไม่ยาก แต่อย่าลดทอนมันเหลือแค่ git bundle คำแนะนำการอัปเกรดอย่างเป็นทางการของ Forgejo ถือว่าการสำรองที่เชื่อถือได้คือสแนปช็อต ณ จุดเวลาเดียวกันของพื้นที่จัดเก็บทั้งหมดที่ Forgejo ใช้ และเมื่อทำเช่นนั้นไม่สะดวก ก็ให้ใช้ Forgejo dump ควบคู่กับ dump ของ PostgreSQL หรือ MySQL แยกต่างหาก ไม่ว่าจะใช้ Forgejo หรือ Gitea ให้เก็บที่เก็บโค้ด ฐานข้อมูล คอนฟิก ไฟล์แนบ และข้อมูล LFS ไว้ด้วยกัน เก็บสำเนาไว้นอกเซิร์ฟเวอร์ และทดสอบการกู้คืนจริง

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

จุดยืน C: ย้ายทั้งหมดเมื่อการควบคุมเป็นข้อกำหนด

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

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

ต้นทุนคือ VPS เครื่องเล็ก การดูแลรักษาอย่างต่อเนื่อง และการสูญเสียการเชื่อมต่อ ส่วนที่คนมักลืมคือการสูญเสียการเชื่อมต่อนี่แหละ อะไรก็ตามที่ยืนยันตัวตนด้วย "Sign in with GitHub" ก็ยังต้องอยู่บน GitHub หรือไม่ก็ต้องมีผู้ให้บริการตัวตนแยกต่างหาก

วางแผนการย้ายโดยยึดจากสิ่งที่พึ่งพากันอยู่ ไม่ใช่แค่ที่เก็บโค้ด ตัวอย่างพรีวิวของพูลรีเควสต์ Actions จากภายนอก บอต เว็บฮุก รีจิสทรีแพ็กเกจ และการเชื่อมต่อผ่าน "Sign in with GitHub" อาจต้องใช้ข้อมูลรับรองใหม่ เวิร์กโฟลว์ใหม่ หรือบริการทดแทน ส่วนดาวและผู้ติดตามจะไม่กลายเป็นข้อมูลในระบบของฟอร์จใหม่ ดังนั้นโครงการสาธารณะจึงต้องยอมสละสัญญาณการค้นพบที่มีอยู่ไปบางส่วนด้วย

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

สำหรับทีมที่ต้องการธรรมาภิบาลแบบไม่แสวงหากำไรโดยไม่ต้องดูแลเซิร์ฟเวอร์เอง Codeberg น่าพิจารณา

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

ต้นทุนการดำเนินงานของการโฮสต์ Git แบบสาธารณะ

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

ในการสนทนาเรื่อง Git ที่โฮสต์เองซึ่งกล่าวถึงก่อนหน้านี้ ผู้ดูแลระบบรายหนึ่งรายงานว่ามีคำขอ 37,212,377 ครั้งเข้ามาที่อินสแตนซ์ cgit ภายใน 60 วัน โดยกว่า 99% ถูกจัดว่าเป็นบอต

ในการสนทนาเดียวกัน kstrauser เล่าว่าได้ลดคำขอที่เข้าอินสแตนซ์ Forgejo จากราว 600,000 ครั้งต่อวัน เหลือประมาณ 1,000 ครั้ง แต่ทำได้ก็ต่อเมื่อเพิ่มด่านทดสอบด้วย JavaScript และคุกกี้ซ้อนทับมาตรการมาตรฐานแล้วเท่านั้น

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

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

ด่านทดสอบด้วย JavaScript หรือคุกกี้ช่วยลดการขูดข้อมูลแบบไม่ซับซ้อนได้ แต่ก็อาจกันผู้ใช้ที่ไม่เปิด JavaScript ออกไปด้วย และรบกวน Git ผ่าน HTTPS ถ้าเอาไปใช้กับทุกเส้นทาง ส่วนการแคชผ่าน CDN ช่วยได้กับการอ่านซ้ำ ๆ แต่ช่วยได้น้อยกว่ามากกับปลายทางที่ไม่ซ้ำหรือกินทรัพยากร เช่น ไฟล์อาร์ไคฟ์ มุมมอง blame และหน้าของแต่ละคอมมิต

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

ใช้ด่านทดสอบฝั่งเบราว์เซอร์อย่างเลือกเฟ้น เปิด SSH ไว้สำหรับการทำงานของ Git และทดสอบ Git ผ่าน HTTPS ก่อนจะเอาการป้องกันไปครอบเส้นทางนั้น เพราะหน้าด่านทดสอบที่ส่งกลับไปยังไคลเอนต์ Git จะกลายเป็นการโคลนที่ล้มเหลว ไม่ใช่ขั้นตอนตรวจสอบที่มีประโยชน์

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

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

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

คำถามเรื่องผลจากเครือข่ายสำหรับผู้ดูแลโครงการโอเพนซอร์ส

ตรงนี้ผมกำลังพูดกับผู้อ่านกลุ่มหนึ่งโดยเฉพาะ คุณดูแลโครงการโอเพนซอร์สอยู่ มีผู้ร่วมพัฒนายี่สิบคน ดาวสองร้อยดวง และตัวติดตามอิชชูที่ยังคึกคัก และคุณกำลังคิดจะย้ายมันออกจาก GitHub

ซื่อสัตย์กับตัวเองว่าคุณกำลังแลกอะไรไป ทั้งโอกาสที่ผู้ร่วมพัฒนาจะเจอโครงการ เครื่องหมายความน่าเชื่อถือโดยปริยายของ github.com, Dependabot, CodeQL และระบบนิเวศของบุคคลที่สามที่อิงกับการยืนยันตัวตนของ GitHub ไม่มีอะไรในนี้ที่ทำที่อื่นไม่ได้ แต่ทุกอย่างกลายเป็นแรงเสียดทาน

กฎคร่าว ๆ ที่ผมจะเสนอคือ ถ้าคุณค่าของโครงการอยู่ที่ตัวโค้ดเป็นหลัก การโฮสต์เองก็อธิบายเหตุผลได้ง่ายกว่า

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

ภาพรวมแพลตฟอร์มของ Codeberg อธิบายถึงบริการที่สร้างบน Forgejo ซึ่งดำเนินการโดยองค์กรไม่แสวงหากำไร Codeberg e.V. สำหรับผู้ดูแลโครงการโอเพนซอร์ส นั่นหมายถึงธรรมาภิบาลโดยชุมชนโดยไม่ต้องแบกภาระการดูแลฟอร์จด้วยตัวเอง

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

ทำการเปลี่ยนแปลงที่เล็กที่สุดซึ่งแก้ปัญหาได้

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

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

ของ Cloudzy การติดตั้ง Forgejo ในคลิกเดียว เป็นวิธีที่รวดเร็วในการตั้งฝั่งส่วนตัวของโมเดลไฮบริด ส่วนการติดตั้งด้วยมือบน Linux VPS ก็ใช้ได้เช่นกัน ไม่ว่าจะเลือกทางไหน ให้เก็บหน้าเว็บไว้เป็นส่วนตัว สำรองสถานะทั้งหมดของแอปพลิเคชัน และทดสอบการกู้คืนก่อนจะย้ายที่เก็บโค้ดสำคัญ

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

คำถามที่พบบ่อย

ควรย้ายออกจาก GitHub เพราะการเปลี่ยนแปลงเรื่องการฝึกของ Copilot หรือไม่?

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

GitHub เอาที่เก็บโค้ดส่วนตัวของฉันทั้งหมดไปฝึกโมเดลหรือเปล่า?

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

การโฮสต์ Git เองเป็นส่วนตัวกว่าเสมอหรือไม่?

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

ควรเลือกแพลตฟอร์ม Git แบบโฮสต์เองตัวไหนดี?

เลือก Forgejo หรือ Gitea ถ้าคุณต้องการฟอร์จส่วนตัวที่เบากว่า เลือก GitLab CE เมื่อ CI/CD ในตัวและรีจิสทรีแพ็กเกจหรือคอนเทนเนอร์สำคัญมากพอที่จะคุ้มกับความต้องการทรัพยากรและการดูแลรักษาที่สูงกว่า

Forgejo หรือ Gitea ต้องใช้ VPS ขนาดไหนสำหรับทีมเล็ก?

สำหรับทีมส่วนตัวสองถึงสิบคน 2 vCPU และ RAM 4 GB เป็นจุดเริ่มต้นที่ปลอดภัยกว่า ให้เพิ่มกำลังเครื่องเมื่อการทำดัชนีค้นหา แพ็กเกจ ที่เก็บโค้ดขนาดใหญ่ หรือตัวรัน CI ใช้เครื่องเดียวกัน ส่วน GitLab CE ให้คำนวณขนาดแยกต่างหาก เพราะต้องใช้ทรัพยากรมากกว่า

ควรทดสอบอะไรบ้างก่อนเปลี่ยนรีโมตหลัก?

ทดลองนำร่องกับที่เก็บโค้ดตัวแทนหนึ่งตัว ตรวจสอบประวัติอิชชูและพูลรีเควสต์ การยืนยันตัวตน Actions หรือเวิร์กโฟลว์ CI ที่ใช้แทน เว็บฮุก การเผยแพร่แพ็กเกจ ข้อมูล LFS สภาพแวดล้อมพรีวิว การสำรองข้อมูล การกู้คืน และเส้นทางย้อนกลับ ก่อนจะย้ายทั้งหมด